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