On Mon, Jul 19, 1999 at 07:24:41PM -0400, David Villeger wrote:
> Return-Path is added by the *final* transport system. So why is it added by
> qmail-inject?
rfc 821 seems to define "transport system" not as a host, but more
generally. Specificly, I think this would address the question:
When the receiver-SMTP makes the "final delivery" of a
message it inserts at the beginning of the mail data a
[... removes page break ...]
return path line. The return path line preserves the
information in the <reverse-path> from the MAIL command.
Here, final delivery means the message leaves the SMTP
world. Normally, this would mean it has been delivered to
the destination user, but in some cases it may be further
processed and transmitted by another mail system.
so a reverse-path would have to be provided in an smtp conversation.
To accomodate local and remote delivery, I'd guess that having it
start life as a return path is easier.
> On the same subject, if I send an email message to [EMAIL PROTECTED] without
> the Return-Path field (e.g. by using qmail-queue) but using VERP (so that
> the envelop sender becomes [EMAIL PROTECTED]), the
> email.com server writes the Return-Path as <[EMAIL PROTECTED]>
> stripping everything left of the equal sign.
They've broken themselves, I think.
> As far as I can tell this only happens with email.com (and other domain
> names they host). Is this a problem with their mail server or should I
> always include the Return-Path field, against RFC822?
Didn't RN send a message to the list about this? Bad, bad email.com.
--
The 5 year plan:
In five years we'll make up another plan.
Or just re-use this one.
