RE: [exim] Is there and logical reason to reject mail from: …

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Exim User's Mailing List
Ημερομηνία:  
Προς: jori.hamalainen
Υ/ο: Exim User's Mailing List
Αντικείμενο: RE: [exim] Is there and logical reason to reject mail from: <> ?
[ On Friday, October 15, 2004 at 13:32:08 (+0300), jori.hamalainen@??? wrote: ]
> Subject: RE: [exim] Is there and logical reason to reject mail from: <> ?
>
> I always wonder why SMTP-RFC didn't do it differently. Always use
> normal sender/recipient information, but for 'bounce' messages use
> "ERROR"-command instead of DATA. And if on "ERROR" makes another
> "ERROR", don't send it to avoid loops. Besides this functionality
> "ERROR" would work like DATA. Too simple?


No, that would be too complex. :-)

SMTP error handling is done "in-band" -- that way the error messages
usually go back to the person most interested in correcting them (though
of course the world of e-commerce has changed that outlook somewhat).

It also means that the dynamic many-hop store-and-forward nature of SMTP
is inherently supported in the error handling mechanism.

One thing that's been missed by many SMTP implementers (even many who
should ahve known better) is that the sender address is only supposed to
be the very last resort. All errors should be reported in direct and
immediate SMTP responses to SMTP commands. A mail server should never
accept a message that it might not be able to deliver -- and the very
nature of the way the sender address is specified makes this doubly
important. The MTA must make every effort mechanically possible to be
sure it will be able to deliver the message to the specified recipients
before it accepts it because the likelyhood that the bounce can be
delivered is far smaller still. Bounce messages must only be generated
if there has been a critical insurmountable system failure which could
not be predicted at the time the message was accepted.

Remember, if the vast majority of all operating MTAs were to implement
this rule then the problem of backscatter would be non-existant in the
first place. That's the most frustrating aspect of this problem.

-- 
                        Greg A. Woods


+1 416 218-0098                  VE3TCP            RoboHack <woods@???>
Planix, Inc. <woods@???>          Secrets of the Weird <woods@???>