On Thu, 18 Nov 2004 22:41:49 -0800, Dave Crocker <dhc(_at_)dcrocker(_dot_)net>
wrote:
On Fri, 19 Nov 2004 00:58:50 +0100, Frank Ellermann wrote:
But I agree with you that a technical problem between my box and
anybody else should be reported to me and not to Dave - if he sent
the mail in question from my box... ;-)
a problem between your box and anyone else is detected during the smtp
session and needs to be reported to the box's admin. a bounce is for
notifying the originator/poster of the message about problems getting it
delivered. hence, it is for end-to-end problems, not hop-by-hop.
I'm going to have to disagree with you here Dave. By definition
bounces are not end-to-end. They are point to point (sometimes
indirectly). As an MTA (administrator) I only know for sure the
immediate upstream (whether MTA or MUA) and downstream (whether MTA or
MUA). I know the code and whatever messaging given for the bounce but
I don't know whether that MTA would/could have delivered directly to
the end user client or whether it needed to relay/forward to another
MTA (or more).
This issue is exactly why many claim that SPF is flawed (because it
does not provide a solution for multiple hops). I happen to believe
that it is good at what it does and nothing more. If you choose to use
a hammer to pound in screws your results may vary. The only thing that
SPF does is prevent domain forgery for the bounce path...and it only
truly does it on a single hop basis. Otherwise people wouldn't be
discussing SES, SRS or any other scheme to protect multiple hops.
I'm going to use AOL (sorry Carl) as an example. Sometimes I get the
bounce when my MTA connects to their MTA. Sometimes I get a bounce
from another AOL MTA after the particular email was initially accepted
by an AOL MTA. Not knowing AOLs internal architecture, I have no way
of knowing if either the initial or second MTA is the final MTA to
handle the mail before it is passed to the users email client.
How can you describe this process as end-to-end ?
Mike