ietf-mta-filters
[Top] [All Lists]

Re: Change to "reject" action: compatible with fileinto/redirect?

2005-04-29 15:25:24


On 4/28/2005 2:05 PM, ned(_dot_)freed(_at_)mrochek(_dot_)com sent forth 
electrons to convey:

>
>> Matthew has asked this question before and I've heard no opinions.
>
Clarification: It's been the I-D of "refuse" for a while:

4.2  "refuse" compatibility with other actions
   "Refuse" cancels the implicit keep, and is incompatible with
   "reject" and "discard". "Refuse" is also incompatible with
   "vacation" extension [VACATION]. (It should be compatible and
   incompatible with the same actions as "reject", but [SIEVE] states
   "Implementations SHOULD prohibit reject when used with other
   actions." However we feel that "refuse" should be permitted when
   used with other actions such as "fileinto" and "redirect".  This
   could be useful for analyzing, tracking or reporting spam.  Also,
   users can use tricks (such as multiple redirects back to their own
   email addresses) to get around such a prohibition anyway.)

>> I just want to hear explicit confirmations/objections to the idea of
>> allowing "reject" to be compatible with "fileinto" and "redirect".
>
>
> I think sending a "this message was rejected" message but then
> keeping/forwarding the message is disingenuous at best. It also opens
> the door
> to certain abuses, including but not limited to various sorts of loops.

I don't see how allowing "reject" to be compatible with "fileinto" and
"redirect" opens a new venue for a loop that having "reject"  be
INcompatible with "fileinto" and "redirect" keeps closed.

There is increased potential for loops any time you unconditionally  generate a
message in response to another message. This is then magnified if the original
message heads off to other places, which is exactly what fileinto and redirect
do.

If "redirect"
can be used to create a loop, it can do so irrespective of whether
"reject" happens as well. Please explain.

Of course redirect has the potential to create loops - I see it happen all the
time. And so does reject. Allowing both increases the risk even more, and to
what gain? So you can easily lie about having thrown out a message when you
didn't actually do it? Sorry, this doesn't fly with me.

I think the refuse/reject, forward and log abuse setup Nigel mentioned
is a valuable use case that we should support,

I completely disagree. I don't think it is a valuable use case at all; the
cases where reject should be used are in fact pretty rare and get rarer all the
time as the potential for harm due to joe-jobs and blowback spam increase. I
really don't want to do anything that has the potential to make reject more
popular than it already is.

On a side note, I understand that due to widespread abuse of reject our
customers demanded our GUI be changed so that by default it does not offer
users the ability to specify a reject action.

Refuse is another matter, of course.

                                Ned