On Sun, 2007-06-03 at 10:01 -0400, 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).
Agreed. MX . is a very bad idea. > 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. Why not simply No MX RR then No mail? > 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. It really depends upon who is using SPF. SPF expands macro constructs which modify subsequent DNS transactions. This means SPF might be invoked again and again for each such application. Repeated invocations could be required for MAILFROM, PRA, DKIM domains, or EHLO. Proponents want to believe a 10 x (instead of a 100 x) increase in the number of DNS transactions is not a problem. However, whichever factor that might be, multiply this factor again by the number of elements within a message associated with SPF records, and then again by the number of message local-parts within a spam run. The DKIM WG should stay far far way from SPF due to DDoS concerns. The DKIM WG should understand the risk in using SPF records for anything. Add to these problems, a likely need to search for SPF records. Few SPF records are small enough to safely permit use of wildcards. Why not no MX RR, then No mail? -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
