You need to throw way the whole idea of mandating an MX. MX is for
OUTGOING mail. DKIM is for IMCOMING mail.
MA applies to the x821.MailFrom domain period. Attempting to tie to the
the 2822.FROM is arkward and the proposed solution is isolated to a few
systems that believe they have a total solution for the world.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Jim Fenton wrote:
Eric points out, correctly, that issue 1534 fell through the cracks when
I was preparing the slides for last week's meeting, so we didn't discuss
it. I had intended it to go into the "medium" category, but we
shouldn't close it without the opportunity for some discussion.
The text of the item from the tracker is:
http://mipassoc.org/pipermail/ietf-dkim/2007q4/008437.html
s The signing practices apply only to the named domain, and not
to subdomains.
So this is intended to overcome the problem of not being able to use
wildcards?
What is the query behavior that validators need to use, to discover this
record, when they start with a message having a deeply-nested From field
domain name?
To the extent that the above is not sufficiently clear:
There is not way to properly enforce or even discover the semantics of
this flag, in the general case of sub-domains. This option needs to
removed or be specified in a way that works.
My response is that the upward query, and the t=s flag (which provides a
way to limit the application of ASP outside the immediate domain) are
not intended to cover subdomains. Rather, they provide a way to cover
terminal leaf nodes within the domain (e.g., hostnames) that can be used
as domains (in the 2822 sense) in email addresses.
While the need to cover this hole exists primarily as a consequence of
the use of hostnames (vs. MX records) as email delivery points, this
problem can't be solved by requiring MX records for domains publishing
ASP, as was suggested in Issue 1547. Suppose that a message from
blarney.example.com was being ASP checked, and we don't know anything
about that domain. First you look for
_asp._domainkey.blarney.example.com TXT, and if you don't find it, let's
say you do an MX query for blarney.example.com, and it isn't found either.
The possibility exists that blarney.example.com is a host that receives
its mail using its A record, and just hasn't published an ASP record.
At this point you would need to conclude, unless the MX query resulted
in an NXDOMAIN error, that blarney.example.com has an "unknown" ASP.
The requirement for an MX record would apply when the ASP record does
exist, but in that case you wouldn't need to query for it anyway.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html