Re: [Asrg] 6. Proposals - DNS-Based - LMAP - Deployment

[Philip Miller <millenix@zemos.net>]

Dave Atherton wrote:
> 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".
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.


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


_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg