ietf-mxcomp
[Top] [All Lists]

Re: X-header for forwarding MTAs

2004-09-03 16:10:19
At 04:05 PM 9/3/2004, Craig Taylor wrote:

Both Yakov , Thomas and others have made calls to focus on technical issues, so here's a strictly technical issue.

One of the weakness of SenderID is its exclusive focus on the last hop. If I receive my email via an alumni forwarding MTA, the alumni MTA might or might not run the SenderID check but regardless the MTA probably still accepts and passes the message through because it is a forwarder. When the message arrives at my MTA I can run the SenderID check but again I'll accept the message because it is coming from my alumni forwarder. What I'd like to know is if the connection to my forwarder failed the SenderID test.

Having as part of the standard some sort of x-header that well-behaving forwarders used would allow me to look beyond the last hop.

First, if it's important enough to implement in a uniform way around the world, then it should not be an X-something.

Second, this implies all those servers that haven't been touched, need to be touched. While adding in a new header might be less work than implementing Sender ID (if a site is even willing to consider implementing Sender ID), this means a lot of things will still break.

Seems like a non-starter to me.

For example, "x-senderid-result receiver=forwarder.com connecting-ip=x.x.x.x pra-result=fail". While such a record can be forged there is no reason to forge failures (what would be the point).

There may be a point to forging a failure if this results in significant headaches in the form of a denial of service.

Knowing that somewhere in the chain authentication has broken down would allow me to take further action based on failed authentication. In addition, the same header could potentially be used to communicate between the MTA and the MUA but that is another discussion probably best left to asrg.
Craig Taylor
VP, Technology
Ironport System
<Prev in Thread] Current Thread [Next in Thread>