[Top] [All Lists]

Re: CBV systems - was Re: SMTP Extensions - proper peply code for disabled commands

2004-01-14 15:38:29

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 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 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.



<Prev in Thread] Current Thread [Next in Thread>