Subject: RE: [ietf-dkim] "I sign everything" yes/no

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 21 Nov 2006 17:44:09 -0800

> [mailto:[email-masked]] On Behalf Of J.D. Falk

> Should that be in SSP?  Should it be in something else?  
> Should I encourage all of the banks to use a non-standardized 
> external mechanism while y'all argue?

Policy should support that statement and only that statement plus the absolute bare minimum required to move from one version of DKIM (read algorithm choices) to another.

Policy statements should be actionable. If the policy statement does not cause the receiver to act differently there is no value.

"I sign almost all my mail with DKIM" does not seem to me to have any real value.

There is a practical value between "I sign all my mail with DKIM" and "I send no mail ever". The first has a large scope for administrative mess ups. I don't think many people would say they send no mail by mistake.

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Tue, 21 Nov 2006 19:09:40 -0800

On Nov 21, 2006, at 5:44 PM, Hallam-Baker, Phillip wrote:
>
> Policy should support that statement and only that statement plus  
> the absolute bare minimum required to move from one version of DKIM  
> (read algorithm choices) to another.

A separate authorization scheme can be easily subverted to mislead  
recipients.  DKIM will not prevent spam, and an authorization scheme  
will not thwart phishing attempts.  Perhaps just the opposite could  
be true.  The goal of blocking spam should not cloud rational choices.

DKIM signatures are not visible.  Without alternation of the MUA,  
there is no assurance recipients see elements assured by policy.   
When the MUA is altered, the address-book provides a far more secure  
method to authorize annotations added to DKIM signed messages.

Of course policy used as authorization must be discoverable from all  
possible sub-domains as well.  The majority of email domains do not  
publish policy records.  Searching for largely non-existent records  
after each message generates a flood of DNS traffic.  Even a new  
wildcard PPTR discovery scheme still involves several non-cached  
transactions per message, and can not indicate when this scheme is  
available before hand.

Blocking all bad messages based upon what is "authorized" will not  
reduce the success rate for a substantial portion of phishing  
attempts.  An effective annotation scheme based upon the recipient's  
address book should greatly reduce the success of phishing without  
adding to email's overhead.  Making phishing less successful is the  
best way to stop phishing traffic.

It remains conjecture an authorization scheme provides a measurable  
reduction in the success rate.  As bad actor are able to authorize  
their own messages in various forms, an authorization scheme may  
increase the success rate of phishing attempts.  Recipients are not  
protected by such a highly flawed scheme.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Tue, 21 Nov 2006 22:49:44 -0500

Douglas Otis wrote:
> reduction in the success rate.  As bad actor are able to authorize their 
> own messages in various forms, an authorization scheme may increase the 
> success rate of phishing attempts.  Recipients are not protected by such 
> a highly flawed scheme.

I don't understand why you make it so difficult.

If I say "all may mail is signed" and that expectation is defined based
on a standard SSP protocol established, then a RECEIVER and the original
DOMAIN owner should be as happy as a pig in mud when fraudulent MAIL is
arriving without signatures.

The first thing that we will be getting rid of is the legacy malicious
exploiters of domains who are not going to following anything or would
care for anyway.

But sure, bad actors can participate in the DKIM/SSP process and in my
view, that is great if we can get them to ADAPT in a positive way - our
way.

That is where the additional layers come into play, such as REPUTATION
if that is what the receiver wants to use to further give credence to a
DKIM-ready message.

The goal is to eliminate the obvious and that obvious comes in detecting
the invalid conditions and if a DOMAIN exposes a policy implying invalid
conditions were not expected, then all the receiver needs to junk or do
something with that message and the receiver and original domain would
be protected.   We don't need an MUA to get an involved.

I don't see whats so hard to understand about this.

---
HLS

---

From: Douglas Otis <[email-masked]>
Date: Tue, 21 Nov 2006 21:14:32 -0800

On Nov 21, 2006, at 7:49 PM, Hector Santos wrote:

> Douglas Otis wrote:
>>
>> It remains conjecture an authorization scheme provides a  
>> measurable reduction in the success rate.  As bad actor are able  
>> to authorize their own messages in various forms, an authorization  
>> scheme may increase the success rate of phishing attempts.   
>> Recipients are not protected by such a highly flawed scheme.
>
> If I say "all may mail is signed" and that expectation is defined  
> based on a standard SSP protocol established, then a RECEIVER and  
> the original DOMAIN owner should be as happy as a pig in mud when  
> fraudulent MAIL is arriving without signatures.

This presumes bad actors are blocked by an easily defeated scheme.   
Guidance offered by SPF suggests the numbers blocked is less than  
3%.  In addition, blocking is not as black and white as you suggest.   
What happens when someone sends a message to a mailing list?

Bad actors easily create messages that appear official and blessed by  
their authorization record.  The recipient is still in the muck  
sorting through fraud while attempting to uncover a bad actor's many  
tricks.  With EAI, there are now two email-address published per From  
entity.  Which email-addresses is checked?  What part of the email- 
address is displayed, if any?  An authorization scheme alone benefits  
bad actors.

> The first thing that we will be getting rid of is the legacy  
> malicious exploiters of domains who are not going to following  
> anything or would care for anyway.

Are you talking about including policies for the Mail From as well?

> But sure, bad actors can participate in the DKIM/SSP process and in  
> my view, that is great if we can get them to ADAPT in a positive  
> way - our way.

The recipient is still lost attempting to decide which messages are  
valid. Look-alike and cousin domain ploys are not defeated.  Without  
evidence there is any value validating the DKIM signature, it should  
not be done.  Here domain association techniques can play a greater  
role than would any authorization scheme.  If there is any  
authorization scheme added, it would be practical in only a very  
small portion of domains sending messages.  Hardly worth the overhead.

> That is where the additional layers come into play, such as  
> REPUTATION if that is what the receiver wants to use to further  
> give credence to a DKIM-ready message.

Without a means to prevent positive reputations (white-listing) from  
being abused, positive reputation use is highly prone.  Anti-replay  
protections require some means to associate DKIM signing with the  
SMTP client.  SPF does not offer a safe method for this association.   
As the envelope is not included within the DKIM signature,  
unsolicited messages can not accrue against the signing domain.  It  
would be a bad outcome when messages are rejected because envelopes  
do not match message headers.

> The goal is to eliminate the obvious and that obvious comes in  
> detecting the invalid conditions and if a DOMAIN exposes a policy  
> implying invalid conditions were not expected, then all the  
> receiver needs to junk or do something with that message and the  
> receiver and original domain would be protected.   We don't need an  
> MUA to get an involved.

In an ideal world, perhaps.  Limiting this effort to only  
authorization is the wrong choice.  While the MTA might be able to  
block 2.5% of non-compliant messages, the success rate of phishing  
will hit a new high, and the integrity of email delivery will hit a  
new low.  DKIM requires the MUA to annotate messages.  The DKIM  
signature is not visible _by design_.  There is no assurance what the  
recipient sees in a non-DKIM aware MUA.  This must change, and  
efforts must focus upon message annotations.  Once the recipient has  
an MUA that compares signed messages against their address-book,  
there is _absolutely_ no need for an authorization scheme,  the  
sizable overhead, and the many delivery problems with incumbent  
support calls.

Why not allow the MUA to safely apply annotations based upon a  
recipient's out-of-band knowledge of the sender.   What annotations  
can be applied based upon an email-address domain authorizing their  
own messages?  None.  When authorization is the only goal, then  
practical, safe, and reasonable has been completely missed.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 22 Nov 2006 17:36:22 +0100

> I don't see whats so hard to understand about this.

I don't understand the definition of "my" in "all my mail is signed",
wrt mail without signatures (or unrelated signuters).  What is "my" ?

Anything that's neither PRA nor MAIL FROM doesn't fly, and MAIL FROM
is out of scope.  From that I conclude that "my" MUST mean PRA, is
that correct ?

Frank

---

From: Hector Santos <[email-masked]>
Date: Wed, 22 Nov 2006 12:34:18 -0500

> is out of scope.  From that I conclude that "my" MUST mean PRA, is

No,  MAIL FROM has nothing do with it and you (speaking in general) keep 
talking about 821 stuff, then that only feeds unrelated nonsense SPF 
talk to those who want to believe they discovered anything new about 
whats wrong with SPF.

DKIM/SSP is 100% 2822 and the only thing close to the MAIL FROM is 
possibly the inclusion of the Sender: address in the hashing.  This is 
not about SPF,  PRA.  (See more below)

Its the 2822.FROM: that is "My" mail.   That is the constant, consistent 
frame work in every mail system, including gateways.  The 2822.FROM is 
the "connector' between what is WRITTEN and what is SHOWN.

That's it. No more, no less.

That said, for a system that might want employ 2821 and 2822 logic, for 
example, a domain may have an exclusive SPF policy and an exclusive 
DKIM/SSP policy.   The RECEIVER will process 2821 first. SPF must pass 
first before it even gets to 2822, and when it goes to 2822, all 2821 
logic has already been satisfied.   However, if the 2821 fails, then 
DKIM/SSP does not even come into play.

Now, is there a tie-in?  There is probably has logic to make a tie-in 
between the two.  But I see them as completely separate and you need to 
keep it that way for 1 main reason:

      - Dynamic SMTP processing vs Post SMTP processing

A more modern system will in be able to process DKIM/SSP at the 
transient level (at the DATA stage).  Here this framework has a greater 
chance of having some "tie-in" logic.

Others, and they could be modern too, will process the mail after it is 
received.  At this point, the technology can not be dependent on any 
2821 information being available to them.

So in short. DKIM/SSP is 100% 2822.  It can not be dependent on any 2821 
information.

---
HLS

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 22 Nov 2006 21:24:52 +0100

Hector Santos wrote:

> Its the 2822.FROM: that is "My" mail.

I don't believe that.  The 2822-From is the author.  It's perfectly
okay to use it in SMS, news etc., arriving elsewhere as mail with a
different Sender, Resent-Sender, or Resent-From.

Depending on where it originally came from it can have no signature
at all.  "I sign all mail" isn't the same as "I sign everything with
some From: me construct".

> That is the constant, consistent frame work in every mail system,
> including gateways.

Not for news from me behind a news2mail gateway.  Folks want to use
"their" 2822-From-addresses whereever it pleases them, not only on
outbound routes with the corresponding DKIM-signing agents.

> The RECEIVER will process 2821 first

One hopes... :-)

> SPF must pass first before it even gets to 2822, and when it goes
> to 2822, all 2821 logic has already been satisfied.

It can be still some MAIL FROM me Resent-From me with a rather old
"From you".  Or a MAIL FROM GMaNe Sender GMaNe From me (that's what
the list here sees), where GMaNe is some special news2mail gateway,
of course with both SPF and SenderID PASS for MAIL FROM and Sender.

Do you intend to enumerate all cases where a pure 2822-From logic
won't work as expected, adding a MUST NOT in the SSP draft ?  With
Sender-ID some folks already had serious doubts that it will work.

A policy bound to the 2822-From is even more restrictive, and for
a policy about DKIM signatures it's additionally bound to a single
outbound route.  It's a kind of BATV for 2822, like Sender-ID is a
kind of SPF for 2822.

If that goes into an SSP RFC it should list scenarios where it will
"annotate" perfectly harmless mails as "suspicious".  And we know
that "annotate as suspicious" means DROP, otherwise we'd say REJECT.

Rough idea how to express that in the next SSP requirements draft:

"The protocol MUST state what 'DKIM signing complete' precisely
 means wrt common practises like resending, news, and other uses
 of a 2822-From address".

Frank

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 23 Nov 2006 14:05:36 +0000

Hi Frank,

>  means wrt common practises like resending, news, and other uses

Two questions:

Can you provide us with an example of the kind of statement
you'd envisage being made in an SSP protocol draft?

I don't understand why we, now, need to care about other
uses of the 2822-From address? (And if we did, then why news and
not, say kerberos, where the same string may occur.)

Stephen.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 23 Nov 2006 15:16:31 -0000

> talk to those who want to believe they discovered anything new about  

If writers of verifiers find it useful to use knowledge of the envelope  
addresses, then they will do so, whatever we say. Those fighting spam  
cannot do so with one hand tied behind their backs.

> the "connector' between what is WRITTEN and what is SHOWN.

On the contrary, it is the Sender header if present that should be the  
decider, and only the From if Sender is absent. People keep ignoring the  
fact that there can be several addresses in a From header (in which case  
Sender is obligatory).

On top of that, the message might also be Resent, as Frank has pointed  
out. Hopefully, the resender will have preserved the Signature put there  
on behalf of the original Sender. If the Resender also "signs everything",  
then an extra signature should be picked up there.

BTW, the bit in the base document that says the "From" MUST always be  
signed is wrong. It should have been the Sender, and maybe any Resent-From  
too. And that MUST is going to haunt us again when EAI happens, because  
both From and Sender may well get changed in transit. Not clear how EAI is  
going to get around that, but that obligatory From signing is not going to  
make that job any easier.
> 2821 information being available to them.

On the contrary, the MAIL FROM should now be in the Return-Path, and then  
it is a 2822 header and the verifier is allowed to look at it. So why  
shouldn't it look at it before then?

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Thu, 23 Nov 2006 14:00:28 -0500

Charles Lindsey wrote:

 > If writers of verifiers find it useful to use knowledge of the
 > envelope addresses, then they will do so, whatever we say. Those
 > fighting spam cannot do so with one hand tied behind their backs.

So you have a generalize rule everyone should follow?

That is what we need to stop trying to impose.  What is consistent in
all systems is a 2822.FROM and that is what DKIM/SSP is based on.

 >> Its the 2822.FROM: that is "My" mail.   That is the constant,
 >> consistent frame work in every mail system, including gateways.
 >> The 2822.FROM is the "connector' between what is WRITTEN and what
 >> is SHOWN.
 >
 > On the contrary, it is the Sender header if present that should
 > be the decider,

Who says?

 > and only the From if Sender is absent.

Why?

 > People keep ignoring the fact that there can be several addresses
 > in a From header (in which case Sender is obligatory).

No one ignored it. It is part of the specs.

 > On top of that, the message might also be Resent, as
 > Frank has pointed out.

Irrelevant because its a retransmission. News/Email gateways don't apply 
as well.

 > Hopefully, the resender will have preserved the Signature put
 > there on behalf of the original Sender. If the Resender also
 > "signs everything", then an extra signature should be picked up there.

Exactly, so it doesn't apply.

 > BTW, the bit in the base document that says the "From" MUST
 > always be signed is wrong. It should have been the Sender, and
 > maybe any Resent-From too.

No, SENDER nor Resent-* anything is guaranteed.  2822.From is.

 > And that MUST is going to haunt us again when EAI happens,
 > because both From and Sender may well get changed in transit.

A retransmission.  Doesn't apply.

 >> Others, and they could be modern too, will process the mail after
 >> it is received.  At this point, the technology can not be
 >> dependent on any 2821 information being available to them.

 > On the contrary, the MAIL FROM should now be in the Return-Path,
 > and then it is a 2822 header and the verifier is allowed to look
 > at it. So why shouldn't it look at it before then?

Nope.  A in-transient system will store the Return-Path, but there is no 
  guarantee it will passed on to the next process.  In fact, many 
systems will STRIP it once it reaches its final destination.  That that 
means is that a MFA (Mail Filtering Agent) that is outside the SMTP 
reception boundary DOES NOT have a guarantee the Return-Path will be 
part the headers.

Anyway, I still say this process has been made more difficult than it 
already is and we need to stop talking about 2821 considerations unless 
you want to rewrite the entire email framework where there is only a set 
of processing rules that applies across the board and for everyone to 
use.  Needless to say, that isn't going to happen.

DKIM/SSP needs to fit the current framework - not the other way around.

The first basis for DKIM/SSP is to resolve and address the FIRST PARTY 
conditions.  We have that.

We already know about the remaining key two issues for over 2 years

    - 3rd party
    - Mailing List

