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)
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.
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.
Neither RFC x822, x8221 goes into the guidelines of how to handle
"missing fields" but do indicate the minimum requirements:
To: (or bcc:, doesn't say cc:?)
2822: relaxes To:
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
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.
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
Any feedback would be appreciated.
Hector Santos, CTO