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
