Re: X-header for forwarding MTAs

[Daniel Senie <dts@xxxxxxxxx>]

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