On Thu, 29 Dec 2005, Terry Fielder wrote:
"accept email" != "send email"
It's too bad one has to read the whole RFC to get the picture that, in
the context of NULL MX "accept email" == "send email" by implication.
Would have been clearer to me on first read if: "This document formally
defines the "NULL MX" as a simple mechanism by which a domain can
indicate that it will never accept email and therefore (implies?) also
does not send email"
Could you define what "domain does not send email" means?
Probably one of:
1) domain will not be used in the domain component of the RFC2821 Mail From
OR
2) domain will not be used in the domain component of the RFC2821 or RFC2822
Mail From
Point taken, being concise makes it wordy. But clarifying what "domain does
not send email" means later in the document could still add to the clarity.
Or do you think there is a different feasible interpretation then my
suggested 1 or 2?
#1 is already certain since by having domain in return-path implies
you'd accept bounces to it, that is pretty basic rule from RFC821 and
all successors.
#2 as with RFC2822 From header field more interesting. Lets assume we have
"example.com. IN MX 0 ."
If we assume that #2 is not true, then one can continue to legitimately
send email with "bob(_at_)example(_dot_)com" in From. Now lets assume that somebody
else received email from bob that he thinks violates some known rules or
laws (or maybe bob is misrepresenting example.com) and wants to send a
complaint back. If you look at the RFCs, they basically say that you
need to complain either directly (to bob(_at_)example(_dot_)com) or generally to
abuse(_at_)example(_dot_)com(_dot_) But example.com does not accept emails so
you
have no legitimate address to complain to...
So having established #2, your next question is what happens if somebody
uses example.com as domain in "Sender:" header field. Would that be
legitimate? I think I can easily make the same argument as above to show
that if you use some domain in Sender you might expect that there maybe
cases where you need to send complaint (certainly Sender has as actual
entity sending email has responsibility to make sure it complies with
receiving end policies if it knows about them).
So we end up expanding #2 to include "From and Sender" header fields.
Now as you know I'm big "fan" of Resent- :) So my next question is
obvious - what about Resent-From and Resent-Sender? Since they are
used as authorship fields by email direct users (senders) in the same
way as "Sender", the argument would also be true.... Now the next one
(not from SID) is what do you expect if somebody puts address in
"Reply-To:" and you can not send email to that address - is that
legitimate use of domain? You can expand this further with couple
other header fields too...
Now here less obvious one - if you see hostname in Received (say EHLO)
and you can not send email to abuse(_at_)hostname is that legitimate use of
the domain or hostname in EHLO? Actually if you read RFC2142, it says
"[RFC822 6.3, C.6] requires the presence of a <POSTMASTER(_at_)domain>
mailbox name on all hosts that have an SMTP server.". So this means
the domain/host with "mx ." can not be EHLO name and can not appear
in Received. I care to generalize and say we can probably expect that
it can not be used in some other header field either and in general
can not be used within context of RFC2822 and RFC2821 mail application.
The interesting thing is even that is not enough - if you go back to
RFC2142 it is clear that other protocols have their own email address
that hosts that participate in protocols are expected to accept email
to in case of problems and there is also general line "Defacto standards
also exist for well known mailbox names which have nothing to do with a
particular protocol, <ABUSE(_at_)domain> and <TROUBLE(_at_)domain>". But if we
expand it to mean that domain can not be used with any protocol, why
is it in the dns in the first place?
So the problem with having such seemingly simple statement as "domain
does not accept email" is that it can be interpreted way too far.
I think possibility of such generalization and unclear statement is
not helpful and it is better to use specific statement that you know
applies to particular identity (i.e."v=spf1 -all" as it applies to
RFC2821 MAIL FROM) or otherwise the draft MUST specify exactly what
it means when "mx ." is there and it should be something lot better
then just "domain does not accept email".
Considering controversy that already exist in deciding if "." is
actually legitimate hostname for MX in the first place, I think
we're better off not using it, at least not with the draft in its
current form.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com