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
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg