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 *
************************************************************* *