[Top] [All Lists]

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

2014-03-14 12:43:07

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

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

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.

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

(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.

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).  

I do so for viruses, thanks to the extremely low
false-positive rate.
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.

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

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

(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 blcwback, may actually make discarding a better option than
selective rejection.  

(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

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


ietf-smtp mailing list