which are inter-related with each other and has not really changed since.

But the first party condition is the most important one to be resolved 
and DKIM/SSP does that.

---
HLS

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 23 Nov 2006 19:37:01 -0000

> not, say kerberos, where the same string may occur.)

Because news and email regularly get gatewayed into each other.

Suppose foo.example announces that it "signs everything" (presumably we  
intend that to mean all emails). So if [email-masked] sends an unsigned  
email, it is sure to be treated with "suspicion".

But what if [email-masked] posts an article to some newsgroup? DKIM in  
Usenet might be found to be a good idea someday, but it is not likely to  
be in our drafts and is not in our charter. So, although they would do no  
harm, we are not expecting such signatures on Usenet. But things leak, and  
his article might turn up as an email (probably on some mailing list). We  
don't want the mailing list admin to reject is as being unsigned. Maybe  
the gateway should have signed it (quite a good edea that, and then the  
SSP and reputation of the gateway would come into play). But is that  
sufficient to cover for the lack of a signature by foo.example?

And maybe (USEFOR hat on here) gateways from news to email ought to be  
adding suitable Resent-* headers.

---

From: Hector Santos <[email-masked]>
Date: Thu, 23 Nov 2006 19:07:06 -0500

> Because news and email regularly get gatewayed into each other.

But this suggest that you have a DKIM-NNTP based protocol as well as a 
DKIM-EMAIL protocol which is what the DKIM system only currently supports.

I think we are asking for why too much trying to get DKIM to work in a 
NEWS/EMAIL gateway environment, especially when there is no standard for 
such processing and transformation.  And even then, it shouldn't be a 
big issue as long as the "twain shall never meet."  NEWS is NEWS, EMAIL 
is EMAIL.  Transformation concepts would have be done in such a way that 
they appear to be independent of each other.

You need to address the base system first which is 1 to 1 EMAIL concept 
before we even have a chance to make it work in a 1 to MANY or MANY to 
MANY environment.

> be in our drafts and is not in our charter. 

Right, so why are fussing around with this can of worms?  If the user 
with an exclusive domain is going outside a domain policy to post mail 
in a newsgroup, then isn't this exactly what we might want to protect 
against?  The domain has gone to the trouble to protect itself with DKIM 
because it may not want such activity with its domain property.  Why 
should we go against those wishes?   If the domain doesn't want this, 
then it shouldn't use DKIM/SSP.

In my view, implementing DKIM for NNTP would have be a GROUP concept 
which is what NNTP is designed be a - a GROUP conferencing system.  This 
is much different then a DKIM 1 to 1 concept.

Granted, many systems have successfully "merged" the two - such as our 
own  Wildcat! SMTP and NNTP Server framework with its NEWS/EMAIL 
interface system.  Sysops can expose news conferences and the outbound 
mail goes as email and vice-versa.  But the transformation is still done 
on the idea that they are independent of each other.

> And maybe (USEFOR hat on here) gateways from news to email ought 
 > to be adding suitable Resent-* headers.

IMV, we should stop trying to mix EMAIL vs NEWS - two different things.

It is already a major consideration just adding DKIM into our email 
framework.  It would almost impossible to begin even thinking about 
throwing in DKIM our NNTP framework.

We are going way overboard with this DKIM consideration.

Anyway, thats my opinion on this.

Thanks for listening.

---
HLS

---

From: Douglas Otis <[email-masked]>
Date: Thu, 23 Nov 2006 17:34:06 -0800

> all systems is a 2822.FROM and that is what DKIM/SSP is based on.

This generalization is incorrect.  Other headers can be accommodated:

http://tools.ietf.org/wg/dkim/draft-otis-dkim-dosp-02.txt

DKIM will never be effective at blocking spam.  Spoofing can only be
stopped by comparisons with lists established by recipients, such as
utilizing their address-book.  A policy to establish expectations of a
signature is unnecessary and is unlikely to curtail a meaningful amount
of abuse.  Once EAI becomes commonly used, a strategy based upon From
header signature compliance falls apart.

Associations with the MAILFROM and the SMTP client utilizing the DKIM
signature can protect against abusive replays when white-listing, and
ensure DSNs.  Associations offer far more protection from abuse than
policy statements such as:

 "All From email-addresses are signed and this invites altered messages
  to be dropped or rejected"

It is clear this type of policy breaks mailing-lists and prevents
modifications needed for EAI.  Even when the EAI alternations are made
prior to signing, there is now the issue that two different
email-addresses that may be present within the new header (one suitable
for UTF-8 and one for ASCII).

Other aspects related to an association scheme can provide these
additional features:

1) Allow email-address domain owners to independently establish
   relationships with email-provider's signing domain without a need to
   relinquish use of their private keys.  Freedom of choice at no cost.

2) Allow email-address domain owners to independently indicate
   assurances of their email-address's validity.

3) Ensure the DKIM signing domain relates the entity transmitting the
   message.  The transmitting entity may have their IP address
   held accountable for spam. Ensuring feedback is sent to the
   transmitting entity offers better and more effective protections.

4) A means to associate the signing domain with the SMTP client is
   essential for protecting the transmitting entity from possible replay
   abuse perpetrated by their customers.  The lack of an SMTP client
   association would disable white-listing.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 23 Nov 2006 21:18:19 -0500

----- Original Message ----- 
From: "Douglas Otis" <[email-masked]>

> utilizing their address-book.

I totally disagree and I don't see that is required for us to consider 
implementing DKIM into our system.    A MUA is not required to protect a 
DOMAIN who has published an SSP with its policy define telling a RECEIVER 
what is expected and not expected.

We have a complete integrated environment and in NO WAY do we see the MUA to 
get involved here.   We can do all this transparently without getting any of 
our 5-6 offline and online MUAs software involved.

The only consideration is if we want to give the ADMIN the option to HOLD 
MAIL or some extras user controls via via 3rd party interface options 
providing the ergonomics to the USER and the instructions to the backend 
server.

But in absolutely no way is this necessary by default and what you are 
talking about is just pure candy.

The current protocol DESIGN is sufficient for MTA to MTA operations without 
a MUA getting involved.  Nes Pas.

---
HLS

---

From: Douglas Otis <[email-masked]>
Date: Fri, 24 Nov 2006 01:58:27 -0800

On Thu, 2006-11-23 at 21:18 -0500, Hector Santos wrote:
> DOMAIN who has published an SSP with its policy define telling a
> RECEIVER what is expected and not expected.

What is meant by an "all From email-addresses are signed" policy
assertion?  Does this mean "Reject or drop messages sent to a
mailing-list."?  If so, what percentage of domains wish to make this
assertion?  

How are EAI headers protected?  What must recipients see before an
assertion of signature expectation offers effective protections for
either recipients or the email-address domain owners?  This question is
largely pointless.  There is no way to know what recipients can see.

If the recipient sees a display name or the UTF-8 version of the From
header, what protection is provided by an assertion applying to
different domain?  None.  Many phishing attempts already utilize altered
email-addresses.  Look-alike or cousin domain attempts are unaffected by
assertions of what is signed.

Annotations based upon signed messages also found in the recipient's
address-book thwarts these various phishing attempts.  Protection is
obtained without recipients needing to take out their magnifying glass
or make often fruitless queries.  At what point does it become clear
self authorization schemes are pointless in both excessive traffic and
easily defeated protections.

Causing phishing attempts to be unsuccessful is the best way to quell
this traffic.  On the other hand, an authorization scheme will likely
improve phishing success rates.  It is possible for plug-ins to be
implemented with existing MUAs. It is being done now, so the MTA vendor
don't need to change what they are doing.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 24 Nov 2006 11:56:36 +0100

Stephen Farrell wrote:

  [proposed requirement]
 
> you'd envisage being made in an SSP protocol draft?

"At the moment 'DKIM-signing-complete means that addresses of the
 given domain cannot be used in the From header field of Netnews
 articles.  All newsgroups can be exported from news by news2mail
 gateways to mail.  For moderated newsgroups articles can be 
 forwarded almost as is by mail from the server where the article
 was submitted to the moderator, or forwarded by mail from one to
 another moderator in the case of cross-posts in multiple moderated
 newsgroups."
 
Maybe too verbose.  The complete list of issues with PRA, plus some
additional issues for the 2822-From-centric POV of SSP, if it uses
the latter (at the moment 6.3 says it does).

> I don't understand why we, now, need to care about other uses of
> the 2822-From address?

Because the terminology is messy.  The 2821-From is something like
an envelope-sender, the 2822-From is something like an author, the
news-From (T -6 days to first opportunity of approval) is a poster.

As soon as I say 2822-Resent-From or Resent-Sender: me any decrees
of the original author in an SSP about 2822-From are at best wishful
thinking.  In one of his anti-replay strategies Doug proposed to
strip the signature at the MDA, and then the resender can't resend
this signature even if she's willing to try this.

All I know about MMS-to-mail gateways is that there's an RFC about
it.  Somebody knowing what it's about has to check if and what it
means wrt 'DKIM-signing-complete'.  Maybe nothing, then it's fine.

Or maybe it means "'DKIM-signing-complete' domains cannot be used
in MMS", and if that's the case then SSP has to say so explicitly.

Is somebody here a 'lemonade' expert ?  A 2822-From can be used in
many applications, transformed into mail at some point.  I have no
clue where that might be a problem wrt a 'DKIM-signing-complete'
SSP, the news2mail case is only the most obvious.

Another obvious case which should be explicitly mentioned in the
'DKIM-signing-complete' explanation is SenderID spf2.0/pra:  Even
if we don't care about PRA, a PRA == 2822-From is a normal case.

A domain claiming to be 'DKIM-signing-complete' has to be sure that
there's some DKIM-signing agent on _all_ routes before one of their 
spf2.0/pra PASS or NEUTRAL IPs.  Otherwise they screwed up, causing
harm for mails "from" their domain.

Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 24 Nov 2006 11:02:13 -0000

> But this suggest that you have a DKIM-NNTP based protocol...

It suggests no such thing. Read what I wrote and respond to that, and not  
to some strawman of your own invention.

> before we even have a chance to make it work in a 1 to MANY or MANY to  

Unfortunately, the world is already way beyond 1 to 1 EMAIL. If you  
introduce DKIM without having previously considered the consequences for  
all existing practices, then perfectly legitimate things which have always  
worked will start to fail. And it is DKIM which will get the blame
>> intend that to mean all emails). So if [email-masked] sends an  
>> unsigned email, it is sure to be treated with "suspicion".
>>  But what if [email-masked] posts an article to some newsgroup? DKIM  
>> in Usenet might be found to be a good idea someday, but it is not  
>> likely to be in our drafts and is not in our charter.
>
> in a newsgroup,

Hold on! Read what I said. I said nothing about posting mail in a  
newsgroup. I spoke about posting news in a newsgroup, and DKIM is not  
involved in that because, as you correctly said, DKIM does not apply to  
NNTP (yet).

The problem does not arise until someone far away gates that news article  
back into email, at which point its lack of a DKIM signature suddenly gets  
noticed. So we need to think abut this and establish the correct  
procedures to be followed (maybe some signature by the gatewayer, or maybe  
some action by the mailing list admin that it was gatewayed to).

> IMV, we should stop trying to mix EMAIL vs NEWS - two different things.

"We" (TINW) are not in a position to stop it. It already happens.  
Gatewaying between newsgroups and mailing lists is an already established  
feature of Usenet. You (TINY) have to live with that.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 24 Nov 2006 11:17:01 +0000

> the latter (at the moment 6.3 says it does).

I don't think its too verbose, but I don't understand how it
answers the question I asked ;-)

You want to add a requirement "The protocol MUST...state..."
I wanted you to give me a strawman statement that would meet
that requirement (that you think is reasonable).

> harm for mails "from" their domain.

I think that last is a fair point. But I'm still not convinced that
it's up to the DKIM WG (now) to figure out all details of all such
gatewaying cases, which is where we'd be heading if we start on that
road.

Stephen.

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Nov 2006 06:21:32 -0500

> What is meant by an "all From email-addresses are signed" policy

Exactly what it means.

> Does this mean "Reject or drop messages sent to a
> mailing-list."?  

Possibly.  If it is not suppose to happen.

> If so, what percentage of domains wish to make this
> assertion?  

Who knows?  Do you?  No.  But I have a pretty good feeling most people, 
company and systems are very interested in protecting their email domain 
properties in this era.  PERIOD.

And quite frankly, I believe the percentage is quite low that most 
domains will want to mix up (Break their own policies) screwing around 
with operations ONCE they begin to consider DKIM.  So if I begin to DKIM 
protect our my "high value" domains, rest assured I am not going to be 
using them promiscuously in mailing list or in other unknown areas.  I 
think that is common sense.  Don't you?

> How are EAI headers protected?  

In the same way everything else is.  EAI shouldn't break the integrity 
of the system just like anything shouldn't.

> What must recipients see before an assertion of signature expectation 
 > offers effective protections for either recipients or the email-address
 > domain owners?

None. MUAs are not involved in my DKIM implementation considerations. 
They are not required.  We are not passing the buck to users.

> This question is largely pointless.  

So why ask?

> There is no way to know what recipients can see.

Sure they do. Its been pretty standard for the last what?  30 years?

   FROM
   TO
   SUBJECT
   DATE

   BODY

Why make is so difficult?

> different domain?  

MUA doesn't apply because the protection, if possible, was done at the MTA.

 > None.

Exactly!

> Many phishing attempts already utilize altered email-addresses.  

Ok, so DKIM doesn't SOLVE everything.  No one claim it did.  BY the same 
token, non-phished domains will be less exploited under a DKIM/SSP 
environment and that is a very important and a major step in the right 
direction.

> Look-alike or cousin domain attempts are unaffected by

Ok, so what else is new?

> address-book thwarts these various phishing attempts.  

No it doesn't. You still have FUZZY logic involved, especially when the 
unknown emerges. If you want to past fuzzy considerations to your users, 
by all means, implement what you want into your own SMTP server so that 
you can pass on the buck to your users. We are not doing that and I 
strongly believe MOST users don't want to baloney sent their way either.

> Protection is obtained without recipients needing to take out 
 > their magnifying glass or make often fruitless queries.

I don't agree.  Once the DOUG-SMTP server passes MORE unknown to the 
user, you are forcing the user to ponder, to begin scratching his heads, 
and in fact, may begin to question the value, sanity and ethics of their 
ISP as to why the ISP are passing junk to them, etc.

 > At what point does it become clear self authorization schemes
 > are pointless in both excessive traffic and easily
 > defeated protections.

No point because I don't believe your statement is true. DKIM/SSP is a 
wonderful technology, especially for 1st party domain protection.  I 
firmly believe that and I've seen nothing by you or anyone else that has 
proved otherwise.

> this traffic.  

And MUAs are suppose to solve this MTA's PASSING the UNKNOWN to them?

> On the other hand, an authorization scheme will likely
> improve phishing success rates.  

I think that is an oxymoron - if you phish, you can't authorize it 
because its an UNKNOWN entity.   Even if the phisher is DKIM-COMPLIANT, 
and this might pass the MTA test, it is no different than having no DKIM 
record as well.  So why would a phisher have a DKIM/SSP setup?  He 
doesn't have do this.  There is nothing really lost or gain.  However, 
if its a NON-PHISH. there is a lot of protection value there.

> It is possible for plug-ins to be implemented with existing MUAs. 

Great. So write it. In the mean time, IMV, I think your suggestion and 
proposal:

- Is completely inappropriate as a standard protocol suggestion for MUAs 
across the board, it is completely unrealistic.

- lacks the design and vendor considerations in MUA variations,

- lack the design and vendor considerations for necessary MSA/MTA 
handling and not passing the buck to end-users,

- is based on concepts typically reserved as "features" not protocol 
variables,  (i.e, not all MUA will have the same address book outline or 
logic you have in mind).

