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.
|
|