ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] Per-Recipient Data Responses

2014-03-14 14:49:09
Hi John,

On Fri 14/Mar/2014 18:42:43 +0100 John C Klensin wrote:

Since I'm still holding the pen on any possible replacement for
RFC 5321 (and have been waiting for over six months for a
response from the ADs about how to handle that), a few
observations from that perspective...


--On Friday, March 14, 2014 12:56 +0100 Alessandro Vesely
<vesely(_at_)tana(_dot_)it> wrote:

I was talking about having an overarching policy of never
discarding a message. Aside from a few small setups, I don't
think I've ever seen anyone implement such a policy in the
past decade or so. Like it or not, a lot of mail believed to
be spam is silently  dropped more often than not, and mail
believed to to be dangerous in someway is almost always
discarded.

Indeed, RFC 5321 says:

   As discussed in Section 7.8 and Section 7.9 below, dropping
mail    without notification of the sender is permitted in
practice.

Yes.  And that particular approach to weasel-wording --
requiring either delivery or rejection (with notices where
rejection cannot be provided at SMTP time) and then explicitly
providing an escape -- reflects the strong consensus of the
group at the time.

I don't think that particular snippet needs to be revised.  It never
went on the YAM database.

Temporarily moving the discussion up several levels, there are
only three possible models for email (or, for that matter,
postal mail) acceptance and delivery:

(i) Delivery is reliable and can be assumed.  Undelivered
messages will be returned or the sender appropriately notified.

(ii) Delivery is unreliable and should not be assumed absent
explicit acknowledgment by the addressee.  For this model to
work well and not segue into the third, the recipient must not
be able to receive and examine the content of a message (and
possibly not even the envelope) without generating a reliable
acknowledgment. 

(iii) Delivery is unpredictable: When one sends a message, one
has no idea whether it will be delivered or not, whether it has
been received or not, etc.  Any acknowledgments or rejection
notices are purely optional to the delivery system, the
recipient, or various intermediaries.

The last model is the only possibly real one, given that perfection is
so difficult to attain, especially on large, heterogeneous systems.

Internet mail was designed around the first assumption.  We are,
for better or worse, sliding toward the third.  It is impossible
(at least for me) to quantify the degree of that effect, but the
more unpredictable things get, the more it drives people toward
use of IM-like technologies in preference to email: those
technologies permit better sender and recipient authentication,
have the advantage of direct (and easily-encrypted) links
without worrying about interference by intermediaries, may be
more immediate than email if the latter is to be intercepted and
scanned/ analyzed in transit, and provide immediate information
about delivery (or non-delivery).

Agreed.  Of course, neither I can quantify how much we're into model
(iii), but --thanks to Jon Postel, you, and myriad others-- it seems
reliable enough to enjoy continued use.

As such, I'm not especially worried about how PDRD interacts
with a never-discard policy. I'm much more interested in how
it lets us replace discard with reject.

Yes, but you can only do so if the client supports it.

The client and, to at least some degree, the delivery server or
other systems acting as its surrogate.

Unlike LMTP, an organization deploying PRDR cannot control how clients
connect to an MX.  The point raised by Paul[1] is that it is difficult
to improve per-recipient solutions without a good fall-back method.

[1] http://www.ietf.org/mail-archive/web/ietf-smtp/current/msg07676.html

 That
may give rise to the long-winded road to adoption that was
discussed last week:  Servers avoid discarding when that
creates more problems than it solves.  Rejecting works better,
so it allows more room for anti-spam solutions. 

I'm not persuaded that is true.  I'm not a spammer (and
presumably neither are you) so it may be hard for either of us
to understand how  they think but I'd guess a few things are
obvious:

(i) Their goal is to get as many messages through to the
recipients who will act as they desire on those messages as
possible.  

(ii) Given that the costs of sending an extra message (or 10)
are very low and those of attaching extra addresses to a given
message are even lower, providing the actual spam-senders with
information about which addresses are valid and which are not
doesn't have much benefit for spam-fighting.  It may, however,
be of advantage to those who compile lists of valid,
message-accepting, addresses.  The latter, as well as avoidance
of blowback, may actually make discarding a better option than
selective rejection.  

That's true.  However, when false positives are too frequent the
resulting behavior falls too deeply into model (iii).  In those cases,
rejection likely gets back to the author.  S/he may or may not want to
retry, but having a chance to understand what went on will not blame
the mail system as a whole for the malfunction.  IOW, false positives
are more endurable if they are notified.  Thus, those who configure
anti-spam filters can get a little more leeway by rejecting rather
than dropping.

(iii) As others have pointed out, making rules that one expects
spammers (and anyone else operating at or over the boundaries of
good taste and good practices) to follow is typically a fool's
errand.

Yes.

Per-recipient
settings individually allow more room too, but thus far that
implies discarding.  So it seems one can improve along one of
two orthogonal directions only.  Is that the reason why many
spammers send to multiple recipients?

See above.

Per-recipient solutions can also be run on the MUA, if dropping is the
only alternative.  That makes them completely orthogonal to boundary
filters.  In any case, since that's in users hands, they are
responsible to find what suits them better.

I'm extremely dubious about standardizing use of specific
types of data analytics in the AS/AV space.

We don't need to "standardize" them, so long as it's clear
what we're talking about.  The case of a server facing a large
number of RCPT TO commands is also in Section 7.8 of RFC 5321.
Since that is the meat of PRDR, it ought to elaborate on that
topic a little bit more, IMHO.

My current hypothesis is "I don't think so" and, as implied
above, nothing is likely to happen any time soon anyway, but
send text and see if you can get consensus for it.

The OP[2] apparently suggested to unexpire that 7-year old draft.  Its
introduction makes it clear that PRDR is meant to improve anti-spam
boundary filtering.  My point is that we'd need more insight into the
relationship between a message's spamminess and the presence of
multiple recipients, if there is any.  Such insight may suggest a good
fall-back method, or it may suggest to forget PRDR tout-court.

[2] http://www.ietf.org/mail-archive/web/ietf-smtp/current/msg07655.html

 Better yet,
follow the advice that has been given (not just by me) to many
others who have asked for substantive changes to 5321: create an
I-D that updates it and see if you can get enough traction to
get it approved as a Proposed Standard.  If you can do so and
then demonstrate the interest and interoperability needed to
advance it, the odds of incorporation into some future 5321bis
are pretty high.  For procedural reasons even if there were no
substantive ones, the odds of actual modifications in 5321bis
without such standalone documents are vanishingly small: the
only exceptions would be for clarifying text, obvious
corrections, or editorial changes that have no substantive
impact on the general understanding of the specification.

I don't think PRDR requires any changes in RFC 5321.  But perhaps
rfc5321bis will happen before prdr-01...

Ale

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp