Hector Santos wrote:
[...]
Return-path is intended for (non)delivery notification, not for sender
verification. It is not reasonable to take return-path as an indicator
of sender identity.
Why not? I believe the presumption is made in RFC 1123 and in RFC 2821 that
DNS and error reporting is to be returned to a "existing" return path.
Otherwise what is the point of using a Return-Path: header?
I believe this needs to be made very clear.
Read Keith' answer again: he states: 'it is not reasonable to take
Return-path as an indicator of _sender_ identity'. And you are talking
about Return-path as the place to send notifications to. These are two
different things:
1. a mail address to send notifications to
2. a sender's identity
See also RFC2821:
When the delivery SMTP server makes the "final delivery" of a
message, it inserts a return-path line at the beginning of the mail
data. This use of return-path is required; mail systems MUST support
it. The return-path line preserves the information in the <reverse-
path> from the MAIL command. Here, final delivery means the message
has left the SMTP environment. Normally, this would mean it had been
delivered to the destination user or an associated mail drop, but in
some cases it may be further processed and transmitted by another
mail system.
It is possible for the mailbox in the return path to be different
from the actual sender's mailbox, for example, if error responses are
to be delivered to a special error handling mailbox rather than to
the message sender. When mailing lists are involved, this
arrangement is common and useful as a means of directing errors to
the list maintainer rather than the message originator.
The text above implies that the final mail data will begin with a
return path line, followed by one or more time stamp lines. These
lines will be followed by the mail data headers and body [32].
It is sometimes difficult for an SMTP server to determine whether or
not it is making final delivery since forwarding or other operations
may occur after the message is accepted for delivery. Consequently,
Klensin Standards Track [Page 50]
RFC 2821 Simple Mail Transfer Protocol April 2001
any further (forwarding, gateway, or relay) systems MAY remove the
return path and rebuild the MAIL command as needed to ensure that
exactly one such line appears in a delivered message.
A message-originating SMTP system SHOULD NOT send a message that
already contains a Return-path header. SMTP servers performing a
relay function MUST NOT inspect the message data, and especially not
to the extent needed to determine if Return-path headers are present.
SMTP servers making final delivery MAY remove Return-path headers
before adding their own.
The primary purpose of the Return-path is to designate the address to
which messages indicating non-delivery or other mail system failures
are to be sent. For this to be unambiguous, exactly one return path
SHOULD be present when the message is delivered. Systems using RFC
822 syntax with non-SMTP transports SHOULD designate an unambiguous
address, associated with the transport envelope, to which error
reports (e.g., non-delivery messages) should be sent.
So the Return-Path may change on the way to the recipient and is assumed
to be set by the MTA which does the final delivery. This shows you that
chances are high that the Return-Path header will not contain the
original Sender address and as such cannot be used for sender
verification purposes.
[...]
The problem I see here with some domain (specifically YAHOO.COM) is that
they delay the validating of the recipient until the DATA stage. So the
harvesting reason may people cite for not validating at the RCPT TO: is a
red herring IMO in the case of YAHOO.COM.
AFAIK MS Exchange does verify the syntax of an address during SMTP
transmission, but _not_ the existence of the recipient address. The
number of Exchange servers, connected directly to the Internet is
growing :-( As a side note: due to dictionary attacks mail system
managers will configure their mailservers (as far as the MTA supports
it) to always give a meaningless answer to the RCPT TO: command.
[...]
I can give you 6 months worth of millions of trace logs. I will be surprise
to see more than 0.01% of MAIL FROM: <> breaks. I will try to find this
count for you today.
I know that IMail (from Ipswitch, Inc., see http://www.ipswitch.com)
does provide a configuration option to block the NULL envelope From
address. I contacted them for this issue (as they provide their
customers with an option to violate the standards) and they were not
willing to change this configuration option. From my postmaster duties I
know that 1-2 percent of all external mail systems run IMail. And I've
seen other mailers rejecting NULL envelope From addresses.
[...]
True, if EVERYONE was using it. There will be a major DNS lookup overhead
when he CDN and RPD does not exist and this was empirically proven in our
testing as we tried to look for all possible ideas that can reduce the CBV
necessity. DMP and others, like RMX and SPF all suffer from the same
fundamental deployment flaw.
FYI: the current SPF draft claims to be a superset of RMX and DMP. See
http://spf.pobox.com/intro.html. I agree with you that SPF has its flaws.
The main problem in my view is that everybody tries to find his/her
solution to the SPAM problem, proposing all sorts of extensions to SMTP
or to the way MTA's handle mail, but there is no single coordinated task
force taking responsibility to start a _fundamental_ discussion about
how to solve/minimize this problem. Many proposed solutions are
solutions for an ideal world and don't take into account the real
messaging world of today (with a myriad of possible usages of e-mail).
E.g. the SPF folks assume that everybody will change the way they are
doing mail forwarding.
[...]
/rolf