- it unnecessarily requires broad MUAs compliance in order to make DKIM 
adledgely effective,

- at a minimum, it is a ADD-ON concept but not one that is required to 
make DKIM effective.

I believe you are attempting to push a specific MUA product design on 
the industry when it isn't necessary, and it is obviously more harmful 
for the user.  Even then, are you planning to take over the MUA world to 
make sure all systems all work the same?

> It is being done now, 

What's being done now? DKIM Extensions for MUAs or extensions in general?

 > so the MTA vendor don't need to change what they are doing.

You mean I should stop and just wait for DKIM ready MUAs to come to 
market?  I don't have to do anything with my MSA/MTA/MDA? MFA?  Am I 
suppose to alter my MUAs using your ADDRESS BOOK design?  What about my 
online MUA devices?  Do you have an extension for that too?

You need to keep your eye on the ball.   MUAs are not required for 
DKIM/SSP operations.  It adds NOTHING more to the process but more cost, 
unrealistic considerations and simply put, it won't help DKIM/SSP 
process.  Your MUA's ideas are simply not required to implement DKIM/SSP.

---
HLS

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 24 Nov 2006 11:25:09 -0000

> all systems is a 2822.FROM and that is what DKIM/SSP is based on.

Then DKIM/SSP is WRONG, because it can't work like that.
>  > On the contrary, it is the Sender header if present that should

RFC 2822, which makes it clear that the Sender, if present, indicates  
where the email _really_ came from.
>  > and only the From if Sender is absent.

RFC 2822 again.
> No one ignored it. It is part of the specs.

Quite. So it a From shows that the mail came from five people at five  
different domains, some of which "sign all mail" and some do not, then  
which domain gets to sign the message and which domain's SSP is a verifier  
supposed to consult?

> No, SENDER nor Resent-* anything is guaranteed.  2822.From is.

It is indeed guaranteed to be present, but not guaranteed to contain the  
information you need.
> A retransmission.  Doesn't apply.

No, it is NOT a retransmissiom. Read the EAI drafts.

> systems will STRIP it once it reaches its final destination.

Then how come RFC 2821 says "..., exactly one return path SHOULD be  
present when the message is delivered"? If that information is present  
when the message is handed off by SMTP, and the local delivery system then  
throws it away before doing its filtering based on what the verifier  
found, then that is its own stupid fault.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 24 Nov 2006 12:40:04 +0100

> Who says?

STD 11.  In Dave's classic "secy@ example" boss@ tells secy@
to send mail "from boss@ to somebody@".  The boss@ won't tell
secy@ which mail route to use, secy@ decides these details.

> News/Email gateways don't apply as well.

NAK.

> No, SENDER nor Resent-* anything is guaranteed.  2822.From is.

NAK.

 [post-SMTP Return-Path]
> there is no guarantee it will passed on to the next process.

NAK.  The guarantee is in STD 10, STD 11, 2821, 2822, and 3834.
It's only stripped in scenarios behind mail2fido, mail2outlook,
mail2news, or similar gateways, but not by say POP3 or IMAP.

Frank

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 24 Nov 2006 06:57:01 -0500

----- Original Message ----- 
From: "Charles Lindsey" <[email-masked]>
To: "DKIM" <[email-masked]>
Sent: Friday, November 24, 2006 6:02 AM
Subject: Re: [ietf-dkim] ISSUE: Better definition of "DKIM signing 
complete"required

> to some strawman of your own invention.

Excuse me?  You are the one that doesn't want t be left out in the 
News/Email Gateway world.   But what about the ral news protocol world - 
called NNTP.     You can't have it both ways.  I don't about your Software 
Designs but in our News/Email Software design, you need NNTP in order to 
gate. This implies you will need NNTP considerations in the DKIM protocol 
and DKIM isn't written NNTP.   I seriously doubt you can consider a 
NEWS/EMAIL system without considering all the NNTP issues as well.

> Unfortunately, the world is already way beyond 1 to 1 EMAIL.

You're kidding?  Private mail is obsolete?

> If you introduce DKIM without having previously considered the 
> consequences for all existing practices, then perfectly legitimate things 
> which have always worked will start to fail. And it is DKIM which will get 
> the blame

I don't think so simply because DKIM wasn't design for NEWS/EMAIL gateways. 
I would never phantom to even consider it when the goal of a Mail Integrity 
system is to avoid as much transformations that you can.

> involved in that because, as you correctly said, DKIM does not apply to 

But Charles,  NEWS/EMAIL gateways goes both ways.  Your design would have to 
work in both directions.     If you post via NEWS you are talking about 
GATING to a EMAIL system.  What are the rules here?  Do you hash the NNTP 
required headers?   Do you strip them?    And vice a versa?   Same issues.

> some action by the mailing list admin that it was gatewayed to).

I am not sure I follow but this is exactly one of the protections I want - I 
don't want someone using my domain in such areas

Nonetheless, even if this was a variable consideration it would be a 
augmentation on the 1 to 1 DKIM system.  Otherwise you need to break the 
specs today to include NNTP considerations.

> feature of Usenet. You (TINY) have to live with that.

I do and we design develop and sell a NEWS/EMAIL gateway as well as other 
multi-mail network gateways.  Do you?  So I would like to feel I have a 
pretty good handle on whats realistic or not from all aspects from project 
to product design and development and more important, making it work right 
and friendly with other systems as well.

I think what you asking for is unrealistic and is getting us no where.

---
HLS

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 24 Nov 2006 07:20:00 -0500

----- Original Message ----- 

> where the email _really_ came from.

But it is not the original domain owner.  2822.FROM: is the author which on 
planet earth typically is the ower of the message.  So who is the decider? 
The sender or the author/owner?

> which domain gets to sign the message and which domain's SSP is a verifier 

The first one.  But I admit the proposed algorithm to handle this is not one 
I personally prefer.  However,  I am not too worry about it because we are 
talking about a very rare situation and I still hold the position that any 
one that is going to invest in DKIM is not going to sabotage itself - not 
intentionally :-)

> It is indeed guaranteed to be present, but not guaranteed to contain the 

It is not guranteed to be present.  I wouldn't bet a design to be dependent 
on it simply because it isn't guaranteed to be followed and by far, it 
isn't.

> No, it is NOT a retransmissiom. Read the EAI drafts.

Huh?  You said above "Changed in Transit"  That is by definition a 
retransmission.  Some middle ware/router is doing the "changed in transit" 
right?

>> guarantee it will passed on to the next process.  In fact, many  systems 
>> will STRIP it once it reaches its final destination.

> found, then that is its own stupid fault.

Neat.   But no. This is where some design experience to understand it better 
helps.  Stupid or not,   that is the reality.  You can't depend on it being 
available at the moment a MFA is triggered and you don't know when that MFA 
could be triggered   Just consider Doug' MUA plans.   It ain't going to work 
a good portion of the time simply because the Return-Path will not be in the 
headers.

Thats the facts.

---
HLS

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Nov 2006 07:25:14 -0500

> mail2news, or similar gateways, but not by say POP3 or IMAP.

Sorry, but that is not true. Frank.  If you based your MUA or GATE or 
whatever design to depend on a RETURN-PATH you will be sadly disappointed.

The SPECS only require its for BOUNCE purposes in POST SMTP delivery 
checks and no other reason.  Once thats done, you don't need it - not 
for SMTP or POP3 or IMAP purposes.

It has only because important for the SPAM market.  But the reality is 
that is not guarantee AFTER the delivery status has been determine and
the message saved, gated, fido, news or not.

--
HLS

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 24 Nov 2006 12:31:51 +0000

> No, it is NOT a retransmissiom. Read the EAI drafts.

Which? (There are 8)

I'd be glad to get a better pointer to how EAI and DKIM might
interact,

Ta,
S.

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Nov 2006 08:07:40 -0500

> gatewaying cases, which is where we'd be heading if we start on that

+1.

We haven't completely nail down the integrity alteration or 3rd party 
issues in the pure email spectrum, including list servers, adding 
news/email/other gateways would be a night mare.  I speak from direct 
experience as a author of multi-network gateway systems including a 
News/Email Gateway.  DKIM considerations here would be horrendous, and 
it would require considerations for the NNTP protocol as well.

Thats not to say it can't be done - but it should be based on the BASE 
DKIM system.

For example, in our news/email system, we can expose mail conferences as 
  Local Newsgroups that an RFC news reader can handle.   We have one 
conference called "Support" where incoming EMAIL is gated into.

Well,

Direction #1 - incoming EMAIL

If the original EMAIL is DKIM signed, then our SMTP processor will 
validate it.  Once validated, our gate will move it into the "support" 
conference/newsgroup.

When our support staff reads the newsgroup article, our NNTP Server will 
  make sure the EMAIL is transformed to a proper NNTP article to be 
downloaded.

When our support staff reads the SUPPORT con fence via the web site, it 
looks like a pure EMAIL to them.

In any reading device case, DKIM is already satisfied by the SMTP processor.

Direction #2 - outgoing, replies to support questions

If posting via the RFC NEWSREADER, the NNTP Server will transform the 
NNTP article to EMAIL.

If posting via the Web site, then its a straight forward email.

In either case, the SMTP outgoing process will now DKIM sign the message.

The point here is that the two never mixed up.  DKIM is done on the 
email side.  Not the news side.

Now this is where it really gets hairy.

What if we want the NNTP processor to DKIM sign the message?

It could be done and I see less of an issue if the mail remains as News.

But once you begin to gate,  now what?  Do we strip?  Do we add more 
signatures?

Again, all possible, but we are really but now we will need minimum 
requirements possibly like signing the Path:, Newsgroup: headers, etc 
and then possibly carrying them over in the gate.  Some mail readers 
can't handle a Newsgroup header coming in as an EMAIL.

It will get really messy here IMV.

---
HLS

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 24 Nov 2006 14:17:55 +0100

> that requirement (that you think is reasonable).

LOL, somewhere we're out of sync.  AFAIK we're still discussing
the "requirement-02", is that correct ?  For the "requirements"
we don't need to go into details about gateways etc., but we can
"require" that the future SSP defines 'DKIM signing ciomplete'
in a way understood by anybody considering to publish some kind
of "I sign everything" policy.

IFF "I sign everything" means "reject or even annotate (= drop)
all mails with a 2822-From 'me' without 'my' signature" (incl.
"known" cases of signatures broken by irregular mailing lists),
then the future SSP has to enumerate all "known" cases where it
will cause havoc.

So far we have irregular (mutilating and munging) mailing lists.

Another case are news2mail gateways.  A third case are articles
in moderated newsgroups, depending on how the server forwards it
to the moderator.  USEFOR is about to fix the latter, but until
it's deployed worldwide in Netnews... let's say 2020 or later :-(

There might be more cases (MMS-to-mail, IM-to-mail), I can't tell,
I only know why I don't like PRA.  The SSP-"I-sign-everything" is 
apparently _far_ more restrictive than spf2.0/pra.  We could as
well tell potential users that they can draft a no-nonsense (= no
NEUTRAL) PASS or FAIL PRA-policy.  If they can't figure out that
one they also won't understand WTH "DKIM-signing-complete" is.

They don't need to publish their no-nonsense PRA policy, but they
do need a DKIM-signing agent somewhere on all of its routes.  For
some domains it might be as simple as a decree "we have one MSA --
formerly known as a smart host -- and you're gonna use it or die.
And stay away from mailing lists and Netnews with from-addresses
in this domain".

For other domains wishing to be 'DKIM-signing-complete' it might
be less simple.  For a domain bank.example it could be an idea to
create a subdomain office.bank.example for mails sent "from the
office" (i.e. DKIM-signing-complete).  Maybe the future SSP could
mention this deployment strategy.  Maybe their MSA could rewrite
any From bank.example to From office.bank.example before signing
it.  That's not covered by RFC 4409 at the moment, maybe we need
a son-of-4409 (?)

>> A domain claiming to be 'DKIM-signing-complete' has to be sure
>> that there's some DKIM-signing agent on _all_ routes before one
>> of their spf2.0/pra PASS or NEUTRAL IPs.  Otherwise they screwed
>> up, causing harm for mails "from" their domain.
 
> I think that last is a fair point. But I'm still not convinced
> that it's up to the DKIM WG (now) to figure out all details of
> all such gatewaying cases, which is where we'd be heading if we
> start on that road.

Not *now*, now we IMO only need a requirement that any future SSP
"I sign everything" has to be very clear about its implications.

No weasel words like "annotation as suspicious".  We're talking
about reject or maybe even drop depending on the receiver policy
(if they look at SSP at all).  And no unclear uses of "sender", a
2822-From isn't related to the "sender" in many valid cases.

E.g. the word "sender" in requirements-02 chapter 4.1 4th paragraph
is unclear, apparently it should be "author" if it's limited to the
2822-From.  In chapter 5.3 it's not yet obvious what happened with
Alice's "I sign everything" SSP after Bob resends it.  Did he also
resend her signature ?  Has one of Doug's anti-replay MDAs stripped
her signature ?  What if Bob feels like resending Alice's mail 25
years later, will it still work as expected and required wrt STD 11
and 2822 ?  (Of course not, SHA-256 will be long dead then, the SSP
"I sign everything" concept has also temporal limits.)

The longer I think about it the more I feel that this SSP "I sign
everything" could be handled as special application of spf2.0/pra.
It's in essence the same mess.  Adding "'I' DKIM-sign everything"
_syntax_ to spf2.0/pra is simple, and maybe the SPF folks will add
this _syntax_ anyway IFF the semantics is clear.  

Frank

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Nov 2006 09:17:46 -0500

> of "I sign everything" policy.

This might not be related but I think that we have confuse DKIM in the 
last 5-8 months with these "layman" constructs when really what we 
should be distinguishing it with as "Technical Constructs" such as:

     "The EMAIL SENDER signs everything"
     "The EMAIL OWNER/AUTHOR signs everything"
     "The LIST SERVER signs everything"

etc. To me, this is more technically correct and it allows the 
association with the headers to be more correct.

Now, are you proposing, suggesting, hinting, a new possible technical 
constructs for NEWS?

     "The NEWS SERVER/DOMAIN" signs everything"

To me, the above constructs make them more technical DKIM complete.

---
HLS

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 24 Nov 2006 15:15:53 +0100

> for SMTP or POP3 or IMAP purposes.

I can't recall how often I've posted the relevant part of RFC 3834 in
the last 30 months.  The auto-reply stuff - it already got a normative
reference from the SIEVE-vacation RFC (or maybe it's still a draft, or
an approved draft waiting for its number):

| A Personal or Group responder SHOULD NOT deliver a response to any
| address other than that in the Return-Path field, even if the
| Return-Path field is missing.  It is better to fix the problem with
| the mail delivery system than to rely on heuristics to guess the
| appropriate destination of the response.  Such heuristics have been
| known to cause problems in the past.

It's also used in all kinds of DSNs (not only non-delivery reports),
but as you said that's still within SMTP.  It is also used for MDNs,
that's post-SMTP, see RFC 3798:

| MDNs SHOULD NOT be sent automatically if the address in the
| Disposition-Notification-To header differs from the address in the
| Return-Path header (see [RFC-MSGFMT]).

> the reality is that is not guarantee AFTER the delivery status has
> been determine and the message saved, gated, fido, news or not.

This isn't true.  Don't let some MS calendar software behind their
emulation of groupware muddy the waters, this calendar software is
nice and popular, but no serious Internet MUA.  I can't tell if they
fixed this after 2003, I only know Outlook versions older than 3834
and 3798.

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 24 Nov 2006 15:33:12 +0100

Stephen Farrell wrote:

>> Read the EAI drafts.

> I'd be glad to get a better pointer to how EAI and DKIM might

For the purposes of DKIM look at I-D.eai-framework-03, that's
more or less ready (= post WGLC, pending nits are editorial).
It has an informative reference to the DKIM charter.

The hardcore technical stuff is still far from ready, one of
the points where it will get interesting is a procedure known
as "downgrading" (from UTF8SMTP to traditional message/rfc822),
for a sneak preview see I-D.eai-downgrade-02

Or just look around at <http://tools.ietf.org/wg/eai>.  

I'd feel better if we can shift the "I sign everything" stuff
in SSP to "experimental" (= the same status as EAI and SPF).

Frank

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 24 Nov 2006 14:47:10 +0000

Hi Frank,

Frank Ellermann wrote:
> the "requirement-02", is that correct ?  

Yep.

> For the "requirements"

Correct. I was asking because I couldn't envisage a way to really
meet the requirement without having to go into lots of piecemeal
discussions of other protocols that may re-use (related) header
fields.

If however an SSP protocol spec sentence like: "Everything is
signed using the RFC2822-From domain" was specific enough (forget
for now whether its perfect/ok/plain-wrong or not), then I think
your putative requirement can be handled.

