ietf-smtp
[Top] [All Lists]

Re: (lack of) message header field ordering

2005-03-15 09:03:38

This has been a very interesting discussion. I didn't follow all the details, but if I understand the bottom line, some MTAs do not follow the common practice of only prepending new headers. If these MTAs are rare on the public part of the Internet, and are non-compliant with existing standards in other ways, I would say ignoring them is OK.

If they are not so rare, and do in fact perform some useful function, we can deal with them as we do any untrusted source. We already block open relays, even though they may be SMTP compliant, and even if someone, somewhere, has an essential need for them. My goal is not to put spammers out of business, but just to keep them out of my inbox.

Immediate blocking is not the only option in handling messages from insecure MTAs. A properly designed authentication protocol will not *force* a policy on what domains should be blocked, but simply *facilitate* enforcement of a policy decision by the Recipient. Any complaints about "impairment of email" will then go to the intended Recipient.

Here is a typical scenario:

   Spammer -->  Forwarder -->  Receiver --> Recipient

I trust my own Forwarder, or I get another one. I am counting on the headers above and including the Forwarder's Received header to be unaltered by the Spammer. That will allow me to use the Spammer's domain name (authenticated by the Forwarder) as an input to my spam filter.

A slightly different scenario is that the Receiver does the filtering on behalf of all its Recipients. Then it could have a list of trusted forwarders, and step down through the pile of headers until it gets to the first domain not on the list. That domain will be used for filtering, just as if it had connected directly to the Receiver.

In either scenario it is the domain just ahead of the Recipient's Forwarder that gets rated. Normally, this is the Originator's domain, but it could be another Forwarder authorized by the Originator. The sticky situation is where we have somewhere in the middle a "text-to-binary translator", a "header randomizer", or some other weird thing not authorized by either the Originator or the Recipient.

Here is how I would write the requirements for a domain that wishes to participate in authenticated transfers:

From http://www.ece.arizona.edu/~edatools/etc/draft-authent-interop-00.htm:

5) If the message is forwarded, the results of authentication must be made
available to all subsequent receiving MTAs.  The format should be simple and
standardized to facilitate later blocking and filtering.

6) A Forwarder must not alter either the incoming headers nor the body of a
message.  Prepending of headers is acceptable.

6a) A Forwarder that needs to alter a message must act as a new Originator,
using a domain name for which it is authorized.

There are also some example headers further down in the draft.

Will these requirements conflict with any existing or proposed protocol? I'm looking for the minimum requirements that will still meet our goal of having simple and reliable inter-operation for all MTAs involved in an authenticated transfer.

-- Dave

*************************************************************     *
* David MacQuigg, PhD              * email:  dmq'at'gci-net.com   *  *
* IC Design Engineer               * phone:  USA 520-721-4583  *  *  *
* Analog Design Methodologies                                  *  *  *
*                                  * 9320 East Mikelyn Lane     * * *
* VRS Consulting, P.C.             * Tucson, Arizona 85710        *
*************************************************************     *