On Tuesday 08 August 2006 15:15, Frank Ellermann wrote:
[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.
I was thinking in terms of using the policy record as a hint rather than
something directly in the SMTP exchange. If an SMTP client tells me
something in order to convince me to accept it's mail, I am extremely
unlikely to believe it without outside confirmation.
If the Mail From domain has a DKIM policy record that says it signs mail, then
that's an external source that is at least somewhat more believable.
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 ?
In order to know what policy record to look at.
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've probably seen it the same places. I'd be interested if someone had some
current statistics too.
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.
Yes, but Mail From and signing will usually be generated at the MSA, so as
long as the policy record is correct for the signing domain, I don't think
that matters.
In the cases of a list / moderated newsgroup / etc. (Dave
mentioned other cases) the MAIL FROM is not the same as the
2822-From.
Yes. I don't think this can solve all problems, but it might have general
enough utility to be worth specifying. I'm not sure. I throw this out as an
idea for consideration by the group, not something that I am certain is
worthwhile.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html