Douglas Otis wrote:
On Mar 17, 2008, at 12:31 PM, Hector Santos wrote:
You need to throw way the whole idea of mandating an MX. MX is for
OUTGOING mail. DKIM is for INCOMING mail.
While MX and A records are used to discover inbound SMTP servers, they
can also play a role in determining whether the domain might also be
publishing DKIM related policy.
[SNIP]
We know all that and any vendor can come with a total solution.
Like I said, it becomes awkward and also half baked because in reality
the real contact address could be the Reply-To: header, if any.
The technical reality today is such that all mail responding software
are required to follow the RFC based mail system rules for responding to
an originating address:
Use Reply-To: field. if not available, fall back to From:
In other words, in practice, the only thing that is required for a valid
response is that Reply-To works, if any and if not, then use From:
So unless the Reply-To: header is taken into account in the "Total
DKIM+POLICY Solution", it really is not addressing the entire issue.
This is also one area I believe SENDER-ID fails with its protocol theme
of depending on some PRA that does not take into account the Reply-To
address.
Think about it:
Assume a message gets to a user and it passes all the CBV, RBL, SPF,
SENDER-ID, DKIM, ASP POLICY tests or at least they don't raise any
red-flag, if the Reply-To field is bogus, then it may be all for
nothing. The user may be hosed.
What this might suggest
For the DKIM signers:
If a Reply-To: header is presence, it MUST be included in
the list of hashed headers for the DKIM signature.
For the DKIM verifier:
If a Reply-To: header is presence but NOT part of the
the hashed headers for the DKIM signature, then the
message SHOULD BE viewed as SUSPICIOUS.
Note how POLICY does not even play a role. It is the kind of filtering
rules or ideas that will be explored when (not if) DKIM becomes a major
part of the ABUSE process
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html