Re: [Asrg] 6. Proposals - LMAP - Latest version of the LMAP discussion paper

Yakov Shafranovich wrote:
> Alan DeKok wrote:
> 
>>   I've updated the LMAP discussion paper, and put the latest copy on
>> my web site at:
>>
>> http://www.striker.ottawa.on.ca/~aland/draft-irtf-asrg-lmap-discussion-00.txt 
>> 
> In case we get SlashDoted, a copy is also available on the ASRG worksite 
> at:
> 
> http://asrg.kavi.com/apps/group_public/download.php/18/draft-irtf-asrg-lmap-discussion-00.txt 
> 

Some comments on the document:

Please add the following towards the beginning:

> NOTE: This document is intended to evolve, based on comments
>       from the Anti-Spam Research Group (ASRG) mailing list.
>       It is certain that the current draft is incomplete and
>       entirely possible that it is inaccurate. Hence, comments
>       are eagerly sought, preferably in the form of suggested
>       text changes, and preferably on the ASRG mailing list,
>       at <[email protected]>.
> 
> NOTE: This protocol is experimental and is not suitable for
> wide spread deployment or production use.

Section 1.1:
> 
>    The policy published by a domain includes statements as to which IP's
>    are permitted to claim association with the domain in SMTP EHLO/HELO
>    and MAIL FROM.  That policy can request certain decisions to be made
>    by a recipient on behalf of the domain.  For example, "mail from
>    example.com originates solely from the machine mail.example.com.
>    Please reject mail allegedly from example.com which originates
>    elsewhere."

I would also add information here about MTA MARK.

>    SMTP recipients can look up this policy when a domain name is used in
>    EHLO/HELO and/or MAIL FROM.  The recipient can then choose to apply
>    the requested policy to the message.

We can also mention that nothing steps someone from checking the LMAP 
information against the "From" address inside the actual message body, 
resulting in a 5xx code after the DATA command. We should also decide 
whether such behavior should be encouraged or discouraged.

>    Note that recipients should also publish that they use/enforce LMAP.
>    Receiving mail transport agents using protocols with the ability to
>    advertise capabilities should advertise a capability to the sender
>    that informs the that the sender that the receiver will check the
>    incoming IP address with LMAP.

Have any proposals addressed this? Is this something that should be done 
via the SMTP banner, DNS records, or perhaps an ESMTP extension?

> 
> 
> 2. Problem Statement and Scope
> 
>    LMAP addresses the problem of forgeries in the argument field of SMTP
>    EHLO/HELO, and SMTP MAIL FROM.  It does not use or examine any other
>    argument of any other field of the SMTP protocol.  Specifically, no
>    information in the body (DATA portion) of an SMTP message is used in
>    any part of LMAP.  Examination, validation, or verification of the
>    body "From:" is explicitly not part of this proposal, and this
>    proposal should not be represented as using body "From:".

But should we encourage such behavior or discourage it? The current text 
seems to stay away from the issue.

> 
> 
> 2.2 Scope of the proposal
 > 2.3 Scope of the Problem

Some information should also be added about the MTA MARK proposal. The 
entire LMAP idea is about publishing policy decisions on the Internet, 
and the MTA MARK proposal does the same for IP addresses, that 
RMX/DMP/DRIP/etc. do for domains.

> 2.3.1 Junk Email
>
>    Since this proposal does not examine or verify the body From: field,
>    there is still the possibility for spammers to use that field to
>    fraudulently claim assocation with a well-known domain.  We leave
>    that problem to be addressed by a method other than LMAP.  We will
>    recommend, however, that recipients take additional care when
>    accepting messages where the domain in the envelope MAIL FROM does
>    not match the domain in the body From:.  Such messages have greater
>    potential to be forgeries than messages where the domains are
>    identical, and where an accountability system exists.

What kind of care can be taken in this instance? Since the MTA cannot 
modify the "From" headers, either a custom header or something in the 
"Received" headers should be added?

> 
> 
> 2.3.2 Viruses, Trojans, and Worms
> 
>    While many malicious programs sometimes use the infected machine's
>    sender address, they rarely use the sender domain's resources to send
>    copies of itself, instead running their own SMTP engines.
> 
>    Domains implementing LMAP may reject copies of viruses and other
>    malicious software sent in this manner.  This method does have
>    limitations, however, see also Section 2.4.3.

More text on MTA MARK can be useful here as well.

> 
> 
> 2.4.1 Junk Email with Correct Envelope Information
> 
>    LMAP can not stop a spammer from using envelope information that they
>    are authorized to use.  However, maintainers of a spammer's domain
>    could audit their activity more effectively, as the spammer is forced
>    to use their correct information.
> 
>    If spammers maintain their own domains, domain-based blocking becomes
>    more effective.  In extreme cases, where a spammer hosts multiple
>    domains, blocking the authoritative DNS servers for the spammer's
>    domains becomes very effective, as the recipient could reject all
>    LMAP lookups on the spammers' DNS servers. They would effectively
>    reject all email from domains hosted there.

We have to address the fact that spammers can register new domains much 
faster than we can block them. The bit about DNS servers might also be a 
bit controversial, since possible fallout can affect others hosted on 
the same DNS servers.

> 
> 
> 2.7 DNS based attacks

You can add a reference here to the draft published by one of the DNS 
working groups on the subject, it has an entire list of issues. DNS SEC 
can be mentioned as well:

http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-threats-05.txt







-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"I ate your Web page. / Forgive me. It was juicy / And tart on my 
tongue." (MIT's 404 Message)
-------