IETF standards and spam blowback from Sieve implementations

[elvey]

This is a request for feedback from experts/regulars to help reduce spam blowback from Sieve-based systems.

The IETF's SIEVE Working Group is modifying/updating the way scripts written in Sieve (the mail filtering language) can handle messages to be refused/bounced/sent to where they purportedly came from. The current method, as defined in the Sieve standard (RFC 3028) is not good, IMO. It results in tons of spam blowback/backscatter when the sender is forged, including when Sieve scripts are part of a Challenge/Response system, or out-of-office system, or spam-filtering system. I've gone through a great deal of effort to remedy this; I've written several versions of an Internet-Draft to fix the problem to a great extent; see refuse-reject, which explains the problem in more detail to those not familiar with the issue.

At the last Sieve meeting a few days ago (I attended remotely), it was determined that there was a rough consensus among implementers who were present (at least there was support from Alexey, Chris, and Philip; the others abstained or did not support it) to keep the current behaviour as the default. It was stated that Sieve is not used as part of spam-filtering systems, and that the current behaviour was not causing problems. I'm here to solicit feedback as to whether that's the case. I've said that I regularly receive blowback from such systems (along with tons of blowback from other kinds of systems), but I was the lone voice. In my effort to fix Sieve the way I think it needs to be to best address the problem, I could use some support for my argument.

If you have expertise and can speak credibly and/or provide statistics on receiving blowback from such systems, your feedback would be most appreciated; the best forum for such feedback would be the Working Groups mailing list (you must subscribe to post). If you just need to vent or yell semi-incoherently, please don't do so on the list.

How to identify such blowback: for example, if you get lots of blowback that says, " Your message was automatically rejected by Sieve, a mail

filtering language.", or is "From: Mail Sieve Subsystem <postmaster[at]somedomain.dom>", it's coming from a Sieve-based system, and that's what I want to hear about. (Though if it's not there, that does NOT mean its wasn't from such a system.)

Questions? Post here?

[Wazoo]

I'm not sure I understand your request, actually. The "blowback" issue is docmented pretty heavily within this forum, especially by all the folks that (unfortunately, usually using their own 'crafted' terminology) come in bitching about their InBoxes being flooded with rejection notices about e-mail they didn't send ... that forged From: or Reply-To: issue ... which is what I thought your request started out asking about.

The issue continues with some IP addresses making their way onto the SpamCoDNSBL based on the fact that these mis-sent bounces/rejection notices/whatever are now considered to be a reportable item ... so there are also the multiple discussions / arguments about the current status of various RFCs, netiquette, software configuration/capabilities, etc.

However, your last paragragh stating that you only really want to hear about Sieve-system rejection notices changes the whole answer set ...????

[Miss Betsy]

At the last Sieve meeting a few days ago (I attended remotely), it was determined that there was a rough consensus among implementers who were present (at least there was support from Alexey, Chris, and Philip; the others abstained or did not support it) to keep the current behaviour as the default. It was stated that Sieve is not used as part of spam-filtering systems, and that the current behaviour was not causing problems.

They must have their heads in the sand. If I understand correctly that this Sieve is sending emails to forged return paths in spam. Anyone using Sieve for whatever it is used for will probably end up on the spamcop blocklist. Backscatter is bad. As well as causing problems for some people by inudating them with NDRs for email they didn't send, it really gets some people upset to see all those bounces with their domain name as the sender in a spam.

You can get some more technical and more colorful quotes from previous posts on the subject (including the FAQ).

Miss Betsy

[elvey]

