On Mon, 26 Jan 2009, My BSD wrote:

> On Thu, 27 Nov 2008 09:27:47 -0800 (PST)
> davidel at xmailserver.org (Davide Libenzi) wrote:
> 
> >  ... <snip> ... 
> > 
> > The Return-Path header must be set only when SMTP servers do the "final 
> > delivery" on the recipient mailbox.
> > An MTA->MTA message must not set Return-Path. XMail inserts the 
> > Return-Path only when dropping messages inside its own mailboxes (final 
> > deliveries).
> > 
> > "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."
> > 
> > Note that there are historical issues about the Return-Path, and note the 
> > phrase "message has left the SMTP environment". In todays infrastrucutre, 
> > the SMTP "environment" is left only when a message is finally delivered.
> > 
> >  ... <snip> ...  
> 
> Good day Davide.
> 
> Built XMail v. 1.26-pre05, have been testing it for the last several weeks 
> and,
> so far, am mostly pleased with it.  Looked through the list archives to not
> re-invent the wheel and found this old thread that is right on point with my
> questions and comments.
> 
> Noticed two peculiarities about how XMail handles the Return-Path header:
> If there is an existing R-P header it neither prepends a new one nor truncates
> the old one.  (This happens when messages already containing an R-P header
> are relayed to XMail with sendmail or SMTP.)
> 
> Looked at the source and it seems that this behavior is by design.  XMail
> has been coded to intentionally look for an existing R-P header and neither
> truncate it nor prepend a new one if it finds it.
> 
> As I understand it, the delivering MTA normally deletes any existing R-P
> header and prepends a new one upon delivery.
> 
> My workaround was/is a hack to the source to always prepend an R-P header
> upon delivery.  Any existing R-P header is truncated by an incoming filter
> that invokes a perl one liner.  
> 
> I would suggest that XMail should do this natively and that the user should
> not have to resort to a gross hack like mine.

I thought I explained pretty clearly the behavior, by citing even the RFC. 
MTA -> MTA transaction does not fit the bill of "message has left the SMTP 
environment" in my books. MTA -> Mailbox does, and that when XMail does 
actually something WRT Return-Path.



- Davide


_______________________________________________
xmail mailing list
[email protected]
http://xmailserver.org/mailman/listinfo/xmail

Reply via email to