Subject: [Asrg] 6. Proposals - DNS-Based - LMAP

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 10 Nov 2003 20:59:52 -0500

Just a reminder that a draft of the LMAP discussion document has been 
posted and is available at:

http://asrg.kavi.com/apps/group_public/download.php/15/draft-irtf-asrg-lmap-discussion-00.txt

 From the abstract:

------------
"  The Lightweight MTA Authentication Protocol (LMAP) [ref] has been
    proposed as a method to help address the spam problem.  That document
    describes the design of the protocol.  This document discusses the
    applicability, and the costs and benefits of wide-spread deployment
    of that protocol."
------------

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

---

From: Matthew Elvey <[email-masked]>
Date: Thu, 13 Nov 2003 21:42:01 -0800

> http://asrg.kavi.com/apps/group_public/download.php/15/draft-irtf-asrg-lmap-discussion-00.txt 

My feedback:

Typos: propogation, matcg and Columes aren't words.
====
No reason for including mention of ASRG is provided. Add
"A private list of LMAP type proposal writers from the ASRG hashed out 
an initial version of this spec, which was then posted to the ASRG 
mailing list for further discussion." ?
===
Indeed, we should remove the possibly OT paragraphs in 2.1.2.  (C-R and 
SMTP AUTH may well be critically flawed, but they're OT, and have found 
significant use)
===
3.3 needs a correction. It falsely states that content filters can only 
work if the email has already been accepted.
It should instead say "... has already been _received_." It is perfectly 
acceptable, per RFC 2821, to send a <550 refusal to accept for policy 
reasons> in response to the end-of-data indication, and thereby not 
accept the email.  SpamAssassin, for example can be configured to 
operate this way.
===
Re:    "Note that recipients should also publish that they use/enforce 
LMAP.
           (Ed.: This topic should be addressed in more detail.)"
It would be good if there were a standard computer-readable way for this 
to be determined.  (Some possibilities:
a welcome message
or response to the EHLO/HELO
(like "LMAP required" or "LMAP used" added to the "No UCE permitted." 
when one connects to, e.g. smtp.us.messagingengine.com)
, or a DNS entry for the recipient domain.)
Perhaps we should not say that MUAs MUST NOT use/enforce LMAP at all, 
which is something the current spec states implicitly - by saying that 
LMAP is only about MTAs.
We should say that MUAs MUST NOT send forged* email to the alleged 
sender in order to indicate that they use/enforce LMAP.
We should encourage MTAs to  refuse forged* email during the SMTP 
session, and if that's not possible, either accept and tag it, or 
discard it.

