Subject: X-header for forwarding MTAs

From: "Craig Taylor" <[email-masked]>
Date: Fri, 3 Sep 2004 13:05:49 -0700

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

Craig Taylor
VP, Technology
Ironport System

---

From: Max Kanat-Alexander <[email-masked]>
Date: Fri, 03 Sep 2004 14:46:21 -0700

On Fri, 2004-09-03 at 13:05, Craig Taylor wrote:
> Having as part of the standard some sort of x-header that
> well-behaving forwarders used [snip]

	My understanding was that this is the purpose of the Resent-* headers.

	-Max
-- 
Maxwell Kanat-Alexander
2nd Level Tech Support Engineer, USA
Kerio Technologies, Inc.
2041 Mission College Blvd. Suite 100
Santa Clara, CA 95054
Phone: (408) 496-4500
Fax: (408) 496-6902
Web: http://www.kerio.com/support.html

---

From: Yakov Shafranovich <[email-masked]>
Date: Fri, 03 Sep 2004 17:44:51 -0400

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

> 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

---

From: Daniel Senie <[email-masked]>
Date: Fri, 03 Sep 2004 19:09:39 -0400

At 04:05 PM 9/3/2004, 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.
>
>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 

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