...
> "I sign everything" has to be very clear about its implications.

Good. So for example, qualifying the statement (in the RFC or using
syntactic means) to restrict it to mean "I sign everything that's
sent out via SMTP with the RFC2822-From domain" or somesuch  would meet
the requirement.

> No weasel words like "annotation as suspicious".  

That's a different topic. But one I suspect that inevitably requires
weasel words.

> this _syntax_ anyway IFF the semantics is clear.  

I don't personally know enough so know about that, but I'd be
interested if a bunch of folks felt that way.

So, we've clarified your putative requirement enough now (for me
at least) that I think people can make up their minds as to whether
to accept it or not. (And this is issue#1398 now btw, so we'll be
coming back to decide it thanks to the tracker.)

Cheers,
S.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 24 Nov 2006 15:59:47 +0100

Hector Santos wrote:

> are you proposing, suggesting, hinting, a new possible technical
> constructs for NEWS?

I did that some months ago (early 2006), and it was rejected as too
obscure.  But we have everything in place to adopt DKIM for Netnews
later, most important the registry of canonicalization algorithms -
you've already posted an I-D in this direction.

If "they" (the news server folks) want it, replacing an old existing
system to sign headers.  Maybe they don't want it.  That's IMO stuff
for 2008 after some USEPRO-RFC explaining basic operations without
this feature is ready and on standards track.

For the purposes of an SSP "I sign everything DKIM-complete" today
we can simply state that such domains SHOULD NOT be used in Netnews.

As they SHOULD NOT be used on _irregular_ mailing lists.  Maybe more
cases, we should ask the 'lemonade' folks what they think about this
"I (defined by 2822-From) sign everything DKIM-complete" construct.

Frank

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 24 Nov 2006 15:13:59 +0000

> "I (defined by 2822-From) sign everything DKIM-complete" construct.

Good idea. Do you know who to ask? If so, do so!

Thanks,
S.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 24 Nov 2006 16:23:16 +0100

Stephen Farrell wrote:

> this is issue#1398 now btw, so we'll be coming back to decide it

Yes, we got the same mail with the ticket number from Eliot.  What
about two minor points in this thread:

1 - Is the "sender" in 4.1 4th paragraph actually an "author" ?
2 - What exactly happens with Alice's SSP in scenario 5.3 ?

Should that also get new tickets, or is it obvious / irrelevant ?

Frank

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 24 Nov 2006 15:33:46 +0000

> Should that also get new tickets, or is it obvious / irrelevant ?

They sound sufficiently like new tickets that we might bother
Eliot again:-)

S.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 24 Nov 2006 16:39:16 +0100

Stephen Farrell wrote:

>> we should ask the 'lemonade' folks what they think about this 
 
> Good idea. Do you know who to ask? If so, do so!

I've started to read their list (after subscribing it via GMaNe) less
than a week ago.  Maybe it's better if you try that with a DKIM Chair
hat.  I'd be completely lost if they talk about IMAP, or the wild and
wonderful things they do to combine MSAs with IMAP message stores.

Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 24 Nov 2006 15:48:52 -0000

On Fri, 24 Nov 2006 11:57:01 -0000, Hector Santos <[email-masked]>  
wrote:

> ----- Original Message ----- From: "Charles Lindsey"  
> <[email-masked]>

>> It suggests no such thing. Read what I wrote and respond to that, and  
>> not to some strawman of your own invention.
>
> called NNTP.     You can't have it both ways.  I don't about your  
> Software Designs but in our News/Email Software design, you need NNTP in  
> order to gate.

No you don't. You likely need NNTP in an Email2News gateway, but for a  
News2Email gateway you have just somehow acquired the article (who cares  
whether it arrived by NNTP or not - for sure it was not DKIM-signed), and  
your problem is to construct a valid, DKIM-proof Email out of it.

> You're kidding?  Private mail is obsolete?

No. But a lot of Email is NOT private (this List for a start).

> But Charles,  NEWS/EMAIL gateways goes both ways.  Your design would  
> have to work in both directions.

No it wouldn't. There are Email2News Gateways, and there are News2Email  
gateways, and there are some which try to do both (and doing bidirectional  
gatewaying 100% safely is an unsolved - and probably unsoluble - problem).

  ...     If you post via NEWS you are
> talking about GATING to a EMAIL system.  What are the rules here?  Do  
> you hash the NNTP required headers?   Do you strip them?    And vice a  
> versa?   Same issues.

That is exactly the question this thread is attempting to address. There  
is no question, at the moment, of requiring hashing of anything sent by  
NNTP. The best suggestion so far is that the News2Mail gateway should  
treat it as a resend and add the proper Resent-* headers. And if someone  
can convince me that would solve the problem, then I can try and get that  
written into the upcoming News protocol standard.
>
>> The problem does not arise until someone far away gates that news  
>> article back into email, at which point its lack of a DKIM signature  
>> suddenly gets noticed. ...
>
> I am not sure I follow but this is exactly one of the protections I want  
> - I don't want someone using my domain in such areas

And how, precisely, do you propose to prevent it?

>> IMV, we should stop trying to mix EMAIL vs NEWS - two different things.

Sorry, that horse bolted through the open stable door 15 years ago. You  
just admitted that your own company writes software to do such gatewaying.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 24 Nov 2006 15:53:11 -0000

> gatewaying cases, which is where we'd be heading if we start on that

I think it is up to the DKIM WG to try to spot all the things that are  
likely to break when DKIM starts to be implemented, and to do what it can  
in its drafts to forestall them.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 24 Nov 2006 16:52:35 +0100

Stephen Farrell wrote:

>> What about two minor points in this thread:

> They sound sufficiently like new tickets that we might bother

Okay, I test the RFC 4096 subject magic again... <gd&r>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 24 Nov 2006 16:09:42 +0000

Charles Lindsey wrote:

> That is exactly the question this thread is attempting to address. 

If that is so, then this thread looks to be way out of scope.
Where is that envisaged in our charter?

Stephen.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 24 Nov 2006 16:13:20 +0000

Charles Lindsey wrote:
> likely to break when DKIM starts to be implemented, and to do what it 
> can in its drafts to forestall them.

No. "All" is not reasonable. (Obvious, non-controversial things are
easy, of course, but I've not seen many of those.)

As chair, if someone wants to write up a personal draft explaining
such details then I'd be fine with the group considering its adoption.
(Or inclusion in the overview document.)

I am not fine with considering an unbounded number of possibly
controversial protocol interactions before doing something.

Stephen.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 24 Nov 2006 17:28:18 +0100

First, I see nothing wrong with someone writing a draft for netnews, but 
this is well beyond this group's scope, IMHO.  There are many types of 
mail systems, and they all may require some transformations and some 
special treatment.

Charles Lindsey wrote:
> We don't want the mailing list admin to reject is as being unsigned. 
> Maybe the gateway should have signed it (quite a good edea that, and 
> then the SSP and reputation of the gateway would come into play). But 
> is that sufficient to cover for the lack of a signature by foo.example?
I wonder how much of a real world example this really would be.  I think 
as a mailing list administrator I'd be quite offended that someone 
attempted to gateway in a newsgroup without my permission.  If such 
gatewaying had my permission, then I could decide to accept such 
gatewaying and then choose to ignore the fact that there is no DKIM header.

A more likely case would be where some organization is doing the 
gatewaying to and from a LOCAL newsgroup.  In such cases, it makes 
perfect sense for that gateway to consider signing the message on its 
way into email.  And it should because it is going to monkey with some 
headers that might be previously signed, such as Article-Id and 
Newsgroups.  What's more, NNTP is 8 bit clean (always has been), so you 
may well have to do some monkeying already.

Eliot

---

From: Michael Thomas <[email-masked]>
Date: Fri, 24 Nov 2006 08:47:13 -0800

> Good idea. Do you know who to ask? If so, do so!
Can somebody explain to me what an "irregular" mailing list is?

I'm afraid that some people have a more "composed" idea of SSP than
I do. I think of SSP being two distinct things:

1) An information service provided by a domain which describes what
    it does as mail passes through its infrastructure
2) A mechanism for finding and fetching information provided by the
    service in (1).

I know that we've been talking about rfc2822.from alone with respect to
2 primarily, and that we've been pretty vague about whether the information
service in (1) has anything to do with any other address header. I'm not
convinced that that's right though: our signer at Cisco by policy always
signs messages which correspond to a From: or Sender: or Listid. If
SSP is just an information service, wouldn't it be better to just describe
what we do? There seems to be no particular harm in publishing what
is just a fact.

Whether a receiver wants to find/fetch information related to addresses
is its business alone. We've envisioned From as being the Most interesting
one, but it's not clear that that's _always_ the case, and we certainly
can't prevent a receiver from having an "unapproved" opinion about
which addresses it's interested in.

Long and short, my feeling is: SSP publish what it actually does; describe
the mechanism for looking up anything based on a rfc2822 address, and
just give some non-normative guidance about which addresses might be
interesting. Note also: phrasing things this way avoids the tar pit of 
claims
that we're "solving phishing", etc.

       Mike

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 24 Nov 2006 18:42:52 +0100

> Can somebody explain to me what an "irregular" mailing list is?

A mailing list modifying mails in ways not covered by the relevant
RFCs (1123, 2821, and the List header field stuff).  From our POV
anything that doesn't fly with DKIM.
 
> If SSP is just an information service, wouldn't it be better to
> just describe what we do?

That won't help with mail somehow related to Cisco, where they've
obviously not done what they normally do (because it was sent on
completely different routes, somebody at home maybe), or apparently
not done it (some 'irregular' mailing list destroyed the signature).

Unless Cisco sends passwords or invoices by mail it's no problem,
they won't need any "I sign everything" policy.  Big.bank.example
wants this.

> just give some non-normative guidance about which addresses might
> be interesting. Note also: phrasing things this way avoids the 
> tar pit of claims that we're "solving phishing", etc.

Avoiding that tar pit makes no sense, it's the most interesting
feature in DKIM (or rather in SSP) for many senders and receivers.
Without it DKIM is like an X-Face: header field without picture.

Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 24 Nov 2006 20:40:31 -0000

On Fri, 24 Nov 2006 16:28:18 -0000, Eliot Lear <[email-masked]> wrote:

> attempted to gateway in a newsgroup without my permission.

Sure, it would be most impolite. Normally, the gatewaying would be done by  
the mailing list administrator, or by somebody working in agreement with  
him. And between them they have to sort this one out. But it would be a  
good idea to make sure that sensible ways of sorting it out can be  
devised, because if they can't we need to do some rethinking.

That is why I asked whether adding Resent-* headers by such gateways would  
make things easier. It is not usually done AFAIK, but it sounds a sensible  
and consistent thing to do.

> gatewaying to and from a LOCAL newsgroup.

Yes, in a controlled local environment life is always easier. Maybe in  
that environment you just sign the news as you said, and then the problem  
goes away.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 24 Nov 2006 20:49:50 -0000

> easy, of course, but I've not seen many of those.)

Yes, "All" is clearly an overkill, but we need to look at all scenarios  
that are likely to be common. We have already identified mailing lists and  
resenders as areas that need thinking about. I am just pointing out that  
Gateways from News are another, especially as they appear to provide a way  
for email to "leak" out of domains that claim to be "we sign everything".

Email is generated by all sorts of agents that could hardly be described  
as "MUA"s. Gateways from other media is one of them.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 24 Nov 2006 21:19:54 -0000

> validate it.  Once validated, our gate will move it into the "support"  

Sure. Gatewaying dkim-signed stuff *from* email is no problem.

> If posting via the RFC NEWSREADER, the NNTP Server will transform the  

Yes, that is the interesting case. A news2email gateway is, from the POV  
of this WG, just another agent for generating emails (and as such it is on  
topic if it raises special problems). The fact that it came from NNTP is  
an irrelevance, *except* insofar as it may introduce an unsigned message  
whose From/Sender/whatever is from a domain that claims to sign  
everything. That is something we may need to worry about.

> In either case, the SMTP outgoing process will now DKIM sign the message.

That certainly sounds like one way of tackling the problem. Others that  
have been suggested are to treat it as a Resend, which again probably  
involves (re)signing it. Another is to assert that people whose email  
addresses are within an "always signed" domain MUST NEVER post to Usenet -  
someow I cannot see that one flying. Another is to dkim-sign the original  
news articles from that domain (which might well be the best solution, but  
is way beyond out remit to try to specify it).

So what other methods might there be?
> email side.

Exactly. This is what I have been trying to tell you for the past several  
> What if we want the NNTP processor to DKIM sign the message?

because NOBODY (except yourself) has ever suggested doing such a thing.  
Forget it, and stop muddying the waters.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 24 Nov 2006 21:25:39 -0000

>      "The LIST SERVER signs everything"

At last! You have recognized the real problem. According to whichever of  
these situations is relevant for the particular case, you need to look at  
the From, or the Sender, or some List-*, or whatever else header.

>      "The NEWS SERVER/DOMAIN" signs everything"

That might come some day, but for the forseeable future I think we have to  
plan without that one.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 24 Nov 2006 21:29:58 -0000

> retransmission.  Some middle ware/router is doing the "changed in  
> transit" right?

If an email is changed from Content-Transfer-Encoding: 8bit to  
quoted-printable or base64 as it passes from an 8BITMIME-compliant MTA to  
a Non-8BITMIME-compliant MTA, is that "retransmission", or not?

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 24 Nov 2006 13:32:03 -0800 (PST)

On Fri, 24 Nov 2006, Charles Lindsey wrote:

>> If posting via the RFC NEWSREADER, the NNTP Server will transform the NNTP 
>> article to EMAIL.
>
> Yes, that is the interesting case. A news2email gateway is, from the POV of 
> this WG, just another agent for generating emails (and as such it is on topic 
> if it raises special problems). The fact that it came from NNTP is an 
> irrelevance, *except* insofar as it may introduce an unsigned message whose 
> From/Sender/whatever is from a domain that claims to sign everything. That is 
> something we may need to worry about.

Gatewaying from newsgroup is a case equivalent to email coming from mail list.

Neither one the designers of DK[IM] are particularly interested in dealing 
with as is evident in previous discussions in regards to "3rd-party" 
policy considerations or 3rd-party signers.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 24 Nov 2006 19:35:32 -0500

----- Original Message ----- 

> No. But a lot of Email is NOT private (this List for a start).

Ok, so GROUP and/or GROUP-like mail systems existed for a long time.  That 
doesn't suggest that private communicatons is passe nor is group ware 
systems replacing it.

> gatewaying 100% safely is an unsolved - and probably unsoluble - problem).

Thats my point.  It is a doable concept but when you begin to intoduce DKIM 
into it,  it opens up a whole new set of Campbell Worm Soup :-)

Its like List Servers (LS).  I think everyone agrees LS works fine and has 
been for a long time.   But now we introduce DKIM and now we are dealing 
with design concepts which may requires LS design alterations and people are 
resistant to this.  We are trying to make DKIM work with LS systems and its 
nearly impossible (DKIM isn't going to be very effective in LS in its 
current state).