*"forged" strictly as defined in the spec, not any kind of forgery!
===
In "'An individuals "freedom of speech", " individuals should have an 
apostrophe: individual's.
They're US-centric (as is the spam problem, as 
http://www.spamhaus.org/rokso/ proves) but I'd like to see the following 
quotes added, though I can't really present a strong argument for it, 
beyond being on topic and really good quites:
*US Federal Judge Stanley Sporkin:*
"[Spammers] have come to court not because their freedom of speech is 
threatened but because their profits are; to dress up their complaints 
in First Amendment garb demeans the principles for which the First 
Amendment stands."
*Chief Justice Berger, U.S. Supreme Court*
"Nothing in the Constitution compels us to listen to or view any 
unwanted communication, whatever its merit. We categorically reject the 
argument that a vendor has a right under the Constitution or otherwise 
to send unwanted material into the home of another. If this prohibition 
operates to impede the flow of even valid ideas, the answer is that no 
one has a right to press even 'good' ideas on an unwilling recipient. 
The asserted right of a mailer, we repeat, stops at the outer boundary 
of every person's domain."
===
Section 3.1, 3.2, etc. : Really good!
===
My two original cents on the record type, which it seems is settling on 
TXT :
I concur that LMTP be TXT record based (unless, within the next 5 
months, we can get at least ALL of the major players to commit/promise 
to be on board with a new type.  I think it's unlikely, and TXT is the 
way to go. I think, for example MS wouldn't get on board without a lot 
of public pressure - like when its recent opposition to California 
anti-spam bills (SB 12/186, now law) finally vaporized under an intense 
spotlight - which a technical issue like this is unlikely to create.)
Major players/products include bind (8 & 9, I assume given Vixie's 
involvement), ultradns, Microsoft DNS; zoneedit, dyndns; cPanel, the top 
5 DNS providing domain registrars and other major players I've missed.   
Assuming we stick with TXT, we STILL NEED to get the major players who 
DON'T EVEN support TXT records to get on board with doing so, and there 
are several!   Until we do, the claim in 5.1.1 : "LMAP currently 
requires no changes to existing DNS implementations." in a sense isn't 
quite true (perhaps the implementations that don't support TXT records 
aren't therefore actually DNS implementations!)
===
5.1.6: Only roaming users <add this: who avoid using any of the methods 
of 3.2.x> are indistinguishable from spammers
===
4.1.13:
s/existing implementation/existing implementations/
===
I hope these suggestions are appreciated.
-- 
Matthew

Admin note:  I initially mailed this post on the 11th, from a disposable 
address and it just vanished.  Glitch?  IMO, it would be nice if the 
mailing list didn't bitbucket submissions from non-subscribers.

Apropos first steps /how to get deployment to take place/change 
management:  Here's my vision for how it'll happen.  If the current 
versions of qmail, sendmail, and postfix supported LMAP by default, LMAP 
on the Internet would be inevitably on the way to success.  Exchange or 
Notes would likely follow, and another inevitable security bug 
announcement in a few of them will cause the vast majority to upgrade.  
Result: the Internet is LMAP ready for nearly any domain that wishes to 
do so to roll out and have it be highly effective.  At that point, it is 
inevitable because it will sell itself.  Anyone who gets joe-jobbed will 
find out about LMAP if they look into what to do about it, and scream 
loudly at admins until it protects them.

---

From: "Viktor S. Grishchenko" <[email-masked]>
Date: Sun, 16 Nov 2003 14:41:22 +0500

Gradual deployment issues.

1.	Benefits of early adopters

(Definition: 'non-LMAP' or 'non-conformant' party is a DNS domain and 
associated persons, software and hardware, deploying no LMAP records, i.e. 
absolute majority of today)

1.1.	Non-rejecting

	Server what don't reject to communicate with non-LMAP parties is protected 
against simple kinds of domain forgery (while speaking about LMAP-conformant 
domains) and existing mail worms (mostly). Spam which declares itself to be 
from some existing LMAP-conformant domain is also rejected. (It is obviously 
a minority of all spam, while speaking about early adoption.)

1.2. Rejecting

	Servers rejecting to communicate with non-LMAP parties are protected against  
virtually any mail having forged sender domain. A drawback is communication 
with non-conformant domains made forbidden by default. (And it is a majority 
of domains during early adoption phase.)

2. 'Day M'

	Ideally, LMAP implicitly assumes that because of wide advertisement almost 
all mail servers will deploy LMAP on some day. So, at the next day any non- 
LMAP-conformant mail may be rejected. Practically this is impossible and M 
days will significantly differ at different sites.
	Lets explore consequences of site A closing doors for non-conformant mail:
	- sender at non-conformant site B sends a mail to site A
	- he receives bounce saying "just conformant mails this day, see RFC"
	- sleepy sysadmin is called
	- sysadmin has to:
		- learn more about LMAP
		- explore any available updates to software (for free?)
			- if yes, apply them (downtime)
			- if no, consider migration possibilities
	If entity A is significantly bigger than B then, most probably, no policy 
will be implemented for B exclusively. So, e-mail communication B->A will be 
forbidden until sysadmin will handle all the things.
	If entity A is big enough then number of non-conformant Bs may make it not to 
implement reject policy. If bigger entities will not implement the policy, 
then it may never be adopted effectively wide.
	Yes, LMAP enforcement by e.g. Hotmail is a guarantee. But it is a bad kind of 
guarantee.

3. Gradual enforcement

	So (in my humble opinion) gradual enforcement policies have to be discussed 
and somehow recommended (or deprecated) by RFC. Following is some variants.

3.1. postmaster notification

	Most trivial measure is notification of postmaster@ of non-LMAP domain about 
deadline approaching.

3.2. random tempfail

	Other possible measure is first-time TEMPFAIL reject with commentary 
notifying sender and postmaster of sender's domain about deadline. Random 
TEMPFAIL is also possible. In most cases, the mail will finally be delivered 
(by nth attempt, n hours later). Probability of reject may depend on 
date/time (reaching 1.0 at M-day noon, for example).

3.3. timeframe tempfail

	More complicated possible strategy is a closing timeframe. I.e. at some 
'happy' seconds mails from non-LMAP domains are accepted, at other seconds 
TEMPFAIL is returned. Percentage of 'happy' seconds gradually decreases until 
M day.  So, non-LMAP senders and admins will be receiving ever growing stream 
of unignorable notifications, while e-mail communication will remain actually 
functioning (at least, some time before M day).
	Even more sophisticated strategies are possible to overcome possible 
spammer's workarounds.

4.	Possible benefits of gradual enforcement

	First, early adopters have not to dive into cold water rejecting mails from 
non-conformant parties.
	Second, warnings and notifications are distributed directly, and not by mass 
media, for example. Thus, no special propagandistic effort is required.
	Third, tempfail mechanics will have greylisting effect. It is basically a 
variation of greylisting having absolute LMAP enforcement as it's limit. So, 
the deployment period may be set long enough (say year), because gradually- 
enforced LMAP will have effect long before M day (be it coordinated 
planet-wide one or some random date for every site). Hypothetical LMAP flaws 
may be found and fixed during long deployment phase. (Using M-day approach, 
supposing a flaw is found at M+1 day, this may require one more media 
campaign.)

Any comments?

--

	Viktor S. Grishchenko
	just a postmaster

---

From: "Dave Atherton" <[email-masked]>
Date: Sun, 16 Nov 2003 17:54:04 -0800

----- Original Message ----- 
From: "Viktor S. Grishchenko" <[email-masked]>
> functioning (at least, some time before M day).

Should we say "LMAP-conformant" or "LMAP-compliant"?  I have usually heard
the term "compliant" in other matters but perhaps that was for some
particular point of meaning?

In reading the original posting, the term "conformant" (or "non-") described
only the originator.  It is certainly possible for a domain to be conformant
or not as an originator while simultaineously being conformant or not as a
recipient.  Should we use a term other than "conformant" to describe a
recipient such as "LMAP-using" or "LMAP-implementing"?  A special case might
be "LMAP-enforcing".

I like your ideas for gradual enforcement.  In effect, recipients who
implement LMAP (whatever we call them) would automatically encourage
non-conformant originators to become conformant...at least as originators.
Use of TEMPFAIL for this purpose could be based on a constant percentage
probability or a gradually increasing probability between a start date and a
target date.  The probability and/or dates could be adjustable by the admin
but, perhaps, the default value for the target date could be the same for
the entire planet (perhaps, 1-year after RFC publication?).

A concern is that some messages will go undelivered prior to "M Day".  At a
very low probability of LMAP-related TEMPFAIL, the next attempt will usually
get the message through.  If I understand correctly, however, given enough
messages, some messages will eventually fail to be transferred because the
retries are also unlucky enough to get TEMPFAILs and the originating users
will get Non-Delivery Notifications.  How well might such a plan be received
by admins and ISP owners?

-Dave

---

From: Philip Miller <[email-masked]>
Date: Sun, 16 Nov 2003 23:08:27 -0500

Dave Atherton wrote:
> In reading the original posting, the term "conformant" (or "non-")
> described only the originator. It is certainly possible for a domain to
> be conformant or not as an originator while simultaineously being
> conformant or not as a recipient. Should we use a term other than
> "conformant" to describe a recipient such as "LMAP-using" or
> "LMAP-implementing"? A special case might be "LMAP-enforcing".

For the sake of consistent usage, let's define the following terms:
1. LMAP-compliant domain: a domain that authorizes outgoing MTAs as 
specified by the forthcoming LMAP RFC.
2. LMAP-compliant MTA: an MTA that sends mail as the domain that authorizes 
it. NB - this refers to the individual servers, not the software they run. 
(Note 1, below)
3. LMAP-enforcing MTA: a recipient MTA which looks up the LMAP data for the 
sender, and acts as follows:
a) If LMAP data is not available, acts according to local policy. Initially, 
the default would be to accept it as it is now.
b) If LMAP data is available and the sending MTA is approved, it's accepted, 
possibly with the insertion of an additional header (should be standardized) 
indicating that it was checked. Note that the message could still be 
rejected on other grounds, despite presenting proper LMAP data.
c) If LMAP data is available and the sending MTA is NOT approved, it must 
reject any messages sent with a PERMFAIL. This is the primary case LMAP is 
targetting, and we should require its implementation from the beginning.

