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

On Sun, Feb 08, 2004 at 02:41:20PM -0500, Yakov Shafranovich wrote:
> 
> " LMAP is based on two concepts: publication of authorization
>   data by a domain, and application of that data by a recipient
>   MTA.
> "
> 
> or perhaps like this:
> 
> " LMAP is based on two concepts: publication of policy
>   data by a domain, and application of that data by a recipient
>   MTA.
> "


I'd take the first one except that "concept" is the wrong 
word. Two steps? Or maybe 

- the domain owner publishes authorization data in the DNS
- the recipient's MTA fetches and applies it









> I believe that SpamAssasin's implementation of SPF looks at headers as 
> well since it does not have access to the SMTP session information. 

That happens with those guerilla standards. Everyone is cooking 
a different soup. Perfect way to cause a lot of trouble and 
confusion.

BTW, SpamAssasin is the wrong place to implement it IMHO for
several reasons (basically the same reasons I mentioned in my
comment to the Microsoft draft where they also wanted to do 
a late verification at MUA level).

- It's too late, maybe the records have changed meanwhile
- There is no reliable method to determine the IP address
- It's too late to correctly reject the message


The mechanism _MUST_ be implemented in the MTA and peformed
before the final OK is answered to the DATA command.





> Since MSFT has so far not submited its draft to the IETF, we would 
> include something along the following without referencing them directly:
> 
> "It is also possible to verify LMAP data by parsing the Received headers 
> of the message, although this method is not as fool proof or reliable as 
> doing so at the MTA level. Additionally, spammers may choose to fake 
> Received headers, further complicating such analysis."


That's Blabla.

Leave it out and stick to envelope sender and maybe HELO.

Discuss the proposal from Microsoft's CallerID draft and if it is good 
change and extent the draft later, but don't try to define things you 
don't know yet. 










> We cannot put in a flag day. Until LMAP is deployed widely, it would 
> have to be used as a whitelisting method or something that raises the 
> likehood of a message not being spam. It is very possible that wide 
> scale deployment might take years so putting a specific date will cause 
> problems. I think that the statement that non-LMAP data can be treated 
> as it is today is sufficient.

_can_ be treated might be ok. 











> So basically there are:
> 1. IP address of the MTA.
> 2. Information about the sender.

? What exactly does "Information about the sender" mean?
Do we know anything except the IP address? Or does this
mean the mail address the sender wishes to use? 







> There are two types of authorization possibilities here:
> 1. Whether the incoming IP is authorized to be an MTA.
> 2. Whether the incoming IP is authorized to use the domain.
> 
> I do not see a third identifier, perhaps you can elaborate?





1. The IP address as a verified identifier for the caller

2. The mail address / helo name the caller wishes to use

3. A lookup key calculated from 1 and 2. It depends on the 
   IP address and mail address as parameters and on what 
   we like to define as a conversion function.

   This is more to be theoretically precise and to do exact
   engineering. You can't use the mail address to perform a lookup
   directly. 

   The current function would be: Take the domain part and prepend it 
   with _lmap or whatever. 

   But from my point of view it is important to take and treat this 
   as an explicit conversion function, even if it might be trivial 
   at the moment.




regards
Hadmut