ietf-smtp
[Top] [All Lists]

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

2014-03-05 17:49:59
On Wed, Mar 5, 2014 at 3:02 PM, Steve Atkins <steve(_at_)blighty(_dot_)com> 
wrote:

On Mar 5, 2014, at 10:20 AM, Murray S. Kucherawy 
<superuser(_at_)gmail(_dot_)com> wrote:

How come this never got adoption?  It comes up from time to time in "We 
really should do this" sorts of discussions, but it doesn't seem like anyone 
ever took the plunge and it just expired.  Is it just that nobody does it 
because nobody else does it?

http://tools.ietf.org/html/draft-hall-prdr-00

What sort of smtp clients /senders of email are the target market for this?

Most of the obvious users I can think of (send lots of similar email on an 
ongoing fashion, care deeply enough about bounce management to really want to 
track which recipients are bouncing, technically competent enough to both 
implement and make good use of PRDR) don’t tend to batch and blast, rather 
they tend to send unique emails to each recipient.

(I’m sure it’s been discussed before, but I don’t recall what the answer was 
and there’s no mention of it in the draft.)

For us, the most obvious use case is for enterprise routing rules.
For example, you can imagine that a school might implement an
objectionable content filter for students, but not for faculty.  In
that case, a message containing such content that was in the same smtp
transaction could now be allowed to the teacher and rejected by the
student.  Today, we have to accept for both and then generate a
bounce.

As for ESPs, yes, if you're already doing single recipients per
transaction, this isn't especially useful.

As for spammers, not all spammers run their own software.  Even those
that do tend to just throw things together using whatever parts they
find, so they could grab some library which does this without thinking
too much about it.  Others abuse existing infrastructure by hijacking
accounts and such, so they'll get whatever impl the hijacked infra
already has.  I could even imagine that spammers would find this
useful if it increased their immediate knowledge of block rates given
they almost certainly are using forged senders or aren't checking the
bounces.

Anyways, the obvious use case is per-user filters (spam or rule
based), neither of which are really that strong, I'd think.

Brandon

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