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. If "redirect"
can be used to create a loop, it can do so irrespective of whether
"reject" happens as well. Please explain.
This isn't to say such messages can't be sent through other means or
loops
won't happen for other reasons - of course they can or will - but we
should not
make it easy.
It's already not difficult. Example:
(Note: in these examples, the user's mailbox is user(_at_)example(_dot_)com, and it
supports +subaddressing.)
...
} elsif envelope :is :localpart "To" "user+spamrefuse" {
refuse "because";
} elsif envelope :is :localpart "To" "user+spamreject" {
reject "because";
} elsif envelope :is :localpart "To" "user+spamlog" {
fileinto "INBOX.spamarchive";
} elsif envelope :is :localpart "To" "user+spamredir" {
redirect "<SpamCopAcctID>@spamcop.net";
} elsif envelope :is :localpart "To" "harvestedaddress" {
redirect "uce(_at_)ftc(_dot_)gov";
redirect "user+spamredir(_at_)example(_dot_)com";
redirect "user+spamlog(_at_)example(_dot_)com";
redirect "user+spamrefuse(_at_)example(_dot_)com";
redirect "user+spamreject(_at_)example(_dot_)com";
making this easier would just make it *less* likely users will write
something that creates a mail loop, as they redirect things to
themselves in order to get around this roadblock e.g.:
...
} if header :is :localpart "To" ["harvestedaddress"] { #THIS IS BROKEN
CODE; DO NOT USE; MAIL LOOP
redirect "uce(_at_)ftc(_dot_)gov";
redirect "user+spamlog(_at_)example(_dot_)com";
People who want to send some sort of automatic response to a message
while
continuing to process it should use vacation, which implements the
right set of
checks to prevent various bad things from happening.
I think the refuse/reject, forward and log abuse setup Nigel mentioned
is a valuable use case that we should support, but NOT if the cost is
opening the door for significant new abuses.
Thanks for the responses, folks. It's important that we not do that;
thanks for re-raising the issue, Alexey.