> written into the upcoming News protocol standard.

I think it is a separate consideration that needs to fit on top of DKIM. 
There might have to be updates to the specs to might include NNTP 
considerations for NNTP required headers, for example, newsgroups:, path:.

IMV, for a pure NNTP environment, the DKIM implementation is clearer.  It is 
the gating part of it is where it gets really murky because now we are 
dealing with transformation issues.   And even if we limit this to one 
direction,  we must make sure that "other direction" doesn't become a 
loophole threat.

>> I am not sure I follow but this is exactly one of the protections I 
>> ant  - I don't want someone using my domain in such areas

> And how, precisely, do you propose to prevent it?

With SSP! <g>

> Sorry, that horse bolted through the open stable door 15 years ago.

(for longer than that)

> You  just admitted that your own company writes software to do such 
> gatewaying.

Right. And one would naturally think I would be among the first to support 
this if its was that easy to do. But I can immediately see the major issues 
across the board from point to point.  This thread hasn't even touch base 
with 1% of all the issues that needs to be considered to implement DKIM in a 
news/email system environment.   For a pure NNTP newsgroup system?  Sure, 
very doable. But Gating?    That will be very complex.  Not saying it can't 
be done.  But I believe it would be a whole different of rules that are 
beyond the current DKIM/SSP specification.  It would be a new RFC that is 
based on the DKIM/SSP RFCs.

Given the current specs, can you itemize what are the issue "transformation" 
issues in order to maintain mail integrity and SSP security?  IMV, it has to 
be both ways. Not just one way.

----
HLS

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 24 Nov 2006 20:07:05 -0500

> Sure. Gatewaying dkim-signed stuff *from* email is no problem.

Agreed.

>> .....

> The point here is that the two never mixed up.  DKIM is done on the  email 
> side.

> days,

I believe I quoted, "Never the twain shall meet."  from the get-go.

>> but you always come back to raising Red Herrings such as:
>>

> Forget it, and stop muddying the waters.

I'm sorry Charles, but I am not in a habit of doing an "half-ass" design 
work.  Its not in my nature and since we do have a product in this area, I 
probably do have an "advantage" of seeing more issues than you probably do.

If you want a NEWS/EMAIL gateway support, then there I don't see you getting 
getting very far with support for this without considering the NNTP posting 
issues which does include  the concept of NNTP servers creating signed mail 
in order to handle the NEWS ONLY MUA market.

---
HLS

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 24 Nov 2006 21:37:17 -0500

----- Original Message ----- 
From: "william(at)elan.net" <[email-masked]>

> Gatewaying from newsgroup is a case equivalent to email coming from mail 

+ 0.8  See below.

+1.

While I agree that the News/Email gating design is nearly equivalent to a 
mail list, there are many different considerations.

The main one off the top my head is that you don't really have to transform 
a list distribution because it is already within an EMAIL spectrum.

This is not quite the case with a NEWS2EMAIL or a EMAIL2NEWS gate simply 
because there are issues when mixing headers.

One good example is a MUA receiving a popped in email, but when it comes to 
the "natural reply" (not Forwarding or Reply to All) it see its as a NEWS 
ARTICLE because it sees a newsgroup: header, hence the NewsGroup Message 
Input Dialog box appears.

To reply back to the author, you have to Reply to All.

Sort of like the opposite with Mailing List "Natural Reply" issues where 
some LS systems will force the Reply-To: to the list address so that the 
natural reply goes back to the list.   Otherwise, you have to Reply to All 
to write to the list (and the author too).

The main point is that the in this case, the gate failed to remove the 
newsgroup: header when moving the mail into an email spectrum.

But yes, in general, it is nearly the same type of scenario as a LS with 3rd 
party considerations, transformation or mail alteration integrity issues, 
etc.

---
HLS

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Nov 2006 22:00:17 -0500

> Can somebody explain to me what an "irregular" mailing list is?

Same here.

> claims that we're "solving phishing", etc.

I agree. I think. :-)

To me, SSP has always been just exposing what the ORIGINAL DOMAIN OWNER 
is saying about its DKIM signed or not mail.

Al thought the natural tendency is to use this information as part of, 
what I tend to believe, is a strong deterrent to directly domain 
exploitations,  how a receiver reacts has always been a local policy 
decision.

As a vendor, I can't force these decisions to the admin. I have to give 
him the options.   However, I have to also decide is what are the 
defaults and also provide "guidelines" to the admin in how to use it.

I agree with you the 3rd party issue has been a contested one.  I 
thought it was addressable via SSP.

However, some feel it is too much and I don't mind saying it also seems 
soon feel "threaten" by having 3rd party restrictions.

In the end of the day, in my view, the first segment of the population 
that we must address is the first party people.  I think DKIM/SSP does 
that very nicely.  As long as SSP allows the 1st party to declare strong 
and exclusive policies, I strongly believe we have a major winner.

The relaxed conditions, however, which we are still trying to address, 
will always introduce all kind of problems and issues.  Just like it 
does today with the relaxed provisions in SMTP.

Anyway, my two pennies.

---
HLS

---

From: John Levine <[email-masked]>
Date: 25 Nov 2006 03:44:35 -0000

>First, I see nothing wrong with someone writing a draft for netnews,
>but this is well beyond this group's scope, IMHO.

Having written and run my share of gateways between mail and usenet
over the past 25 years, I have to agree.  Mail and news are similar,
but they are different enough that I've always had to futz with
headers on the way through.

It's perfectly reasonable to think about putting DKIM signatures on
news messages, and it may well be possible to define a useful common
header subset so that you can sign a message and successfully transmit
it both over both SMTP and NNTP.  But it'd be a major overstretch at
this point to say anything at all about NNTP in the current DKIM
effort.  We have no experience with DK or DKIM signed news and no
experience with passing signed messages through mail <-> news
gateways.

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Fri, 24 Nov 2006 21:50:14 -0800

william(at)elan.net wrote:
>
> Neither one the designers of DK[IM] are particularly interested in 
> dealing with as is evident in previous discussions in regards to 
> "3rd-party" policy considerations or 3rd-party signers.
>
Your use of "neither one" in this context rather than "none of" implies 
there are only two designers, when in fact there are quite a few more.

SSP and DKIM itself are under control of the Working Group.  If there is 
consensus to do things differently, as there was with the body hash 
mechanism in -base, the original designers are likely to contribute 
their comments, but it is the WG consensus that rules.

I gather you are advocating a requirement that SSP queries be made for 
other addresses in addition to the From address.  Doug Otis's draft 
suggests this as well.  If this is the case, I suggest you ask for an 
issue to be opened on the issue tracker requesting the change you have 
in mind, such as "SSP should also be queried for the {Sender, 
Resent-From, Resent-Sender, List-ID, Reply-To, ...} header fields.  It 
would be helpful to also explain (1) the benefit of doing so, and (2) 
how SSP results from the different header fields should be combined.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Fri, 24 Nov 2006 22:25:27 -0800

Charles Lindsey wrote:
> decider, and only the From if Sender is absent. People keep ignoring 
> the fact that there can be several addresses in a From header (in 
> which case Sender is obligatory).
It's not entirely forgotten; section 2.3 of draft-allman-dkim-ssp-02 
discusses multiple From addresses.  We thought about resolving the 
ambiguity by (1) arbitrarily picking the first address in the From 
header field, (2) picking the address in the Sender header field, or (3) 
querying SSP for all addresses in the From header field, and combining 
them somehow.  We picked (1), because we don't know whether the MUA is 
going to display the Sender address or not, and we felt that it is 
likely that it will display the first From address regardless.  But we 
don't know how this will be displayed, and who the recipient is likely 
to consider the author of the message, so it's very difficult to decide 
the right thing to do.  It's currently a very rare circumstance, so our 
main priority here is to minimize the possibility that it becomes common 
by virtue of becoming an SSP exploit, which we (the authors, not the WG) 
felt favored (1).
> out. Hopefully, the resender will have preserved the Signature put 
> there on behalf of the original Sender. If the Resender also "signs 
> everything", then an extra signature should be picked up there.
There is a lot of question in my mind whether the fact that the resender 
signs everything is relevant to the verifier.  Since the Resent-From 
header field is not very visible to recipients in my experience, an 
attacker is just likely to pick a Resent-From domain that doesn't make 
any SSP assertions.
> signed is wrong. It should have been the Sender, and maybe any 
> Resent-From too. And that MUST is going to haunt us again when EAI 
> happens, because both From and Sender may well get changed in transit. 
> Not clear how EAI is going to get around that, but that obligatory 
> From signing is not going to make that job any easier.
The language here was discussed and determined by WG consensus.  
Personally, I favored the language in -base-03 and earlier that says, 
"any header field that describes the role of the signer (for example, 
the Sender or Resent-From header field if the signature is on behalf of 
the corresponding address and that address is different from the From 
address) MUST also be included." But that was not the WG consensus; 
instead, it was decided that this was an aspect of how the signature is 
used and interpreted rather than the validity of the signature itself.

-Jim

---

From: "william(at)elan.net" <[email-masked]>
Date: Sat, 25 Nov 2006 06:13:35 -0800 (PST)

On Fri, 24 Nov 2006, Jim Fenton wrote:

>> with as is evident in previous discussions in regards to "3rd-party" policy 
>> considerations or 3rd-party signers.
>> 
> Your use of "neither one" in this context rather than "none of" implies there 
> are only two designers, when in fact there are quite a few more.

'Neither one' means neither 'Mail List' nor 'Newsgroup' scenarios which
is what the subject of my previous sentence was.

> consensus to do things differently, as there was with the body hash mechanism 
> in -base, the original designers are likely to contribute their comments, but 
> it is the WG consensus that rules.

Workgroup often means people in support of the original idea who are
willing to work on it further. However in cases when WG charter is
limited in scope and with specific drafts in mind, the participation 
narrows down to largely only those supporting those drafts or their
authors.

> I gather you are advocating a requirement that SSP queries be made
> for other addresses in addition to the From address.

As I said many times the identity should in itself be a scope - in
case of SSP that would mean that lookup should be for "_from._policy."
prefix to allow for future expansion. However I'm not actually advocating 
working on identity other then "From" header field at this time although 
I think that current definition and especially due to "From" being able
to consist of multiple addresses would lead to you seeing "From" address 
changed by intermediate agents which has not been case in email so far.

That said I was referring to WG not being interested in working out
mail list cases (which was always the DK's problem) which would
involve signature that is more likely to path through (and still
be verifiable after) mail lists and similar redirectors and working
out policy system that takes existence for such redirectors and
that some domain users often use them into account.

---

From: Michael Thomas <[email-masked]>
Date: Sat, 25 Nov 2006 11:16:27 -0800

Jim Fenton wrote:
> If this is the case, I suggest you ask for an issue to be opened on 
> the issue tracker requesting the change you have in mind, such as "SSP 
> should also be queried for the {Sender, Resent-From, Resent-Sender, 
> List-ID, Reply-To, ...} header fields.  It would be helpful to also 
> explain (1) the benefit of doing so, and (2) how SSP results from the 
> different header fields should be combined.

Um, huh? Why should we care how they're combined, assuming they'd
be combined at all? I view the use of SSP as completely outside of the
scope of this working group, just like we're not saying a DKIM signature
has any _defined_ purpose.

As far as benefit, insofar as people have been taking a "you break it,
you own it" stance on dkim-base, wouldn't it be interesting to know
the signing policy of the new owner too? Note that there is nothing
we can do to prevent such an inquisitive receiver. The feature seems pretty
marginal to me, though it does have a nice symmetry about it -- and fully
supporting it in SSP would be pretty simple.

       Mike

---

From: Eliot Lear <[email-masked]>
Date: Sun, 26 Nov 2006 10:03:50 +0100

Frank,
> Should that also get new tickets, or is it obvious / irrelevant ?

If you want issues opened, please include "new issue" in the subject, 
one per message.  Please include at least something more descriptive 
than the above so people understand what precisely the issue is.

Thanks,

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Sun, 26 Nov 2006 10:14:36 +0100

Jim,

I agree with what others have said, that the netnews, two way pager 
gateways, and mailing lists are all substantially the same, except for 
one key thing: in the case of mailing lists it WILL be possible in some 
way for those systems to preserve the signature, should they so choose.  
That leaves the cases.  Here, the simple answer is that a message must 
make it TO the originating domain to be signed.  That's a change, but 
not a huge one from my perspective.  Some GPRS based phones already let 
you specify a mail system.  There is a business model issue that 
potentially gets in the way, but I'm not sure we should code to it.  
Netnews is a separate case, but again not worth delving into here.

Eliot

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 26 Nov 2006 11:27:48 +0100

> If you want issues opened, please include "new issue" in the subject,

I used "ISSUE:" as subject tag triggering #1398, therefore I sticked
to what worked in <http://permalink.gmane.org/gmane.ietf.dkim/6566>.

> Please include at least something more descriptive than the above so
> people understand what precisely the issue is.

The issue is Alice with an "I sign everything" SSP.  Bob resends her
mail, he has no clue what SSP and DKIM are, his MUA also doesn't know
it, and maybe his ISP removed Alice's signature at the MDA (proposed
by Doug as naive anti-replay strategy some months ago).

Would the next hop check Alice's SSP (ignoring Bob's Resend-* header
fields) and reject Bob's mail, if Alice's signature didn't survive
the resending ?  Or if her signature is too old.

A related question is "what is a 'sender' in paragraph 4 of 4.1 ?",
if you think it should get its own ticket it's okay.

Frank

---

From: John Levine <[email-masked]>
Date: 26 Nov 2006 16:16:19 -0000

>way for those systems to preserve the signature, should they so choose.  

It's possible in all cases, should the gateway choose to encapsulate
the incoming message inside a MIME message/rfc822 wrapper or the like,
but that's not going to be very useful in practice.

News gateways and mailing lists are similar in that a signature might
survive either in some limited simplistic cases, is unlikely to
survive either in a more realistic general case, and we have no
consensus about whether that's a problem, or if we have any advice to
offer beyond recommending that the gateway or list add its own
signature on the way out.

So my suggestion continues to be that we should note that gateways are
rarely transparent to DKIM and leave it at that.

R's,
John

---

From: "Hector Santos" <[email-masked]>
Date: Sun, 26 Nov 2006 14:36:08 -0500

----- Original Message ----- 
From: "Frank Ellermann" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, November 26, 2006 5:27 AM
Subject: [ietf-dkim] Re: ISSUE: Better definition of"DKIM signing complete" 
required

Frank,

Do MUAa resend, forward messages with original headers included?   Are we 
talking about an MUA or a MTA (router)?

In principle, MUAs do not route,  they create new messages.

Am I missing something here?

---
HLS

---

From: Hector Santos <[email-masked]>
Date: Sun, 26 Nov 2006 16:37:37 -0500

> that some domain users often use them into account.

I agree with your comments.

As I outline in many of my technical postings,  I tried to see what it 
will take at a minimum to make DKIM fit into a LS environment and still 
offer the highest possible DKIM protection.

What this is means is what do I have to change in our LS to make DKIM 
work "at a minimum."

I don't see how you can do this without considering SSP as a 
"Controlling" concept.

The simplest is a LS preventing the usage of a mailing list for a highly 
  exclusive DKIM/SSP domain.   To me, that is paramount.  We must 
satisfy this requirement first.

     - LS should check SSP during the subscription process to make sure
       a domain is not restrictive.

We must work on the basis that a DOMAIN may want to use DKIM in a highly 
exclusive, bar none, 1 to 1 communications environment only.  That is 
the highest protection DKIM an offer.  We can't ignore this.

After that, it gets relaxed and murky as to how to keep this DKIM 
security intact with various relaxed conditions.  But we must satisfy 
the ideal condition and that is the strong and/or exclusive SSP policy.

At this point, we then look at new features to support the DKIM LS 
implementation such as:

   [_] Do not change subject line for DKIM signed mail
   [_] Do not change BODY for DKIM signed mail.

