On Jul 26, 2006, at 1:04 PM, Hector Santos wrote:
----- Original Message -----
From: "Steve Atkins" <steve(_at_)blighty(_dot_)com>
"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 is about INBOUND. Not Outbound Mail. That would only cover a
possible
"no don't receive mail" policy. But I doubt this MX 0 is widely
supported.
The attempts I have researched shows very low usage and if found,
it is
mixed used with other non MX 0 statements. I hope this does not
begin to
chip away at SSP.
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.
Steve, the SPF example was just an example to Stephen, that such a "No
(Outbound) Mail expected" concept does exist and is used in
practice. If
AltaVista.com can do it, so can others.
[steve(_at_)goliath steve]$ host -t mx altavista.com
altavista.com mail is handled by 0 .
My point exactly. But even ignoring that option and just
comparing to SPF...
I can tell you that we will add a
NO MAIL POLICY to atleast 3-4 of our own domains if SSP was to
become part a
new wide adopted practice. We have no problem protecting local
policy when
the spoofs come out way. It is to expose to the external world not to
expect and accept such spoofs.
There is no need to tie "signing of email" to "this domain
sends no email". As such it's not something that _has_ to
be in SSP (unlike "We send no non-signed email"). If you
believe SSP has value you pretty much have to believe
the same of SPF, and SPF already supports making that
statement.
So the only advantage of supporting "we send no mail"
in SSP would be if you believe that the set of people who
look at SSP and do not look at SPF is noticably non-zero.
That's not a reason not to add support for this to SSP, though,
as long as you recognize that it's just adding a redundant
way of saying the same thing at the cost of a small increase
in complexity and risk of contradictory policy messages
via different communication channels.
Cheers,
Steve
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html