In <1F817B0B-1EAC-4ABF-809F-D7CAAD6BD2AB(_at_)blighty(_dot_)com> Steve Atkins
<steve(_at_)blighty(_dot_)com> 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
abuse(_at_)host 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