In sure a scenario, the LS becomes a pure distribution/passthru like 
system.  Keep in mind that thus far, its not about a LS resigning mail. 
  But first preventing errors and maintaining mail integrity first.

But what if the admin wants to "alter" the message, at this point, we 
are talking about resigning concepts with a bunch of new options to 
handle this.

So it gets really crazy in order to do this correctly.

---
HLS

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 26 Nov 2006 23:20:11 +0100

> Do MUAa resend, forward messages with original headers included?   Are
> we talking about an MUA or a MTA (router)?

We're talking about the Resend-* header fields as specified in STD 11,
RFC 2822, and RFC 4406 7.3.  I can't believe that I quote Sender-ID :-(
 
> Am I missing something here?

No idea, same situation as 30 months ago:  I never got a Resend-* mail,
I never sent one, and as far as I'm concerned this mechanism should be
deprecated in favour of a proper MIME message/rfc822 (or a similar EAI
message/utf8smtp, if that's how EAI eventually solves its MIME issue).

Even clarifying 4409 8.1 (it doesn't discuss Resend-Sender) is a royal
PITA, one SHOULD too much, and it's back at PS instead of going forward
from DS to STD.  IMO we need 4409 at STD more urgent than Resend-cruft.

Who on earth needs more or less than one address in a Resend-From, 
justifying to use a Resend-Sender ?

Frank

---

From: Jim Fenton <[email-masked]>
Date: Sun, 26 Nov 2006 17:40:05 -0800

Eliot Lear wrote:
> one key thing: in the case of mailing lists it WILL be possible in 
> some way for those systems to preserve the signature, should they so 
> choose.  That leaves the cases.  Here, the simple answer is that a 
> message must make it TO the originating domain to be signed.
That's only true if the gateway is to apply a first-party (originator) 
signature.  The netnews gateway can still apply its own signature to the 
message it originates, just like a mailing list.  Many netnews gateways 
will be able to apply an originator signature on locally-posted 
messages, in any case.  I see this as being very analogous to the 
mailing list case.

Applying DKIM signatures to netnews messages is an interesting idea, and 
worth further thought, but is outside the (current) working group charter.

-Jim

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 27 Nov 2006 11:57:54 -0000

> At this point, we then look at new features to support the DKIM LS  

AFAICS, a List Expander has the following options:

1. Ignore DKIM. Pretend it doesn't exist.
    The result of that is that list members (or their ISPs) will start  
regarding some messages with "suspicion", and maybe drop them. List  
members wll not be pleased.

2. Refuse to subscribe (as contributors) sites with exclusive SSP policies.
    Will work, but will piss off people from such domains who want to  
participate.

3. Manage the list so that signatures still work after passing through.
    I.e. don't change 'critical' headers, don't add stuff at the end of  
bodies, etc.

4. Resign all messages yourself.
    Essentially, you are saying "I realise I may have broken the existing  
signature, but I assure you I verified the original signature and checked  
that it complied with the sender's SSP, and my new signature encompasses  
an X-verified header I added to testify to those checks. Trust me! I am a  
Good Guy!"

    And then you hope that your reputation is good enough that your highly  
suspicious recipients will indeed believe that you are a "Good Guy".

So, is that a good summary of strategies that have been discussed on this  
list, or are there others? And are they good enough (#4 seems the best  
approach to be, or maybe #3 and #4 together)?

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 27 Nov 2006 12:53:47 -0000

On Sat, 25 Nov 2006 06:25:27 -0000, Jim Fenton <[email-masked]> wrote:

> likely that it will display the first From address regardless.

And there I think you picked the wrong one. Why is whether the Sender  
header gets displayed by the MUA of relevance (though a decent MUA should  
give you the option of showing it)? Surely it is the MTA/MDA that does the  
verifying and that queries the appropriate SSP that needs to consider  
whether to use the Sender: or From: (for sure, full headers are available  
for inspection at that point). So I think you should have picked #2.

OTOH, if you or your MUA are sufficiently sophisticated to want to do the  
checks yourself, then you are presumably sufficiently sophisticated to  
cause the Sender: to be displayed.

I have seen sufficient comments from others to the effect that the Sender  
needs to be looked at in many situations that this matter probably ought  
to be reviewed (does that mean raising an Issue?).

Actually, I think we are all asking the wrong question, by starting from  
some header (From/Sender/Whatever). Surely a proper verifier should  
proceed something like this:

For each signature accompanying the message:

    Consider the Domain that created the signature

    For each relevant header (From, Sender, List-Post, etc)

       Note whether that Domain occurs in the address(es) in that header

    Consider the SSP of that Domain:

       Is the set of headers including (or not including) that Domain
       correct/reasonable/whatever?

Combine results from all signatures to arrive at final  
conclusion/score/whatever.

>  But we don't know how this will be displayed, and who the recipient is  
> likely to consider the author of the message, ...

I think it is more important who the  
originating/resending/forwarding/signing/SSP domain considered to be the  
author/sender.
so it's very difficult to decide

>> Resent-From too. And that MUST is going to haunt us again when EAI ...

> address) MUST also be included."

Yes, Im think you were right there, and if I had been a WG member at that  
time you would have had my support (though maybe not all the way up to  
"MUST"). I think it is up to verifiers to decide whether the correct  
headers have been signed to enable them to form a valid conslusion. For  
example, if the verifier saw that the message had been downgraded by EAI,  
it might take a very different view of which headers it wanted to see.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 27 Nov 2006 13:07:02 +0000

Charles Lindsey wrote:
>> header field, (2) picking the address in the Sender header field, or 
>> (3) querying SSP for all addresses in the From header field, and 
>> combining them somehow.  We picked (1), because we don't know whether 
>> the MUA is going to display the Sender address or not, and we felt 
>> that it is likely that it will display the first From address regardless.
> 
> And there I think you picked the wrong one. 

Fair enough that you disagree, but the main point though is that
the WG reached rough consensus.

> I have seen sufficient comments from others to the effect that the 
> Sender needs to be looked at in many situations that this matter 
> probably ought to be reviewed (does that mean raising an Issue?).

No. For base, Barry and I are using a scheme where re-opening a
decided issue (which is what you'd presumably like in this case)
requires N people supporting, for some informally defined, but
increasing, value of N (the value increases as we get closer to an
RFC). Absent an absolute storm of support, we're done on this
(and by a storm I mean >>1 voices).

So sorry but its just too late,
Stephen.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 27 Nov 2006 14:18:47 -0000

> way for those systems to preserve the signature, should they so choose.

The one important difference, from our POV, between netnews and mailing  
lists, is that mailing lists get their input by email, and hence it will  
likely come already signed.

Not so with Netnews, and not so if the netnews article is then gatewayed  
into some mailing list. And the problem there (and the only one this WG  
might need to think about wrt Netnews) is that this can then cause a leak  
of unsigned messages from domains that claim to "sign everything".

> not a huge one from my perspective.

It seems a helluva big change to me.

All email leaving sign.all.example gets signed. So far so good.

But news articles posted from sign.all.example don't get signed, because  
they depart via NNTP rather than SMTP.

The unsigned article arrives at news.gateway,example who wants to submit  
it, as an email, to somelist@lists,gateway.example. Now you are saying  
that it has to be routed somehow from news,gateway.example, via  
sign.all.example, to lists.gateway.example. How are you going to do that,  
given that it needs the cooperation of sign.all.example which has never  
even heard of gateway.example, which is propably on a different continent  
anyway?

Here are all the possible solutions to this problem that have been  
suggested so far:

1. Employees at sign.all.example are FORBIDDEN to post News articles.

2. The admins at sign.all.example arrange to sign all outgoing NNTP  
traffic. Not envisaged by any standard, but it will work OK.

3. Either news.gateway,example or lists.gateway,example resigns the  
article. Will the verifiers of the ultimate recipients regard that as  
acceptable? Depends on the reputation of gateway.example.

4. Either news.gateway.example or lists.gateway.example treats the  
gatewaying operation as a Resend, and add appropriate Resent-* headers.  
And probably resigns it as well. Will that make the verifiers of the  
ultimate recipients any happier? I am doubtful, but I have not yet seen a  
clear description off what Resenders are supposed to do. And it is NOT  
customary (it is even deprecated) for list expanders to add Resent-*  
headers.

5, News.gateway,example somehow arranges the article to take a trip via  
sign.all.example to pick up a signature, as you appeared to be suggesting  
above. Fine, if you can arrange for it to happen.

Assuming we can form some opinion on the relative merits of these  
approaches, where should we report that? The overview document, I should  
think, or wherever we report on what mailing lists should do. Our charter  
says:

     The specifications will also advise mailing lists on how to
     take advantage of DKIM if they should choose to do so.

I think it is a reasonable extrapolation from that to consider gateways  
 from Netnews to mailing lists at the same time, because of the  
similarities and differences between the two cases as discussed above. But  
I woulddn't want to consider Netnews any further than that limited topic

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 27 Nov 2006 14:39:49 +0000

Charles Lindsey wrote:

> think, 

Correct. Why don't you write up a fwe paragraphs on this and send
it to the list/authors for inclusion somewhere there?

 > or wherever we report on what mailing lists should do. Our
> charter says:
> 
> similarities and differences between the two cases as discussed above. 
> But I woulddn't want to consider Netnews any further than that limited 
> topic

That sounds about right (esp. if we've a knowledgeable volunteer
writing text:-)

Cheers,
S.

---

From: Hector Santos <[email-masked]>
Date: Mon, 27 Nov 2006 12:43:33 -0500

Charles Lindsey wrote:
> On Sun, 26 Nov 2006 21:37:37 -0000, Hector Santos 
> <[email-masked]> wrote:
> 
>> We must work on the basis that a DOMAIN may want to use DKIM in a 
>> highly exclusive, bar none, 1 to 1 communications environment only.  
>> That is the highest protection DKIM an offer.  We can't ignore this.
>>
> signature, but I assure you I verified the original signature and 
> checked that it complied with the sender's SSP, and my new signature 
> encompasses an X-verified header I added to testify to those checks. 
> Trust me! I am a Good Guy!"
> 
>    And then you hope that your reputation is good enough that your 
> highly suspicious recipients will indeed believe that you are a "Good Guy".
> 
> So, is that a good summary of strategies that have been discussed on 
> this list, or are there others? And are they good enough (#4 seems the 
> best approach to be, or maybe #3 and #4 together)?

I think #1 include those who are just unaware of DKIM, legacy software.

I think #2 is the most practical support and probably most likely the 
first thing a list server author will do. I'm speaking as one.  I think 
this is something all "signup concepts" will look at because it is very 
easy to do and helps "Email/Signup Verification" process.

I think once the decision is made to support DKIM, which inherently 
includes #2, is to begin offering options to not alter the integrity 
(#3) and also offer resigning (#4) when possible.

The 5th item is STRIP and RESIGN as 3rd party

The 6th item is STRIP and RESIGN as 1st party in behalf of the original 
domain.

So there are all known or already discussed scenarios.  These was 
written in various places, including the DSAP I-D.

However, the key, IMTO, is SSP. All middle ware interfacing is only 
technically and consistently correct if the DOMAIN allows for 3rd party 
senders and/or 3rd party DKIM resigning, fingerprints.

---
HLS

---

From: Douglas Otis <[email-masked]>
Date: Mon, 27 Nov 2006 14:20:53 -0800

On Nov 24, 2006, at 8:47 AM, Michael Thomas wrote:

> Stephen Farrell wrote:
>> Frank Ellermann wrote:
>>>
>>> As they SHOULD NOT be used on _irregular_ mailing lists.  Maybe  
>>> more cases, we should ask the 'lemonade' folks what they think  
>>> about this "I (defined by 2822-From) sign everything DKIM- 
>>> complete" construct.
>>

s/irregular/typical/

> 1) An information service provided by a domain which describes  
> what  it does as mail passes through its infrastructure
>
> I know that we've been talking about rfc2822.from alone with  
> respect to 2 primarily, and that we've been pretty vague about  
> whether the information service in (1) has anything to do with any  
> other address header. I'm not convinced that that's right though:  
> our signer at Cisco by policy always signs messages which  
> correspond to a From: or Sender: or Listid. If SSP is just an  
> information service, wouldn't it be better to just describe what we  
> do? There seems to be no particular harm in publishing what is just  
> a fact.

Provided value is obtained, yes.  Rather than just potentially  
disruptive assertions that "all" messages of a particular header  
should be signed (which breaks many normal uses of email),  
associating a signing-domain with more than just email-addresses  
found in headers should also be included.

1) Whether a signing domain is associated with SMTP client.  When the  
signing domain is used for white-listing messages, the value is  
avoiding possible replay abuse.

2) Knowing whether the signing-domain is associated with the  
MailFrom.  The value is ensuring return of DSNs.

3) Associate email-address domains with the signing-domain.  The  
value would be elimination of sharing private-keys, DNS delegation,  
or CNAMEs at the selectors following special arrangements with email- 
address domain owners with their providers.  (Overcomes unscalable  
administrative overhead.)

> Whether a receiver wants to find/fetch information related to  
> addresses is its business alone. We've envisioned From as being the  
> Most interesting one, but it's not clear that that's _always_ the  
> case, and we certainly can't prevent a receiver from having an  
> "unapproved" opinion about which addresses it's interested in.

When delivery integrity is improved, there is greater choice for the  
domain owner, better abuse oversight for transmitting entities, and  
administrative overhead reductions for both the domain owner and the  
provider, these association options should not be excluded from  
careful consideration.

> Long and short, my feeling is: SSP publish what it actually does;  
> describe the mechanism for looking up anything based on a rfc2822  
> address, and just give some non-normative guidance about which  
> addresses might be interesting. Note also: phrasing things this way  
> avoids the tar pit of claims that we're "solving phishing", etc.

The only reason for limiting assertions to the From header is to  
support a false claims about anti-phishing protection.  Assessments  
regarding reduction in abuse often overlook adaptation by the bad  
actors, and how such a strategy ultimately reduces the integrity of  
email delivery, increases susceptibility to spoofing, and creates DNS  
traffic where perhaps only very small percentage might have value,  
even assuming sweeping adoption by receiving entities.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 28 Nov 2006 12:48:43 -0000

On Mon, 27 Nov 2006 13:07:02 -0000, Stephen Farrell  
<[email-masked]> wrote:

>>> combining them somehow.  We picked (1), ...

> increasing, value of N ....

That is fair comment, but there seem to be an awful lot of people still  
discussing the Role of Sender (and even List-ID and Return-Path) as  
possible signing domains.

OK, this is a petition for reopening this Issue. That gives 1 vote, but  
you will need lots more to take action. So I invite anyone else who  
supports this view to reply with a +1. If there is insufficient support,  
then I will shut up.

Here are a few examples of recent posts which seem to want to explore  
these alternatives:

John Glube		15 Nov 2006 14:33:54 -0500
Frank Ellerman	22 Nov 2006 21:24:52 +0100
Hector Santos	24 Nov 2006 09:17:46 -0500
Michael Thomas	24 Nov 2006 08:47:13 -0800
Douglas Otis	27 Nov 2006 14:20:53 -0800
Charles Lindsey	27 Nov 2006 12:53:47 -0000

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 28 Nov 2006 13:04:25 -0000

>>    Essentially, you are saying "I realise I may have broken the  
>> existing signature, but I assure you I verified the original signature  
>> and checked that it complied with the sender's SSP, and my new  
>> signature encompasses an X-verified header I added to testify to those  
>> checks. Trust me! I am a Good Guy!"

> The 6th item is STRIP and RESIGN as 1st party in behalf of the original  

The difference in those last two is that they STRIP the old signature, I  
presume? Why should that help? Throwing away possibly useful information  
is not usually beneficial.

The last one, presumably, requires cooperation between the list admin and  
the original domain. Fine if that can be arranged, and if a highly  
sensitive original domain knows that it, or its users, partakes in some  
particular list, then well worth setting up. But too much to expect for  
the average domain and the average list.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 28 Nov 2006 08:28:33 -0500

> supports this view to reply with a +1. If there is insufficient support,

-1 Change this and you are well on the road to replicating SenderID.  Let's 
not do that.

Scott K

---

From: Eliot Lear <[email-masked]>
Date: Tue, 28 Nov 2006 14:37:05 +0100

Charles,

Forgive my sloppy message, but netnews *is* a separate case, and I'm not 
going to go there with you on this list (others already have).  Mail / 
Unicast mechanisms require either 3rd party authentication or the 
message to flow back to the 1st party through some authenticated and 
trusted chain.  So, for instance, consider GPRS.  If I have an email 
address [email-masked] that I want to use to send mail from my phone, 
then either I use my corporate MSA or there is a third party record of 
some sort for my provider.  Those are really the only two possibilities, 
and neither of which is a substantial architectural change.

Eliot

---

From: Hector Santos <[email-masked]>
Date: Tue, 28 Nov 2006 09:15:21 -0500

> possible signing domains.

Why are you stuck on Sender?  It is not the author or owner of the
message and that is whats important in DKIM.

> Charles Lindsey    27 Nov 2006 12:53:47 -0000

Charles,  my apology if I gave the wrong impression, but the only
connection to Sender: is whats already defined over the last few years 
in the DKIM-BASE and SSP specification - the binding that helps define 
the 3rd party.

I an convinced SSP must be anchored off the 2822.FROM domain.

I thought this thread was merely a postmortem Coffee or Bar chat, which
I need to stay away from and attend a few meetings instead. :-)

