tomas(_dot_)fasth(_at_)twinspot(_dot_)net (Tomas Fasth) wrote on 19.11.97 in
<34730E89(_dot_)7E2BE79(_at_)twinspot(_dot_)net>:
Chris Newman wrote:
This is incorrect. UAs will have access to the "MAIL FROM" address unl
ess
an upstream system violated Internet standards. The final delivery age
nt
is REQUIRED to copy the "MAIL FROM" address into the "Return-Path"
header. Anything which doesn't is broken.
Chris, can you give us the exact location in an RFC that backs up your
assertion? I'm not sure it is required and I'm not sure you can ever
rely
RFC 821, of course - this has been true as long as there has been SMTP.
And here I thought everyone knew _that_ one ...
--- snip ---
When the receiver-SMTP makes the "final delivery" of a
message it inserts at the beginning of the mail data a
Postel [Page 21]
August 1982 RFC 821
Simple Mail Transfer Protocol
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.
It is possible for the mailbox in the return path be
different from the actual sender's mailbox, for example,
if error responses are to be delivered a special error
handling mailbox rather than the message senders.
The preceding two paragraphs imply 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 header and body [2]. See Example 8.
--- snip ---
If you do SMTP, and ignore RFC 821, then you're definitely seriously
broken.
on it's existence once the message have moved into the domain of the
MUA.
If you don't have it at that point, then you're not in the Internet any
more.
If you're right, my FreeBSD "out-of-the-box" installation is certainly
broken. The "P" flag required to generate the Return-Path header is
_not_
set for the local mailer by default. I don't know why, but the very
existence of this discrepency (the fact that it's optional) is enough
for
me to maintain that this header might not always be available. Period.
If that's true, you should file a bug report with the FreeBSD people.
Period.
Standards should not cater to software that is already ignoring the most
fundamental standards in that area. That's pointless.
MfG Kai