For what its worth, Isn't the Return-Path: (like the old UUCP "From :")
considered "intermediate" network control header lines?
In other words, SMTP adds it for a Final Delivery or Local hosting domain,
but once the gate or server-side host mail importer deals with it, it is
removed.
This is how our system works, and I believe most work this way as well.
However I do see some systems retain the now useless Return-Path for user
mail pickup.
Example, with SLIP/UUCP, a "From " was added to address bounce situations:
SLIP/UUCP (From Added)
--> GATEWAY
---> USER STORAGE (From Removed)
---> DOWNLINK HOSTING STORAGE (From kept)
---> BOUNCE (From utilized for new notification)
This network control header line was removed once the gate determined a
valid final destination.
Similarly with SMTP:
SMTP (Return-Path Added)
--> GATEWAY
---> USER STORAGE (Return-Path Removed)
---> BOUNCE (Return-Path utilized for new notification)
Also I think it is a matter of implementation as well, on how the server
stores its mail and outbound queues.
For example: A system can retain the transport information in a local
storage format such as:
X-MAIL FROM:
X-RCPT TO:
X-DATA: [delimiter]
Return-Path: [only for local delivery]
Received:
Actual Email Data
The gate now handles this accordingly:
1) SMTP receives MDA or authorized relay mail The above format go into a
common inbound queue,
2) The SMTP router eyeballs the inbound queue to determine local vs. relay,
3) For Local, the gate takes the X-DATA block, strips Return-path:, imports
for user. A local validation is repeated. This allows the gate to create a
bounce just in case the SMTP process did not do it (bad practice today).
4) For Route, there is no Return-Path, and the relay will use the X- data
for the next SMTP send session.
The above is our current design for the Return-Path since 1996. It was
never designed to be passed on to the user.
Happy Holidays,
---
Hector Santos
WINSERVER "Wildcat! Interactive Net Server"
http://www.santronics.com
----- Original Message -----
From: "Bruce Lilly" <blilly(_at_)erols(_dot_)com>
To: <ietf-smtp(_at_)imc(_dot_)org>
Sent: Thursday, December 23, 2004 9:34 PM
Subject: Re: comments on draft-crocker-email-arch-01
On Thu December 23 2004 15:04, Tony Finch wrote:
I agree that the 822 message header is uncomfortably stuck doing two
jobs,
but I disagree that this implies that the term "envelope" should include
any header fields.
What about the Return-Path header field? It is explicitly defined
as containing the content of the SMTP MAIL FROM command when an
SMTP receiver makes "final" delivery. What about RFC 3939
Caller-ID, which is explicitly derived from handling information?
Neither was placed in the message content by the originator;
they are annotations made by transport processes.
I understand that there is a desire to distinguish content
following SMTP DATA from other SMTP command content, but SMTP
itself broke the analogy to postal mail by requiring (e-)mail
handlers to scribble on the message content (Mail-From and
Return-Path fields)[*]. It is desirable to be able to distinguish
end-to-end content (set by author and/or sender and intended
for the recipient(s)) from postmarks and other bits of
scribbling made during transport -- by continuation of the
analogy to postal mail, those postmarks and other notations
are placed on the envelope. The poster child case for making
the difference clear is the Reply-To field, which is clearly
intended as an end-to-end originator-specified field, but
which some errant transport entities have been known to
scribble upon.
The draft under discussion is about the overall architecture
rather than a nitty-gritty detail peculiar to SMTP
protocol. From an architectural point of view it is
important to distinguish the end-to-end, author/sender-to-
recipient information from ancillary notations (to
specify who/what may set/read which portions of a message),
and envelope/header/body work well as analogous terms;
the envelope is where transport-related scribbling (including
delivery status notification requests) is placed, the
header contains information set by the author, intended
for the recipient (which usually matches the envelope
instructions for delivery and indication of source, but
need not do so and after submission do not in fact affect
delivery) and is structured, while the body is free-form
content intended for end-to-end use.
The practice of transport processes scribbling envelope-
type markings on the message content (the header) began
with SMTP and is peculiar to SMTP; it was not so with FTP
or MTP, and is not so with UUCP mail transport. Although
SMTP is certainly an important protocol, I believe we
should not confuse its peculiarities with architectural
principles.
* and that bad practice has been adopted subsequently
by others, unfortunately