Wazoo: I indicated in my first sentence, I'm interested in spam blowback from Sieve-based systems. The top line in the table of sieve implementations is a list indicating that Sieve is widely used. (I understand there's lots of blowback from other systems (and that that's bad too) but that's NOT what I'm trying to address here, it's out of scope.

However, I bet there's an RFC or BCP that discourages blowback that I could point to for additional support; anyone recall one, offhand?)

They must have their heads in the sand.

To continue the analogy, they don't want to stick their necks out; there was no objection to this:

http://www.imc.org/ietf-mta-filters/mail-a...e/msg03235.html

The only argument that's been put forth (by Chris, IIRC) in favor of keeping the behaviour the way it is was not that there was any direct reason not to make the change, but only that it would take significant effort to explain to Japanese clients why it was a good idea, because they always asked such questions and insisted on answers. (Really! recording, starting (Discussion from 2:46:50; mtg from 2:29:19) The unstated argument against the change is laziness. (I suppose we could also be dealing with wolves (i.e. folks wishing to perpetuate the spam problem) in sheep's clothing, but I doubt that's the issue.) The architecture of some (most?) implementations will require significant rework in order to comply with the Internet-Draft I have written. This is because they will have to perform Sieve processing before responding to the end-of-data command during the SMTP transaction. This will require rearchitecting some implementations, such as the ones where a gateway speaks SMTP and LMTP, and the sieve engine accepts messages over LMTP. However, during the same talk, it was asked if the implementers present (about 7 of them) would be able to implement the new standard, and all of them said they would. If I can say that Sieve engines are currently sending about x spam blowback messages per time period y, requiring end-users worldwide JHD z times a day, at a total time cost of d, and d >> the time cost to change the implementations, I have a good argument. If I can't get the numbers for that argument, I can always make the assumption that Sieve becomes so popular that the vast majority are using it, and make calculations based on that assumption. A protocol must be designed so that it works well if everyone adopts it, after all. In fact, I now realize that this is a better way to argue the point. I'll go make that argument shortly... I suppose I could mention that on November 8th alone, I received at 68 NDRs, just to my personal account, and that's excluding the ones blocked by greylisting or the blacklists used to block mail.

If I understand correctly that this Sieve is sending emails to forged return paths in spam.

Right. The current spec, which I'm trying to change, actually requires that SMTP error codes (e.g. 550) NOT be used, rather that MDNs (see RFC 2298) MUST be sent.

...Backscatter is bad....

You can get some more technical and more colorful quotes from previous posts on the subject (including the FAQ).

Right, I'm looking for some quantification as to how bad it is.

Perhaps Ellen could tell us how much of her time she spends dealing with backscatter senders and receivers, and/or how much backscatter gets reported to spamcop, but since many folks think backscatter shouldn't be reported to spamcop, I think that these numbers would underestimate the problem, so I haven't asked her directly.

[Wazoo]

Wazoo: I indicated in my first sentence, I'm interested in spam blowback from Sieve-based systems.

Wow! You got me there. No idea how I managed to skip/miss/ignore(?) that first line ... I know I read everything else a couple of times ...

[jrssystemsnet]

FWIW:

6 detected Sieve backscatters out of approximately 108,000 quarantined spams currently. Please note, however, that I AM subscribed to several RBLs and in addition I have bounce flood protection mechanisms that automatically kick in to forcefully deny any message that appears to be a bounce when a flood is in effect, so that number is very definitely going to be VERY artificially low.

If Sieve servers are producing backscatter from spam runs, they are guaranteed going to be getting RBL'ed at SORBS, SCBL, and several other lists as well as likely winding up trashed by bounce flood mechanisms like mine. Also, many admins implement automatic blackholing of any IP that sends more than [x] detected spams during [y] period of time for [z] hours, so Sieve servers producing backscatter will get DIRECTLY blackholed a lot of places if they produce backscatter - particularly backscatter that reproduces original message content - as well.

FINALLY notice that a lot of admins - such as myself - are trending more and more towards doing automatic deletion of incoming bounce messages even when NOT under load, as they do vastly more damage than good. Producing backscatter is, frankly, inexcusable.

[elvey]

Thanks for the stats.

Producing backscatter is, frankly, inexcusable.

Right, except the current Sieve RFC is an excuse, as it just about mandates it; I'm trying to get rid of that excuse...