Re: working group last call on ISP draft

[hansen@pegasus4.bl-els.att.com]

<< On a related note, I reread Randall's draft on the SUBMIT port and
<< disagree with section 5.3.1, which says that the MSA must look at what is
<< in the header found in the DATA, and then make certain corrections. I
<< think this would be sufficient grounds for many vendors to refuse to
<< switch to the SUBMIT port. Which could be a problem with getting the GRIP
<< recommendation to fly.

< 5.3.1 says MSAs MUST ensure that domains are fully-qualified.  That's not
< an unreasonable requirement.
<
< The SUBMIT background is that many currently-deployed MTAs look at the
< headers in the message data and make alterations.  In many cases these
< alterations are harmful, making problems worse.  Also in many cases these
< alterations are done to *all* messages passing through the MTA. The SUBMIT
< port is intended to formalize what changes can be made and to which
< messages.

There are also currently-deployed MTAs that touch NOTHING within the DATA
segment after adding the Received: header. It's fine to formalize what
changes can be made and to which messages, but I think >>mandating<< changes
within the DATA segment is going too far. Requiring that the MTA go in and
parse the headers of all messages so that it can potentially fix up a
problem which seldom shows up could be considered an onerous requirement.
It's one thing if you have an MTA which is already munging lots of headers,
but if you don't, adding even one header adds considerable overhead.

I'd be happy if section 5.3 were changed to be a MUST for addresses found
in the envelope and a MAY for addresses found in the DATA segment.

					Tony Hansen
			      tony@att.com, tony@attmail.com