Re: X-header for forwarding MTAs

Craig Taylor wrote:
> 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.
Can you give a reason of why you would be interested in that? Can you 
rely on your forwarder to do the checking?
> 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.  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). 
> 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.
There was a "Received-SPF" header in the SPF draft. The problem with 
relying on headers is that they can be faked. This is one of the main 
issues we ran up against in the ASRG when discussing a common standard 
for MTA/MUA communications (for example, see 
http://216.239.39.104/search?q=cache:millenix.zemos.net/asrg-filtering/draft-irtf-asrg-filtering-header.html). 
 One of the easy ways in dealing with it, is simply stripping all 
previous headers which I believe what SpamAssassin does. This would be 
problem when multiple forwarding hops are involved but it might be 
sufficient for a case like the one you are talking about.
One of the beautiful things about Sender-ID and its related proposals is 
that they are based on one piece of data from the SMTP transaction that 
cannot be easily faked - the IP address of the incoming SMTP client 
(yes, I know about BGP attacks). The basic issue here is that Sender-ID 
is designed for MTA authorization which by definition is single-hop. 
Extending it past a single hop might better done with solutions like 
DomainKeys.
But, on the other hand it might be possible to use the information in 
the headers including the "Received" and "Resent-*" headers to backtrack 
 and verify each step. Of course, as William Leibzon pointed out in a 
different thread, that is not reliable.
Yakov