Re: [Fwd: [Asrg] Re: Documents for LMAP BOF]

Hadmut Danisch wrote:
> On Sun, Feb 08, 2004 at 05:45:19PM -0500, Yakov Shafranovich wrote:
 >>[snip]
>>Which brings us back to your original point - why do we want to 
>>authenticate identity? Identity of the incoming MTA or the sender by 
>>itself will be meaningeless unless combined with some form of a 
>>reputation system.
> 
> And that's where those problems begin SPF etc. don't solve.
> 
> In Germany, I am required to have an identity card, to provide
> an impressum on my web site and so on. 
> 
> What kind of reputation is there in the USA except for your
> driving license and Social security number? People use to 
> change their name arbitrarily and can lease domains anonymously 
> just by sending cash in a fedex envelope. I just learned that you 
> can even perform a conference at the MIT without leaving a track 
> of who is responsible.
> 
> That is the main problem.

That is indeed the deep problem with email, and much of human existence, but 
that is not what LMAP is meant to solve. Read on.

>>[snip]
>>As for stopping forgery, since this operates only on the SMTP Session 
>>level, it does not stop forgery of the mail content itself. Rather it 
>>autheticates the SMTP transaction which lets the network administrators 
>>complain to the originator. BUT, if the incoming IP is know, we know who 
>>the admin is anyway, so what's the point to tie it in with a domain.
> 
> Because a malicous admin (spammer's admins are malicous by definition)
> could still send tons of mail with forged sender addresses. If you tie
> it with a domain, the malicous admin is forced to use the own domain 
> name as the sender address. Unfortunately, the spam is still spam.

This is all that LMAP was really meant to solve. The early discussion drafts 
simply said 'we want to prevent joe jobs. Unfortunately, it gets extended 
and extended, until it's not good at anything.

> But it is a good protection in case the admin is not malicious. It
> stops those tons of worm and virus messages with forged sender
> addresses. 

This is also a good, and more importantly cheap and easy, goal to implement.

I think that any LMAP draft should handle these cases first and foremost, 
and anything further is icing on the cake.

> With the HELO approach anyone could still send messages with 
> sender domain @danisch.de. You will know whom to blame for doing 
> so, but this doesn't make you feel better. Blaming is slow and expensive.
> 
> With the sender approach only one machine could send messages from 
> @danisch.de. That's much better. 

Certainly is.

Philip Miller