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