spf-discuss
[Top] [All Lists]

Re: X-trust-previous-hop:

2005-05-10 11:11:42
At 07:04 PM 5/10/2005 +0200, Julian Mehnle wrote:
Mark Shewmaker wrote:
> On Tue, May 10, 2005 at 02:54:33PM +0200, Julian Mehnle wrote:

> > > Generally internal MTA's fully trust their border MTAs not to lie,
> > > (and they know who these trusted MTA's are), but there's no way for
> > > an MUA reading the mail that passed through the internal MTA where
> > > the internal trust border ended.
> >
> > Yes, there is.  Do an MX lookup on the receiver domain.
>
> Problems:
>
> 1.  I don't fully understand how that's supposed to work.
>
>     How do MX lookups within an example.com domain let you
>     define a trust map within example.com of which machines
>     fully and completely trust which other machines as far
>     as email is concerned?

That's not what you asked.

This is my idea:  You can do an MX lookup and thereby find the edge MTAs.
Then you can find the topmost sequence (to account for internal hand-offs)
of "Received:" headers in a message that includes only edge MTAs.  The
lowermost "Received:" heder should be where the message entered the
receiver's trusted network, and all headers above that should be
trustworthy.

I admit I'm not entirely sure it would work reliably.  Some empirical
research would be necessary.

> 2.  It requires "internal" mx lookups to be externally accessable,
>     and match the external answers.

True.

> 3.  It requires the MUA to have an internet connection to simply
>     interpret and display authentication results.

True.

> Looking at this set of abbreviated email headers:
> [...]
> machine3.example.com is the border mta, which accepted an email whose
> first Received: line falsely claimed to be within the example.com
> domain.

Unfortunately, you omitted critical information from the "Received:"
headers.  But after I have looked at a message received at my mailbox at
my employer's network, I see that "Received:" lines are often incomplete,
so without additional information my approach is probably bound to fail in
most cases.  (Note to self: get my employer to fix his "Received:" lines.)

I think Received headers are such a mess, that trying to put authentication information into them is a mistake. An authentication header should be an undeniable statement - I authenticated this domain, using this method, and got this result. We need to know exactly who to blame if the authentication information is incorrect.

I do recognize the advantage of your trust trace header, I just think there
might be a simpler alternative.  I need to think more about it.

An important question remains: what abstract problem is being solved by
knowing the border MTAs of one's mail provider?

I think the fundamental requirement is that the destination MTA be able to quickly and unambiguously determine the domain names in the chain of trust back to the domain that it needs to query for a reputation score. I think the simplest way to do that is require that authentication headers have a standard position (the first header added by a border MTA, or maybe the second). Non-border MTA's should not add authentication headers.

I know this is fragile, but if a trusted forwarder screws up and forgets to add an authentication header, the worst that will happen is you get a burst of spam. The forwarder will fix the problem quickly, or lose his rating as a trusted forwarder.

The fragility is inherent in IP-authentication. A simple scheme like I am suggesting, may make the fragility obvious, but not any worse than it really is. The solution to this fragility, should it remain a long-term problem, is signatures.

Rating forwarders is a lot simpler than rating senders. Forwarders are not responsible for content. They get an A rating by properly authenticating the previous hop, and conforming to the standard placement and content of the authentication header.

--
Dave
************************************************************     *
* David MacQuigg, PhD      email:  dmquigg-spf at yahoo.com      *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                   9320 East Mikelyn Lane     * * *
* VRS Consulting, P.C.              Tucson, Arizona 85710        *
************************************************************ *


<Prev in Thread] Current Thread [Next in Thread>