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

Spam blowback from Sieve implementations.

2006-11-27 16:21:02

At the last IETF meeting, there was rough consensus both that sending spam in the form of MDNs in response to spam was bad (or as Barry put it "I think /everyone/ agreed that protocol-level rejecting is best in cases that use only ASCII text."), and yet also that there was a need to be able to enable some customers to continue to do so to preserve not just backward compatibility and reason text, but behavior that was fully identical to the old behavior. Alexey and I are having a hard time reconciling these two in terms of what the draft should do. It would be a phenomenal waste of time to remove "reject" from the base spec only to add it back exactly as it was defined in the base spec. Surely that's not the reason we did it, right? Of course not, so the action of "reject" needs to be tweakable to be conservative about preserving reason text. Solution: At the one extreme, for users that require behavior identical to the old refuse, we want to require a configuration option that if enabled, provides this via "reject", even though it will produce lots of spam if used widely on the Internet. Next, there's "reject" with this setting disabled, which will preserve even non-ASCII reason text (except when the message has been identified as probable spam), but otherwise always do in-protocol reject where it's possible. Finally, there's "ereject", which never sends MDNs. Among other things, exim calls for this option, as it never sends MDNs.

The configuration option would be something roughly equivalent in the given implementation to a configuration file entry like this:

#Preserve old reject behaviour exactly, at the cost of sending Joe-job spam whenever spam is rejected. sieve_reject_old_style = yes (or true or checked, or no/false/unchecked, consistent with other implementation option syntax)...

Any objections?

<soapbox>
I really think it's irresponsible for us to be attempting to perpetuate behaviour that we know is wrong and, just because it's hard to convince some customers that the change (which no one has argued even breaks backwards compatibility.) It smacks of trying to perpetuate the spam problem in order to keep ourselves busy, and I don't want to even APPEAR to be doing that. But I've compromised in order to reach a consensus that we can all live with.
</soapbox>

In other words, the key question as I see it is:

Do we want to have the spec allow implementers to not bother to implement the ability to do proper smtp-time refusals, even though all implementers at the meeting indicated that it was possible for the implementations to be changed so that they could do so, and not doing so produces and will continue to produce immense economic harm caused by spam blowback? Does anyone think that this is a good idea?

Also, do we want MUAs to be able to claim to support "ereject" or "refuse" even though they don't actually do any of the things that these new actions were created to enable? I think not; any disagreement? (I feel that if an implementation claims to support these actions, it needs to actually do what they were created to do. Alexey feels that this isn't important, rather any require should be able to work anywhere. This would seem to make the whole require feature rather unuseful.)


P.S.  Chris Newman:  If you could confirm/clarify comment, re.
http://staringatemptypages.blogspot.com/2006/11/ietf-67-san-diego.html, that would aid communication.