Hi Hector,
At 15:00 09-06-2008, Hector Santos wrote:
We are updating our mail system, one which a rich history of uucp,
822, 821 semantics and within the last 3-4 years mixed in 2822, 2821 semantics.
We few recent reports highlighted or open up the need to rethink how
some the handling of missing fields is done.
I would like to get the feel or BCP for the following:
- missing To: fields
- missing Date: fields
- missing From: fields
- 822 vs 2822
- Local vs Remote Routing (i.e, Passthrus)
I'll use draft-resnick-2822upd as the reference as that's what most
of the participants agreed upon. Section 3.6 defines two fields,
i.e. the Date: and From: which should be included.
To illustrate the issue, we had a customer who was wondering why our
server reacted differently to what he thought was the same message
received two different ways. But in fact:
a) The original message had a missing date:
b) Route #1, added a date before it was sent to his server
c) Route #2, did not add a date before it was sent to his server
I'm still trying to figure out how he got this to happen (the
original message took two different routes), but the with the route
taken not having a date, it was flagged on our system.
Some MTAs "fix" the headers.
I have no problem with local created mail for outbound corrective
actions (or PORT 587), but I have a problem with correction of
incoming remote mail, especially if its anonymous.
But thats a specific issue, and I would like to hear what would be a
general case ideals for these type of things.
Section 6.3 of RFC 2821 talks about "Compensating for Irregularities".
Neither RFC x822, x8221 goes into the guidelines of how to handle
"missing fields" but do indicate the minimum requirements:
822:
Date:
From:
To: (or bcc:, doesn't say cc:?)
2822: relaxes To:
Date:
From:
Our history of enforcing this was:
198?-1998 ~822 rule -> Date: && To:
1998-2003 ~822 rule -> To: && (Date: || Received: || From:)
2003-now 2822 option: -> Date: && From:
In the early 90, the mail system was still modeled over a UUCP
system, and the router had only a Date: and To: requirement. I
guess because the "From " or the Return-Path was part of the
received email or file it was handling.
I did not take over the engineering until 1998, but it was one of
the first thing we changed, and at best I can recall to reduce a
high rate of missing date: errors, was to relaxed it to a rule:
To: && (Date: || Received: || From:)
this worked very well.
I've come across cases where any one or more of these fields missing.
In our on-going efforts to support 2822/2821, we few years back we
added the 2822 support to relaxed the to: requirement. But with
this 2822 rule enabled, we introduced again the Date: and From: requirement.
Probably, our mistake, again in an effort to support 2822, we made
this option default, so this is why we are getting more reports. I
am thinking of turning off the default to stop surprising customers.
I guess what I would like to hear is how systems should deal with all this.
If you look at it from a MUA perspective (receiver), a missing From:
or Date: affects the rendering of that information. From a sender's
perspective, missing some of these fields would get the message
flagged by mail filters. That can be addressed during message
submission. Please see the Section 3.6 of RFC 2821 if the MTA is
acting as a relay. It has a "MUST NOT" for applying changes.
The general idea is that the less information you have about the
client, the less likely the changes will be correct. For example,
the Date: conveys more information than a simple date field and a
receiver cannot synthesize that.
Regards,
-sm