Note 1: Software running on MTAs which only originate mail and don't receive 
it would not need to know anything about LMAP.

> by admins and ISP owners?

I think this is exactly the point. At first, most admins would see their 
queues backing up with TEMPFAILs. If we've gotten enough publicity for this 
deployment plan, they'll make the connection "no LMAP -> random TEMPFAILs". 
So most admins will be pretty quick to implement LMAP. For the few that 
aren't/don't, complaints from their users that mail isn't getting through 
should enact a pretty swift change.

--
Philip Miller

---

From: "Viktor S. Grishchenko" <[email-masked]>
Date: Mon, 24 Nov 2003 12:28:48 +0500

> Dave Atherton wrote:
> > Use of TEMPFAIL for this purpose could be based on a
> > constant percentage probability or a gradually increasing probability
> > between a start date and a target date.

In fact, behavior have to be a bit more complicated, not to provoke spammers 
to do countless retransmit attempts. I.e. accept or reject decision has to 
last for some time period (shorter than 1 hour but longer than 1 minute).
At the same time fixed probability p is a good statistical simplification, so 
I will use it.

> > A concern is that some messages will go undelivered prior to "M Day".  At
> > a very low probability of LMAP-related TEMPFAIL, the next attempt will
> > usually get the message through.  If I understand correctly, however,
> > given enough messages, some messages will eventually fail to be
> > transferred because the retries are also unlucky enough to get TEMPFAILs
> > and the originating users will get Non-Delivery Notifications.  How well
> > might such a plan be received by admins and ISP owners?

