[ietf-dkim] Re: Signalling DKIM support before DATA

[Frank Ellermann]

Hallam-Baker, Phillip wrote:
 
> For example. Define a command option SDATA, Reciever
> advertises it in response to EHLO, sender uses it to
> present signed data in place of DATA.

If the client sifts his outbound into "signed DATA" and
"unsigned DATA", it could also use a MAIL FROM parameter
to indicate what it's going to be.  

> the point is we should use the SMTP extension mechanism
> not invent our own.

An example is RFC 4405.

  [Scott wrote:]
>> Such a hint would, I imagine, only be useful when From =
>> Mail From.

Why ?  Your scenario is apparently mail where you're about to
reject it before DATA, unless it promises a DKIM signature,
and you're willing to check this.  

If you intend to check the signature after you've accepted the
mail you'd need a no-nonsense MAIL FROM, but why the same as
the 2822-From ?

>> IIRC, that accounts for about 80% of mail.

It would be interesting if somebody can confirm this.  I've
seen it elsewhere, but can't tell anymore if it was about the
2822-From or the PRA.

>> I can see some potential for this to make signing more
>> attractive to small senders who are more likely to be
>> blocked due to RBLs.  It may be attractive to receivers
>> as a way to reduce false positives from spam filtering
>> techniques used on the envelope.

Yes, but I miss two clues here.  First party signatures are
created somewhere between MSA and "mailout" (= MTA talking
to an MX), and that MTA does not necessarily know what it's
sending, signed or unsigned mails.

In the cases of a list / moderated newsgroup / etc. (Dave
mentioned other cases) the MAIL FROM is not the same as the
2822-From.

Frank