[Top] [All Lists]

Re: per user post-data rejects, Processing after the end of DATA

2010-08-12 17:53:30

In article <01NQK8EKPYCU000CVY(_at_)mauve(_dot_)mrochek(_dot_)com> you write:


if rejecting after CRLF.CRLF is better than bouncing, what about
discussing draft-hall-prdr-00 and doing it more normative? ...

I never understood why the interest level in this was so low.

Probably because the problem it solves is not one that many people
have.  The scenario appears to be one where you have per-user content
filters AND you filter during the SMTP session AND you reject mail
that fails filtering AND the message is marginal enough that it passes
one user's filter and fails another's.

No, that's not even close to the typical use-case. The typical use-case is much
simpler: Per-user Sieves or similar user-specified filters that support
reject/ereject or its equivalent. The problem occurs when one recipient rejects
and the another does not, or when both reject but with different reasons.
(Ereject deals with the latter by allowing a generic "everybody hates you,
kindly go eat some worms" response, but it would be nice to retain the original
reason strings.)

One of the typical ways this plays out is the system spam filter, for whatever
reason, misses some spam. (Hardly an uncommon occurance.) One user then takes
it upon themselves to add a rule to reject the spam they received. But other
users don't do this.

I can also assure you that the number of Sieve users out there is NOT small, so
this is a real issue. The usual way it's dealt with, unfortunately, is to
disallow use of reject/ereject, which solves the problem, at the cost of
further compromising email handling integrity since now users will just use

I suspect the real reason these proposals haven't gotten sufficient traction is
because people don't understand the problem they actually solve.

It seems much more likely in that scenario that rather than rejecting,
a system would drop it in the second recipient's spam folder,

What spam folder? You're making a lot of assumptions about what features
are available in many setups.

or if
they're reasonably confident in their filters, just not deliver it to
the second recipient.

Whould would mean, in some cases, ignoring specific whiteisting directives that
you're contracurally obliged to support. THat's a good way to get yourself
sued. (I Happen to know this last has been a real, not theoretical, issue.)


<Prev in Thread] Current Thread [Next in Thread>