I'm not interested in exploring "Sender Header as the Signing Domain."

---
HLS

---

From: Hector Santos <[email-masked]>
Date: Tue, 28 Nov 2006 09:21:45 -0500

Charles Lindsey wrote:
> On Mon, 27 Nov 2006 17:43:33 -0000, Hector Santos 

>> The 6th item is STRIP and RESIGN as 1st party in behalf of the 
>> original domain.
> 

It depends on what you consider useful. Is failure useful?

First note, currently the DKIM-BASE specs make stripping a crime and
failure a disappearing act.

In principle, the goal is to keep the mail integrity intact. For a
middle ware environment such as a List Server, stripping may be the only
viable option because when you add another signature (due to alterations 
  made), you will end up with a failure and a success.

It depends on how mixed failure and success is interpreted.  DKIM-BASE
says as long as one signature is valid in a multi-signature message, the
message is valid.  Failures MUST be ignored as if it was never signed.

There is something not very kosher with that.  I find that to be a
fundamentally flawed concept prune to exploitations.  As you note next,
there needs to be some cooperation in what is expected or is allowed.

> The last one, presumably, requires cooperation between the list admin 
> and the original domain. 

Correct, and my proposal is this cooperation is done via SSP.

> But too much to expect for  the average domain and the average list.

Nothing average about DKIM and in a small way, I think that has
contributed to the lack of consensus in a few areas. We are trying to
make a DKIM, a mail integrity technology, an "average" part of the
entire mail process and is nearly nearly impossible without a total 
system revamp of all the different mail processors.  Its like trying to 
make DKIM work with UseNet. :-)

---
HLS

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 28 Nov 2006 16:17:06 +0100

> message and that is whats important in DKIM.

If the sender is different from the From address(es) it's clearly
not the author.  But at that time it's the owner, responsible for
many technical details, Dave's "secy" in RFC 733.

For Resend-* the owner at that time is the "resender", responsible
for picking this way to forward the mail to somebody else.  It should
work often.  But not in scenarios where an anti-replay mechanism or
something else stripped important (for DKIM) header fields of the
original sender (author or secy).  Or if the original mail is old.

>> this is a petition for reopening this Issue. That gives 1 vote, but
>> supports this view to reply with a +1.

+1  Hector's "owner" proposal makes me nervous, the owner is somebody
who has a mail, it can be the receiver, a secy, a list, a gateway, ...

Frank

---

From: John Levine <[email-masked]>
Date: 28 Nov 2006 15:39:54 -0000

>OK, this is a petition for reopening this Issue.

-1

It's a feature that the signing domain isn't tied to other headers,
not a bug.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 28 Nov 2006 10:42:11 -0500

> who has a mail, it can be the receiver, a secy, a list, a gateway, ...

So how do we start down this path without ending up with PRA?

2822.From is the only identity that is reliably displayed to the end user.  It 
is also a required part of the message.  As soon as you grant 2822.Sender the 
same role as 2822.From in SSP, then any anti-forgery potential inherent in 
SSP (let's not argue that one again - just saying to the extent there is any) 
has been seriously diluted.  Follow this trail to the end and you end up 
protecting resent-sender again.

Scott K

---

From: Steve Atkins <[email-masked]>
Date: Tue, 28 Nov 2006 07:57:04 -0800

Agreed.

Cheers,
   Steve

---

From: Michael Thomas <[email-masked]>
Date: Tue, 28 Nov 2006 08:12:59 -0800

Eliot Lear wrote:
> Charles,
>
> Forgive my sloppy message, but netnews *is* a separate case, and I'm 
> not going to go there with you on this list (others already have).  
> Mail / Unicast mechanisms require either 3rd party authentication or 
> the message to flow back to the 1st party through some authenticated 
> and trusted chain.  So, for instance, consider GPRS.  If I have an 
> email address [email-masked] that I want to use to send mail from my 
> phone, then either I use my corporate MSA or there is a third party 
> record of some sort for my provider.  Those are really the only two 
> possibilities, and neither of which is a substantial architectural 
> change.
Heaven knows that it would be anathema to the walled gardens of the PSTN,
but your phone could do the signing itself too :)

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 28 Nov 2006 08:33:49 -0800

Hector Santos wrote:
> There is something not very kosher with that. 

That's incorrect. DKIM says nothing about "messages" being valid or not.
Only signatures.

       Mike

---

From: Damon <[email-masked]>
Date: Tue, 28 Nov 2006 11:58:06 -0500

> That's incorrect. DKIM says nothing about "messages" being valid or not.

Cluck-
The signature validates the authenticity of the message by verifying
the sender (loose definition).
If paypal sets up a rule that is something less than "I sign all and
be cruel to messages purporting to be from me without valid
signatures", then DKIM-BASE in the case of a spammer putting a RND# in
the signature field, fails to do anything other than waste CPU cycles.

Damon

---

From: Hector Santos <[email-masked]>
Date: Tue, 28 Nov 2006 12:24:32 -0500

> That's incorrect. DKIM says nothing about "messages" being valid or not.

Maybe you should quote "valid"

Look, what in earth are you validating a SIGNATURE for if its not 
directly proportional to the validity of the message?  Is it just for 
show?  I hope you are not suggesting that a signature validity is 
persistent while you can alter the structure and content of a message.

Lets not go there. OK?

Thanks

---
HLS

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 28 Nov 2006 18:36:28 +0100

> So how do we start down this path without ending up with PRA?

Well, I've often posted that while I hate PRA anything else (in
2822-land) is far worse, because it's incorrect... ;-)

> 2822.From is the only identity that is reliably displayed to
> the end user.

In that point I agree with Hector:  The problems of braindead
MUAs are out of scope.  A MUA ready for 4406 would display the
PRA, it's a SHOULD in 4406.  An OE for Vista probably <shrug />

Other MUAs can probably display the Return-Path if desired, as
they should wrt 3834, 4408, and SMTP in general.  But that's
irrelevant for DKIM, DKIM is designed to be SMTP-agnostic (like
PRA).

> Follow this trail to the end and you end up protecting
> resent-sender again.

Yes.  The alternative is to deprecate Resend-*, and I'd support
to deprecate it.  It breaks any serious attempt to make sense
out of the 2822-header fields for PRA or SSP or 4409 8.1 again
and again.

Frank

---

From: Douglas Otis <[email-masked]>
Date: Tue, 28 Nov 2006 10:09:58 -0800

On Nov 28, 2006, at 4:48 AM, Charles Lindsey wrote:

>>>> It's not entirely forgotten; section 2.3 of draft-allman-dkim- 
>>>> ssp-02 discusses multiple From addresses.  We thought about  
>>>> resolving the ambiguity by (1) arbitrarily picking the first  
>>>> address in the From header field, (2) picking the address in the  
>>>> Sender header field, or (3) querying SSP for all addresses in  
>>>> the From header field, and combining them somehow.  We picked  
>>>> (1), ...
>>>
>>> I have seen sufficient comments from others to the effect that  
>>> the Sender needs to be looked at in many situations that this  
>>> matter probably ought to be reviewed (does that mean raising an  
>>> Issue?).
>>
> That is fair comment, but there seem to be an awful lot of people  
> still discussing the Role of Sender (and even List-ID and Return- 
> Path) as possible signing domains.
>
> OK, this is a petition for reopening this Issue. That gives 1 vote,  
> but you will need lots more to take action. So I invite anyone else  
> who supports this view to reply with a +1. If there is insufficient  
> support, then I will shut up.
+1!

Selection of the From address is premised upon a bad assumption that  
by only "authorizing" this header, spoofing an "author" of the  
message can be prevented.  This concept remains highly flawed for the  
following reasons:

1) Only the display name may be visible.
2) The display name may appear as the actual email-address.
3) UTF-8 support makes human checking impossible.
4) Look-alike and cousin domains are not prevented.
5) Increases likelihood of multiple From email-address use.
6) Not likely able to incorporate EAI email-address versions.
7) Establishes credibility of phishing attempts by self "authorization".
8) Reduces email delivery integrity in many scenarios.
9) Requires excessive DNS overhead climbing label trees for every
      unsigned message to satisfy a small percentage of domains that
      will publish an "all From headers should be signed."

This narrow view overlooks a far more protective alternative that:
1) Thwarts look-alike and cousin domains  spoofing.
2) Is compatible with any EAI scheme.
3) Will not increase credibility of phishing attempts.
4) Will increase email delivery integrity.
5) Will not require excessive DNS overhead.
6) Can be implemented by the recipient and email-address domain
      owner independent of their providers.
7) Eliminates exchange of private keys with providers, zone
      delegations to the provider, or negotiations with the provider the
      selector locations for a series of CNAME records.

The alternative is protection by an annotation scheme checking two  
basic items:

1) Is a signed email-address known by the recipient (i.e. in the  
address-book)?

2) Is the signing domain designated by this email-address domain?
     (Obvious only when same domain.)

When other headers are used to communicate with a recipient, then  
which headers gets annotated can still be controlled by the domain of  
the email-address ONLY when other headers are allowed to make  
associations!

Setting flags regarding whether all such headers are signed can be  
added.  However, such flags should not be checked by most  
recipients.  A false expectation of blocking abuse by way of  
"authorization" has been shown not to work, but this seems to be what  
is behind most participants motivations.  This limits their thinking  
to only the use of the From header.  Allowing associations to support  
an annotation scheme has not been considered.  The same association  
scheme can also prevent white-listing abuse and ensure DSNs once this  
approach is considered more carefully.

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 28 Nov 2006 13:06:04 -0500

On Tuesday 28 November 2006 12:36, Frank Ellermann wrote:

> MUAs are out of scope.  

Except that any solution that starts out with upgrade every MUA in the world 
(except I think GNUs) is probably not going to get much traction.  

The reality is that from an end user perspective 2822.From is the only game in 
town.

Scott K

---

From: Michael Thomas <[email-masked]>
Date: Tue, 28 Nov 2006 11:04:04 -0800

> The reality is that from an end user perspective 2822.From is the only game in 
Scott --

This seems to assume that the only consumer of SSP information would be 
an MUA.
That's not a very good assumption -- incoming filters could make use of 
the information
too. From that standpoint, other inputs beside the From address might be 
interesting too.

That said, after thinking about this I don't find those arguments 
compelling enough to
get wrapped around the axle. Also: given that the protocol needs to be 
extensible,
we can be cautious and defer things that we're not very sure about their 
utility to some
time in the future when the benefits are more clear. This seems to be 
one of those
things.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Tue, 28 Nov 2006 11:19:32 -0800

On Nov 28, 2006, at 10:06 AM, Scott Kitterman wrote:

>> In that point I agree with Hector:  The problems of braindead MUAs  
>> are out of scope.
>
> Except that any solution that starts out with upgrade every MUA in  
> the world (except I think GNUs) is probably not going to get much  
> traction.

Don't forget most email applications and browsers offer plug-in  
interfaces.

See:
http://www.iconix.com/

This startup has a fairly broad offering already.  They can also  
enable DKIM on Exchange.

>  The reality is that from an end user perspective 2822.From is the  
> only game in town.

By design, DKIM signatures are not visible.  By inspection of a raw  
message, a recipient has no way of knowing which messages hold a  
valid DKIM signature.  Do not assume DKIM prevents spoofing attempts  
based upon visible headers with existing MUAs.  Unless invalid  
signatures are rejected (which breaks email in many scenarios), valid  
DKIM signature might then be placed into a "valid DKIM signature"  
folder as a type of annotation.  A filter can inspect the "valid DKIM  
signature" folder for signed originators found within the address  
book and then move those messages into the "trusted" folder.  This  
would be far more secure and simpler than checking whether each and  
_every_ unsigned messages should have been signed.  I like the Iconix  
approach myself.  It will take a while before people stop reviewing  
unsigned mail, but they will not be fooled when expecting trustworthy  
messages to be signed by someone they already know.

How would you expect to communicate an assertion that a bank always  
signs to the recipient?  Would conveying this assertion increase a  
likelihood of their customers then being fooled by look-alikes?

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 29 Nov 2006 10:43:12 -0000

> time in the future when the benefits are more clear. This seems to be  

Indeed. What is going to happen when this stuff gets deployed is that  
there will be a continuing battle between the Bad Guys, who will find ways  
to make it appear that their messages are genuine in spite of DKIM, and  
the Good Guys, both signers, verifiers and reputation reporters, who will  
change their strategies as regards what is signed, what is announced in  
SSP records, and how to evaluate the results of verification.

We cannot predict how this battle will go (it is usually the Bad Guys who  
set the agenda). Therefore, there should not be too many MUSTs in our  
specs concerning these details. Our job is just to provide a set of tools  
(weapons), and to leave it to the Good Guys to use them in the most  
effective manner.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 29 Nov 2006 10:51:01 -0000

On Tue, 28 Nov 2006 15:42:11 -0000, Scott Kitterman  
<[email-masked]> wrote:

> 2822.From is the only identity that is reliably displayed to the end  
> user.

I utterly fail to see why what is displayed to the user is of the least  
relevance.

Verification is going to be done mostly by MDAs, who will either drop the  
message, or else warn the user that it is suspicious (warnings may range  
 from a simple Good/Bad to a long essay on exactly what is wrong). It is  
only when the user suspects he has a false positive that he might be  
interested in examining the headers himself. More usually, if he is sure  
it is a false positive, he will just accept it and get on with life.

The occasional sophisticated user who elects to do the verification  
himself will naturally provide himself with tools which display all  
headers of interest.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 29 Nov 2006 10:57:45 -0000

> message and that is whats important in DKIM.

Usually, the Sender will be the same as (one of) the From(s), or at least  
will be from the same domain. But in the few cases where it is not the  
MSA, which is where the signing is likely to be done, will probably be  
more familiar with the Sender, and able to vouch for him, than with the  
From. In other situations, it might be the List-Post rather than the  
Sender.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 29 Nov 2006 12:42:25 +0100

Charles Lindsey wrote:
>
> I utterly fail to see why what is displayed to the user is of the 
> least relevance.

Because it's very possible UAs will indicate whether a message is signed 
or not.  This is already done with various plugins.

Eliot

---

From: Hector Santos <[email-masked]>
Date: Wed, 29 Nov 2006 07:54:34 -0500

