MX dot was (Re: [ietf-dkim] TXT wildcards SSP issues
steve at blighty.com
Sun Jun 3 08:58:17 PDT 2007
(Still way OT, but it's more interesting than SSP, eh?)
On Jun 3, 2007, at 7:01 AM, Scott Kitterman wrote:
> On Saturday 02 June 2007 18:51, Steve Atkins wrote:
>> How is "MX ." working out for you? Not a rhetorical question - it's
>> likely the closest we have to a standard for "I don't send email"
>> today, and is more likely (IMO) to be used by recipients than
>> SSP, so it's an interesting bit of data.
> IMO it's a really odd idea as it causes DNS root queries by standards
> compliant MTAs and changes the semantics of MX (now all of a sudden MX
> relates to sending mail).
No, it shouldn't cause root queries.
No, it doesn't change the semantics of MX. It states "This domain does
not accept email", and does so in a standard fashion that is already
specified by the DNS RFCs. If the domain cannot receive email then
there cannot be "legitimate" email using that domain as the envelope
from. That's already common knowledge, as crystalized in many, many
spam filtering systems.
> I've suggested before that if one wants a standardized "Sends no
> mail", an
> extract of the string literal for that from the SPF RFC (RFC 4408)
> could be
> pulled out and made a separate spec for that one meaning avoiding
> all the
> other baggage. It's currently standardized and has significant
It's not a bad idea, but you again have a huge deployment problem
(as SPF deployment is decreasing, so you can't rely on piggybacking
The main advantage of MX . is that many places already support
it, as a side effect of their rejection of obviously bogus mail at
> It isn't clear to me that either of these proposals though is meant
> to apply
> to message bodies. I know SPF is aimed at the envelope, I that's
> what I
> would have thought for MX . too.
Yes, envelope. The primary goal is to stop bogus bounces. As has
been widely discussed before, constraining the payload of the mail
doesn't really do any good (the only thing it's even claimed to be
useful for is phishing, and it doesn't work there).
More information about the ietf-dkim