[ietf-dkim] Re: Signalling DKIM support before DATA
nobody at xyzzy.claranet.de
Tue Aug 8 12:15:17 PDT 2006
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.
>> 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
More information about the ietf-dkim