It is always better to consider it as an alternative to absolute enforcement.
Nevertheless, the issue have to be cleared out.
First, final delivery may be _guaranteed_ by history-aware algorithm only. It 
may be MTA-level code or some temporary plugin having own data storage. If a 
site has greylisting already deployed, there are no additional costs here.
Second, if history-aware approach is not acceptable on some reasons (storage, 
CPU, complexity or other costs) historyless one is possible.
Due to RFC 2821, the sending MTA is expected to attempt retransmit every two 
or three hours until the message is 4-5 days old. Taking 2*24 hours to be the 
worst acceptable delay, it is 24/3*2 = 16 attempts. If p_rej is a probability 
of TEMPFAIL reject due to sender's non-compliance, then power(p_rej,16) is an 
approximate probability of an unacceptable delay. p_rej may be also 
considered as an approximate spam reject ratio while considering 
non-LMAP-compliant spam messages.

p_rej		power(p_rej,16)
0.3			4.3e-09
0.5			1.5e-05
0.75			0.01 (~1%)
0.8			0.028 (~3%)
0.9			~19%
0.95			~44%
0.99			~85%

If worst acceptable delay is 4 days, every value in the right column have to 
be squared.

I.e. some significant enforcement still may be achieved by cheap historyless 
methods while keeping percentage of nondelivered legitimate messages low.

Assuming that retransmit "usually happen" exactly n hours after previous 
attempt, the historyless approach may be significantly improved. But it is 
not an axiom and may not be truth at all.

Philip Miller wrote:
> a) If LMAP data is not available, acts according to local policy.
> Initially, the default would be to accept it as it is now.
> b) If LMAP data is available and the sending MTA is approved, it's
> accepted, possibly with the insertion of an additional header (should be
> standardized) indicating that it was checked. Note that the message could
> still be rejected on other grounds, despite presenting proper LMAP data.

Good.

> should enact a pretty swift change.

Yes.
So, the requirements:
1. Before deploying any enforcement a site may use autonotification of 
administrators or/and senders which use non-LMAP-compliant MTAs. It is 
undesirable, especially for larger sites, to send notification against every 
message received from non-compliant MTA - at least, during early phase of 
world-wide LMAP deployment. Notification must have null ("<>") return address 
and must be directed to sender address taken from the envelope.
(Note: volcanic bombardment of adresses, being forged by spammers, must be 
avoided. Of course, it is generally unavoidable.)

2. Before turning strict LMAP enforcement on, site may implement some kind of 
gradual enforcement using transient message rejection (SMTP 4?? reply code). 
Probability of rejection has to grow slowly, starting from small values. The 
bigger the site the smaller starting value has to be and the slower it has to 
grow. Recommended date for strict LMAP enforcement is one year after RFC 
publication date (as a proposed standard?).

--

	Viktor S. Grishchenko