Charles Lindsey wrote:
> On Tue, 28 Nov 2006 14:15:21 -0000, Hector Santos 
>>
> Usually, the Sender will be the same as (one of) the From(s), or at 
> least will be from the same domain. 

And it may not be the same domain, and it may not exist at all.

> But in the few cases where it is not the MSA, which is where 
 > the signing is likely to be done,

Really?  Why do you say that?  IMTO, the MSA is the least likely place. 
  But then again, that might probably depend on your definition of what 
an MSA is.

> will probably be more familiar with the Sender, and able to vouch 
 > for him, than with the From.

Vouch? As in reputation?

Anyway, IMV, most people could careless who actually sent the message. 
People are more interested in who "authored" a message.  It is only when 
you want to "shoot the messager", then you might be interested in who 
"sent" it, but by far, the electronic mail infrastructure across the 
board is fundamentally based on FROM:

 > In other situations, it might be the List-Post rather than the
> Sender.

It sounds to me that in a indirect way, you are trying to solve the 3rd 
party signer authorization problem and to use this as the basis for DKIM 
signing in general?  That the domain owner have no say in its domain 
mail? Does the domain owner have any control any more? Or is that 
obsolete too? :-)

I fail to see how mandating Sender is going to solve anything other than 
to take the domain owner completely out of the picture. I see this as 
flawed in so many ways, far more than what From: protection can offer.

---
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 29 Nov 2006 08:44:30 -0500

> I utterly fail to see why what is displayed to the user is of the least

For DKIM-base I agree.  There is no tie at all between the signing domain and 
any of the 2822 identities.  This is, as I think it was John Levine that 
said, a feature, not a bug.

> himself will naturally provide himself with tools which display all

For DKIM-SSP it is a different matter.  We've been through this before, but...

SSP needs an identity to key off of to lookup a policy.  The agreed identity 
for that is 2822.From for several reasons:

1.  It the only 2822 identity that is mandatory.
2.  It is one of the headers that is signed.
3.  It is displayed to the end user (senders that have an interest in 
protecting their domains from spoofing are deeply interested in what is 
displayed).
4.  Allowing any other header to trump the policy of 2822.From allows 
2822.From to be trivially spoofed and eliminates whatever anti-phishing 
potential there is in DKIM (how much that is has been argued to death and I 
don't propose we do it again - it is what it is).

Scott K

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 29 Nov 2006 14:49:12 +0000

> supports this view to reply with a +1. If there is insufficient support, 

First, thanks for taking this attitude, I really do appreciate you
being constructive even though you've gotten involved after this was
already decided in the WG.

After a little more than 24 hours the net score is about zero there.
And I'm entirely sure there're folks who've not said anything but who
don't want to change base as you'd like, so in fact, it'd most likely
really be a negative score.

So I guess that's that then - there is nothing like a consensus to
re-open this topic for base, and so we won't. (If the tables turn in
the next day or two, then I'm ok with changing, but it seems clear
enough to me call it already.)

Cheers,
Stephen.

PS: The discussion as to which field to use to query SSP records,
is a separate, though related, one, where we can't yet say that we
have a consensus (since we're only on ssp-reqs and not protocols).

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 29 Nov 2006 08:50:24 -0800 (PST)

On Wed, 29 Nov 2006, Charles Lindsey wrote:

> On Tue, 28 Nov 2006 15:42:11 -0000, Scott Kitterman <[email-masked]> 
> wrote:
>
>
>> 2822.From is the only identity that is reliably displayed to the end user.
>

Charles is correct. The way protocol is layed down right now what is
displayed to the user is irrelevent to the core. It only becomes relevent
with the the policy part which is supposed to be the one trying to protect
against phishing. Also note that any MUA-based anti-spam systems that may
use the core would look at what it says and therefore if other header field
like Sender is listed its quite likely to be displayed.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 29 Nov 2006 09:26:51 -0800

On Nov 29, 2006, at 3:42 AM, Eliot Lear wrote:

> Because it's very possible UAs will indicate whether a message is  
> signed or not.  This is already done with various plugins.

The same plug-ins can also verify an associative policy regarding  
other headers as well.  Being signed might be for entities found in  
the 2822.From, the 2822.Sender, or for the 2821.MailFrom (to help  
ensure DSNs).  Annotation of a message being signed by itself is of  
little value.  Being "signed" and "recognized" is what is important  
when the desire is to curtail spoofing.  This "recognition" should  
not be visual.  Because a great deal of email is sent by entities not  
found within the 2822.From header, being able to "recognize" other  
headers becomes important when extending protection for this portion  
of the email traffic.  Leaving holes in what gets protected only  
invites abuse.

-Doug

---

From: Damon <[email-masked]>
Date: Wed, 29 Nov 2006 13:31:21 -0500

+1

Damon Sauer

---

From: Eliot Lear <[email-masked]>
Date: Wed, 29 Nov 2006 19:52:17 +0100

Damon wrote:
>> ensure DSNs).

First of all, we are now talking about that which is not there, a signed 
2821.MailFrom, and we are discussing base, which this group is finished 
with.  So, it seems to me that we have really veered from the topic of a 
sender header.

>> Annotation of a message being signed by itself is of
>> when the desire is to curtail spoofing.  

Sure.  And when we get there life will be peaches and cream.  But we 
need to transition to that point, and end users should be able to 
benefit from DKIM + the good work that people like Paul Hoffman are 
doing, so that SPs themselves don't become a bottleneck to deployment.

Eliot

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 30 Nov 2006 10:55:07 -0000

> like Sender is listed its quite likely to be displayed.

Ah! I think I see now what Scott and Eliot are getting at. Suppose we have:
     From: [email-masked]
     Sender: [email-masked]
with good signature by bar.com

The verifier informs the recipient that the message was signed by bar.com,  
and is confused because he sees no header mentioning bar.com. Or it  
reports a failed signature by bar.com, and the user is even more confused.  
I.e., he is supposing that the user is merely informed of what signatures  
are present and it is left to him to inspect the displayed headers to see  
whether he needs to be alarmed.

I find that a very poor way of communicating to the user, as others have  
pointed out (though I don't go along with Doug's expectation that the  
user's MUA will go trawling through his address book). So let us step back  
a moment and see how this communication might take place.

There are two cases:
1. The MUA has been specially adapted to work with DKIM
2. The MUA has not been specially adapted

We are supposed to be designing a system which will work with existing  
MUAs (i.e. case 2), so in that case the verifier's policy module can only  
communicate with the user via the body of the message - rather like those  
irksome systems which add long paragraphs to the end of messages to inform  
you of all the viruses they did or didn't detect.

So in that case it is up to the policy module to describe its suspicions  
in a manner the user can understand whether he can see all the relevant  
headers or not.

So it might say
    "This message was sent by [email-masked] (good signature by bar.com) but  
you
     should notice that the From: address made no mention of bar.com."
or
    "This message was sent by [email-masked] apparently on behalf of  
[email-masked],
     but there is no valid signature from either of them."

OTOH, if one can assume an adapted MUA as in case 1, then presumably the  
communication could be by some other channel (possibly using the headers),  
but such an MUA would, in any case, display all headers relevant for  
understanding the report from the policy module, including the Sender if  
appropriate.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 30 Nov 2006 10:56:57 -0000

> or not.  This is already done with various plugins.

In that case the plugin can be arranged to display the Sender, if relevant.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 30 Nov 2006 11:14:53 -0000

> for that is 2822.From for several reasons:

But that is wholly back to front. The SSP policy to look up initially  
should be that of the domain making the signature. Then you look at the  
various headers and see which ones match the policy of that domain. And  
finally, if some of them don't match and your policy module thinks they  
should, then you can look up the SSPs for some of those too. The case  
where the domain of the Sender did not match _any_ of the domains in the  
 From might be a case for such additional lookups.

But OTOH suppose the SSP of the signer said:

"We are a list expander and resign all messgaes because we have corrupted  
any original signatures, but only after we have checked the validity of  
those original signatures", then what are you going to do?

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 30 Nov 2006 07:33:10 -0500

> whether he needs to be alarmed.

Not quite.  What I want to be able to do with SSP has nothing to do with user 
interface.

In your example, let's say that foo.com is a heavily phished domain that has 
published a signing complete SSP.  In this case I have received a message 
that is outside the criteria of their declared SSP.  They have published such 
an SSP knowing that it will cause some legitimate use classes of mail to fail 
(e.g. mail sent through mailing lists that break signatures), but that the 
benifits of combatting exact domain forgery are worth the cost (this has been 
extensively debated on the list already and the group is divided on this - I 
don't propose to redo this debate).

What I want to be able to do is retrieve the SSP based on the 2822.From, 
determine that foo.com has published signing complete, look for and fail to 
find a signature by foo.com, and then after the final "." in DATA reply 550.  
Rejecting the message then keeps the end user and MUA considerations out of 
it entirely without negatively impacting the reliabliity of the overall 
e-mail infrastructure.

If a good signature from bar.com can over-ride this, it won't be long before 
all the phishers add it.  If I follow this to it's logical conclusion, we end 
up using the MS PRA algorithm and get:

      From: [email-masked]
      Resent-Sender: [email-masked]

With good signature by bar.com over-riding whatever foo.com has to say.  
Whatever limited value SSP could have had in combatting phishing without 
having to upgrade every MUA in the world is pretty well negated.

Scott K

---

From: <[email-masked]>
Date: Thu, 30 Nov 2006 10:12:24 -0500

I fail to see any relevance here?
Go out to your user pool show them the headers and ask them what they signify. Chances are "not much".

From: [email-masked]
Sender: [email-masked]
Good DKIM sig from bar.com

Means that bar.com signed on behalf of (purportedly) [email-masked] and when asked will verify that yes indeed we sent that message. It has squat all to do whether the letter is a 419er, Viagra or get rich quick pumping stock.

Expecting end users, remember we are an ISP, to understand DKIM + SSP is far beyond anything we could imagine.
Thanks,

Bill Oxley
Messaging Engineer
Cox Communications

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Lindsey
Sent: Thursday, November 30, 2006 5:55 AM
To: DKIM
Subject: Re: [ietf-dkim] Re: Role of Sender header as signing domain

There are two cases:

So it might say

---

From: Michael Thomas <[email-masked]>
Date: Thu, 30 Nov 2006 08:04:35 -0800

Charles Lindsey wrote:
> should be that of the domain making the signature.
What signature? SSP is for the case when you get a piece of mail whose 
signature
is either missing altogether, broken, or doesn't fit the requisites for 
the SSP policy.

> "We are a list expander and resign all messgaes because we have 
> corrupted any original signatures, but only after we have checked the 
> validity of those original signatures", then what are you going to do?

Ignore them in absence of any other information. If I don't know you, I 
really don't
care much about what your third party role is since you could be lying 
and trying
to get me make the, oh say, From address look more believable than it is.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Thu, 30 Nov 2006 11:04:59 -0800

On Nov 29, 2006, at 10:52 AM, Eliot Lear wrote:

>>> other headers as well.  Being signed might be for entities found  
>>> in the 2822.From, the 2822.Sender, or for the 2821.MailFrom (to  
>>> help ensure DSNs).
>
> First of all, we are now talking about that which is not there, a  
> signed 2821.MailFrom, and we are discussing base, which this group  
> is finished with.  So, it seems to me that we have really veered  
> from the topic of a sender header.

DKIM signer policy can also offer pertinent information related to  
the MailFrom.  Why not?  The Sender, or Resent-From, Resent-Sender,  
or whatever new From header that might come into existence can all be  
encompassed by a set of policies, where each has a separate reference  
that is only used when needed.   Having a means to associate the  
Signing-Domain with the MailFrom better ensures DSNs are returned  
(even when SPF fails with this mode of backscatter prevention).  With  
a MailFrom policy association, DKIM can greatly improve email  
delivery integrity in these situations.

>>> Annotation of a message being signed by itself is of little  
>>> value.  Being "signed" and "recognized" is what is important when  
>>> the desire is to curtail spoofing.
>
> Sure.  And when we get there life will be peaches and cream.  But  
> we need to transition to that point, and end users should be able  
> to benefit from DKIM + the good work that people like Paul Hoffman  
> are doing, so that SPs themselves don't become a bottleneck to  
> deployment.

The Domain Assurance Council is attempting to establish a type of  
white-listing or vouching structure.  To support white-listing, in  
many cases it is _absolutely_ essential to associate the Signing- 
Domain with the SMTP client.  An SMTP client is not an email-address  
either!   Being able to make policy associations with SMTP clients  
provides conditional requirements that ensure there is no Replay- 
Abuse of the white-list.  This would be extremely important when used  
for domains like Yahoo!.

There is real risk to current email applications, how email might  
function in the future, and to the security of recipients that are  
then expected to trust annotations applied to messages premised upon  
what a recipient thinks they are seeing with regard to an author's  
email-address.   Whether the basis of checking a signature is based  
upon a DAC compatible list structure, an Address-Book, or something  
else, the "Recognition" process MUST NOT BE VISUAL!  The "I sign All"  
approach is predicated upon visual recognition along with an  
assumption this reduces the amount of abuse carried by a particular  
MTA.  It will not, and this approach seriously places recipients and  
the email infrastructure at risk.

To apply this ill-considered, dangerous, and destructive policy, the  
recipient must walk up label trees, repeated at rates of a negative  
caching interval, for each and every message that might be unsigned  
or signed, but where the From email-address is not within the Signing- 
Domain.  Any benefit from this flood of DNS transactions (in addition  
to those already needed to validate the signature) can only be  
realized when the domain setting policy is willing to have valid  
messages rejected when sent to mailing-list or exchanged in other  
ways.   So for perhaps a small percentage of the domains signing with  
DKIM, all messages should invoke a DNS process that walks up label  
trees looking for typically non-existent records?  This seems more  
like veering off the road heading toward a reasonable use of DKIM  
policy.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Thu, 30 Nov 2006 14:27:04 -0800

On Nov 30, 2006, at 2:55 AM, Charles Lindsey wrote:

> We are supposed to be designing a system which will work with  
> existing MUAs (i.e. case 2), so in that case the verifier's policy  
> module can only communicate with the user via the body of the  
> message - rather like those irksome systems which add long  
> paragraphs to the end of messages to inform you of all the viruses  
> they did or didn't detect.
>
> So in that case it is up to the policy module to describe its  
> suspicions in a manner the user can understand whether he can see  
> all the relevant headers or not.
>
> So it might say
>    "This message was sent by [email-masked] (good signature by  
> bar.com) but you

It should be understood modifying the body prevents a recipient from  
using DKIM.   Assuming the MUA does not directly support DKIM will  
allow bad actors to make similar assertions within the body of the  
message.   Adding information to the body of the message must contend  
with complex structures within HTML such as color and text schemes.   
This too can be irksome while also damaging efforts of adopting a  
truly secure strategy.  At this _very_ moment, the recipient might be  
able to validate DKIM messages based upon a trusted list, where an  
assumption that the recipient can not MUST be done on an  
individualized basis.

> OTOH, if one can assume an adapted MUA as in case 1, then  
> presumably the communication could be by some other channel  
> (possibly using the headers), but such an MUA would, in any case,  
> display all headers relevant for understanding the report from the  
> policy module, including the Sender if appropriate.

In the case of Iconix for example, a company's logo may also be  
displayed, perhaps this could be the seal of the Internet Banking  
Federation. : )

Why would you consider it to be difficult for the MUA to check signed  
headers against email-addresses found in the Address-Book or a  
trusted list?  The next step in this checking process would be to  
discover whether the Signing-Domain is associated with the email- 
address in question.  Only when an association is established between  
a trusted list and the email-address, and between the Signing-Domain  
and the email-address, should the DKIM signature even be validated.   
Not checking in this order conveys which messages pass anti-spam  
measures, and unnecessarily burdens the receiving MTA.  Having the  
MUA selectively perform this function better ensures DKIM will not  
burden the system (or increase costs), while dramatically improving a  
recipient's ability to trust specific messages.

-Doug