(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
deployment.
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
on that).
The main advantage of MX . is that many places already support
it, as a side effect of their rejection of obviously bogus mail at
receipt
time.
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).
Cheers,
Steve
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html