Subject: [Asrg] Latest version of the LMAP discussion paper

From: "Alan DeKok" <[email-masked]>
Date: Tue, 9 Dec 2003 16:02:07 -0500 (EST)

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

  It's also called -00 (like the previous one), because I've asked
Yakov to submit it as an Internet-Draft, and I expect that they will
number it -00.

  I've corrected a number of typos, and added suggested text.  I've
also removed some of the rants.

  Comments and suggestions are welcome.  I have a little more time
than I had a month ago, so I'm better able to discuss the document.

  Alan DeKok.

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 09 Dec 2003 16:10:12 -0500

[Subject changed as per posting guidelines. Mod.]

> 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

Yakov
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"But in this world nothing can be said to be certain, except death and 
taxes" (Benjamin Franklin)
-------

---

From: Markus Stumpf <[email-masked]>
Date: Tue, 9 Dec 2003 22:47:11 +0100

(Subject adjusted)

> than I had a month ago, so I'm better able to discuss the document.

I am still not really happy with the forwarding issues, especially with

*> 5.1.16 Factor 4.5 (16), Mailing Lists
*>   Most current mailing list software rewrites the MAIL FROM, to permit
*>   bounces to be sent back to the mailing list administrator.  These
*>   lists will be unaffected by LMAP (other than the issues raised above).

This is not true. A lot of MLMs adopt VERP style senders, i.e. they use
    newsletter-bounces-maex=[email-masked]
This allows tracking of bounces across forwards:
If in the above example
    [email-masked] -> [email-masked] -> [email-masked]
and [email-masked] fails the bounce will go back to
    newsletter-bounces-maex=[email-masked]
and the bounce handler can easily detect that the failing subscribed address
is [email-masked] and remove that from the list.
This will no longer be possible with LMAP and envelope sender rewriting.

*>   However, commercial and proprietary mail-forwarding
*>   systems alter the sender envelope, and these are by far the most
*>   popular pure mail-forwarding instances.

What numbers can you base the "most popular" on?
Also it is *very* problemativ to alter the sender to the address of the
forwarder:
   [email-masked] send message to [email-masked] which forwards to
   [email-masked].
Now the mailserver at example.org notices that [email-masked] ist over
mail quota. A bounce is sent back to the envelope sender. It is
important that the bounce is a fresh mail with fresh headers. The
original message may (or not) be attached to the bounce.

With the current Mail structure the bounce will go back to
[email-masked]. End.

With envelope sender rewriting the bounce will be sent to [email-masked],
which will change the envelope sender to [email-masked] and will forward
the message to [email-masked] which is over quota so the mailserver will
generate a bounce to [email-masked] which will change the ...
I think you get the point.
As the message is a fresh one no loop detection mechanisms will work:
not hop counting, not Delivered-To: checking, not Received: lines matching.

These kind of mailloops can only be broken by admins disabling the
forward from [email-masked] to [email-masked], as every new eMail arriving
at [email-masked] will trigger the problem immediately again until
[email-masked] is working again.

I'm seeing this behaviour with MS Exchange forwarders *very* often with
customers using our mailserver as a relay. This gives me the possibility
to "save" the customer and break the loop. I've seen cases where such a
loop made > 10 GB traffic within an hour.

Forcing users to envelope rewriting will make this kind of errors occur
a lot more often that now, to I think this has to be mentioned as it will
have a large impact on Efficiency, Costs, Reliability.

Also rewriting the sender will stop bounces from being returned to the
real originator after they have been forwarded.

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

---

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 9 Dec 2003 17:25:26 -0500

> >http://www.striker.ottawa.on.ca/~aland/draft-irtf-asrg-lmap-discussion-00.txt

Minor wording issues, second to last paragraph in 1.1:

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

I think "that informs the sender" or more simply "informing the sender"

   incoming IP address with LMAP.  It is to the advantage of all parties
   for a sender that will not be able to pass LMAP authentication to be
   able to discover the fact as early as possible and abort the
   transmission.

The last sentence is very hard to wrap my head around, perhaps partly
because "pass" initially makes me think "transmit" and not "pass vs
fail".  Maybe rearranging would help:

   If LMAP authentication is required by the receiver, it is to the
   benefit of all parties if a non-conforming sender can discover that
   fact early on and abort the transmission.

Sorry if that's too nit-picky, but I ran into a mental stop there.  :-)

mm

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 18 Dec 2003 17:59:37 -0500

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

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