From: "Frank Ellermann"
AFAIK it's common pratice to create some missing header fields
from the envelope if necessary, but with your "authority" you
can certainly show Henning something better than my hearsay to
prove your point:
Where exactly does any standard propose to create missing 2822
header fields from the envelope for received SMTP data ? I'm
sure where to find the opposite effect (envelope from header
fields) in Internet Standards, but I'm no "authority", maybe I
missed what your're talking about.
Frank,
The short answer is "Think Local vs. Route/Remote"
I can sit here and write a thesis on the subject based how it all evolved,
not just x821/x822, but the basic ingredients across many mail systems.
For our system, we have the general outline shown at:
http://www.santronics.com/images/wildcat.jpg
No matter what network you use, it all has to conform with the
specifications of the network I/O. For marketing reasons, we just show the
Internet components. But you can throw in there UTI, QWK, FIDONET and old
systems like MHS. Its all basically the same.
So what are you exactly asking here?
- Transport systems?
- Original Submissions?
- Routed? Passthrus?
- Final Destination/storage?
- BBS or Online Host Systems?
- Offline Mail Readers/Writers?
- Homogeneous vs. Heterogeneous networks?
I can give you a general idea on the automated concepts, but just keep in
mind that in the final analysis, we are dealing with end points, and that
doesn't necessarily means an RFC offline reader, but the input process and
the output, presentation and display aspects.
They all have one thing in common:
Date:
Subject:
From:
To:
So think about Local vs. Route. Think about what is necessary to complete
the fields for the endpoints.
When internet email comes in, in general wcSMTP server will determine:
- Authorization, if any
- Local vs. Remote
- Valid headers for Local storage
- Valid Headers for original submissions
For the most part, passthrus or routes are not touched with the required
exception to prepend the network trace fields.
For this specific issue (hotmail), the easy part is that we were talking
about no headers in the data block. This is an instant indication of an
Original Submission,. it can't be a MTA because it didn't have a Received
line.
In this case, we have:
From: <--- x821.MailFrom
To: <--- x821.RcptTo
So it was easy and all I was saying, in regard to Hotmail.com, there is no
reason to reject it because it is an original submission for a final
destination user. Not a route.
If was for a remote destination, well, first the session would have to be
authorized, but the MSA needs to make sure that the minimum requirements are
set. How that is done is based on 822 or 2822 level of support.
If you talking about "mixing" or "Insertion" ideas, where you have an some
level of x822 headers but not all, then the first question you need to ask
is what is considered valid.
What is valid and valid for what?
Is not valid, do you reject, add a new BLOCK? or just INSERT?
That is where we might get heated debates and I will agree with all sides
because there is no consistent across the board. In general, I have an
aversion to any idea of "mail tampering" so I prefer to keep as much as
possible the originality of the message intact. The idea of insert, just
creates new issues in regards to placement and ordering.
There are a lot of considerations, but when you are dealing with a local
final destination submission as in this case, where there is no header, it
is pretty easy, what the logic will be for completing the End point From:
To: and PRA requirement.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
