Hallam-Baker, Phillip <pbaker(_at_)verisign(_dot_)com> wrote:
[Andrew Newton <andy(_at_)hxr(_dot_)us> wrote:]
2821 HELO/EHLO domain
2821 MAIL FROM
2822 From:
2822 Sender:
New structure/RR's in .arpa *
...
I believe that there are roles for each of these as follows:
First let us define the term 'consistent value' to mean that
the domain component of an address either has no corresponding
profile record or if one exists it is consistent with the profile
record.
Understood.
However, I suspect that "requiring" "consistent value" will be
out of scope for <mxcomp>. Let's see if we can restate some of this
as semantics:
2821 HELO/EHLO domain
Setting this to a consistent value is not difficult.
There is no reason that email senders should not be required
to always return a consistent value.
In many cases a mail server is configured to serve more than
one domain. This means that the resolution available
is less than would be required for some purposes.
The DNS address of the mail server is likely to be the the
address of the server rather than the message domain.
"SMTP senders wishing to take advantage of the RFC2821 (envelope)
features of this Standard SHOULD set the HELO/EHLO domain to a domain
which serves the appropriate DNS record(s)."
2821 MAIL FROM
This value is empty <> for bounce messages.
If this value is defined, it should be consistent for direct
sent mail.
"SMTP senders wishing to take advantage of the RFC2821 (envelope)
features of this Standard SHOULD set this fields such that the domain
part matches a domain which serves the appropriate DNS record(s).
If the domain part does not match a domain which serves any appropriate
DNS records, SMTP receivers SHOULD not (initially) reject messages,
but MAY take measures to encourage the domain in question to start
serving the appropriate DNS record(s). If the domain part matches a
domain part which serves the DNS records here, but the IP address of
the SMTP sender is not in the set of authorized MTAs, the SMTP receiver
SHOULD reject the email or mark it as unauthorized before passing it on."
(Sorry about the length of that one...)
If a mail forwarder uses the original From value, this
value will be inconsistent.
If a mail forwarder uses the Sender value a consistent value
can be provided.
There is no reason that email senders should not be required
to always return a consistent value.
(I can't figure how to restate these to be in-scope.)
I believe that we should consider these 'identities' as a pair. It
is not always possible to rely on FROM, the value returned in HELO
is tied to the server itself rather than the message.
I think I agree. There is room for question whether the (authorized)
HELO domain should serve for a bounce in the event that the MAIL FROM
proves to be unauthorized.
2822 From:
This value is presented to the user by most MUAs, it is thus
the only value that is usefull to prevent impersonation
spam.
I always cringe at the word "only".
However, we should (IMHO) look for a way to permit authorization
of this field, since the perception is very strong that impersonation
is a serious spam problem.
This value will not be consistent if the sender uses a direct
connection to the destination MTA to send the mail, this
is however a distinctly minority configuration which in
any case is problematic due to port 25 blocking.
I'm hoping we can agree to recommend that individual user MUAs
make use of SMTP SUBMIT (port 587) for connecting to the initial
MTA. Port 25 blocking isn't going to go away; port 587 blocking is
rare (AFAIK), and doesn't lead to the same problems which caused
so many ISPs and corporate MTAs to block port 25.
This value will not be consistent if the mail has been forwarded,
but in this case Sender should be set.
"Individual (human) e-mail senders wishing to take advantage of
this Standard SHOULD ensure that their MUA is configured to put a
string in the RFC2822 Sender header containing a domain part which
matches a domain serving DNS record(s) authorizing the IP address
of the actual sending MTA."
But we need more than that. Perhaps:
"Alternatively, sending MTAs which wish to take advantage of this
Standard but know they will have users wishing to set the RFC2822
From header to a different domain MAY prepend a From header listing
a domain which matches a domain serving the appropriate DNS record(s)."
2822 Sender:
The main importance of this field is that it tells you to
expect RFC 822 validation to fail.
I assume Phillip means RFC2822 From validation will fail.
The sender can be validated to assist anti-phishing
"Receiving MTAs MAY attempt validation of the authorization of
the IP address of the sending MTA in order to distinguish whether
email with a RFC2822 From address appearing to be forged has in
fact be authorised by the domain listed in the RFC2822 Sender
header."
====
Please correct any misstatements or misinterpretations of my
language here, which merely attempts to be a succinct but complete
restatement of Phillip's ideas.
--
John Leslie <john(_at_)jlc(_dot_)net>