In <[EMAIL PROTECTED]> Steve Atkins <[EMAIL PROTECTED]> writes:
> On Jul 26, 2006, at 12:13 PM, Hector Santos wrote: > >> [mention of the SPF record "v=spf1 -all" as a "we never send email" >> notification] > > "MX 0 ." seems to be the standard way of asserting that a domain > neither sends nor receives email. Shoehorning the same assertion > into multiple different pseudo-standards simply leads to contradiction. "MX 0 .", like all MX records with bogus mail exchanges, in effect says "I can not receive email". This is not quite the same as saying "I do not send email". First off, the "MX 0 ." technique will cause queries asking the root for A records, which don't exist. The root servers already get enough bogus queries, it doesn't seem like a good idea to promote a technique that makes things worse. Secondly, I have several domains that, while they never *send* email, I do want to receive email for them. Some of these domains are stuff that used to be in use, pass on obsolete email addresses on to the correct (newer) domain or are used as spam traps. However, others are because I want to allow abuse reports for websites. There are people who argue that any host that doesn't accept an [EMAIL PROTECTED] email is in violation of RFC2142 and will block email from these domains, even if that domain is used in the 2821.HELO address rather than the 2821.MAILFROM or 2822.From: address. See rfc-ignorant.org for an example. So, I think the SPF record "v=spf1 -all" is much better than using "MX 0 .". > I don't see why people would pay any more attention to an SSP > statement of such than they do to SPF statements of it. Just the > opposite, shoehorning unneeded cruft into SSP makes it less likely > that people will pay any attention to it, I'd think. The SPF record "v=spf1 -all" case can be safely used to reject connections for both the 2821.HELO and 2822.MAILFROM during the SMTP session without any of the failure cases of other SPF records. That is, there are no problems with forwarding and such. I can see similar uses for a DKIM policy, although I can also see the argument that having yet another way of saying the same thing is not a particularly good idea. -wayne _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
