Subject: [Asrg] This is a request for feedback from experts/regulars to help reduce spam backscatter from Sieve implementations

From: Matthew Elvey <[email-masked]>
Date: Mon, 27 Nov 2006 22:32:32 -0800

Please read the whole email before responding.

This is a request for a particular kind of feedback from 
experts/regulars on the issue of spam blowback (i.e. 
Joe-jobs/backscatter due to forged MAIL FROM's) from Sieve-based 
systems. There's some relevant work going on on [email-masked].

The IETF's SIEVE Working Group 
<http://www3.ietf.org/html.charters/sieve-charter.html> 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 
<http://www.ietf.org/internet-drafts/draft-ietf-sieve-refuse-reject-04.txt>, 
which explains the problem and my solution in more detail to those not 
familiar with the issue.

At the last Sieve meeting a few weeks 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'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.

NOTE: If you have expertise and can speak credibly and eloquently 
regarding the impact of backscatter and/or provide statistics on 
receiving backscatter from such systems, your feedback would be most 
appreciated; the best forum for such feedback would be the Working 
Group's mailing list <http://www.imc.org/ietf-mta-filters/> (you must 
subscribe to post). If you just want to vent or yell semi-incoherently, 
please don't.  To date, the only support I've received has been 
off-list, from Spamcop Forum regulars, e.g. Miss Betsy, and Wazoo:
http://forum.spamcop.net/forums/index.php?showtopic=7436

If you'd like to comment on the draft please join the list and post 
THERE.  E.g. the current draft doesn't discuss email authentication and 
how it could be used.

It's not be possible to identify some such backscatter. If you get 
backscatter 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.)

There's also an argument going on about whether to require that 
Sieve-generated MDNs include the header of the refused message,  in 
order to help identify authorized senders for email from a domain.  I 
feel we should require that the full message header of the message being 
returned (at least all those header lines that were on the message when 
it was received) be included in the messages, an MXCOMP issue.  This is 
so that backscatter detection systems have something to work with.  
Others disagree.

Questions? Post here or email me.

My most recent post: 
http://thread.gmane.org/gmane.ietf.mta-filters/3328/focus=3328

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: [email-masked] (Justin Mason)
Date: Tue, 28 Nov 2006 13:57:03 +0000

> does NOT mean its wasn't from such a system.)

Unfortunately, I've just checked the 212 MB of backscatter I've
received since Sunday (seriously!) -- no signs here...

> so that backscatter detection systems have something to work with.  

I strongly agree on this point.

SpamAssassin 3.2.0 will probably include an anti-backscatter ruleset, btw.
I'm viewing it as nearly as big a problem as direct spam, nowadays; the
DDOS effects of spam backscatter nearly took down my mailserver this past
weekend. :(

What about the Sieve drafts restricting reject DSNs/MDNs to senders that
authenticated using SPF/DK/DKIM?  that would fix the problem and may
be more popular.

--j.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 28 Nov 2006 10:26:45 -0800

On Nov 28, 2006, at 5:57 AM, Justin Mason wrote:

> What about the Sieve drafts restricting reject DSNs/MDNs to senders  
> that authenticated using SPF/DK/DKIM?  that would fix the problem  
> and may be more popular.

The associative strategy defined in:
http://tools.ietf.org/wg/dkim/draft-otis-dkim-dosp-02.txt

Can utilize a DKIM signature to assure the MailFrom is valid.  This  
could have some advantages when there is a growing reluctance to send  
DSNs.

-Doug

---

From: Daniel Feenberg <[email-masked]>
Date: Wed, 29 Nov 2006 11:15:57 -0500 (EST)

On Mon, 27 Nov 2006, Matthew Elvey wrote:

> This is a request for a particular kind of feedback from experts/regulars on 
> the issue of spam blowback (i.e. Joe-jobs/backscatter due to forged MAIL 
> FROM's) from Sieve-based systems. There's some relevant work going on on 
> [email-masked].
>
...
> backscatter that says, " Your message was automatically rejected by Sieve, a 
> mail
> <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.)
>
...

I looked through a few hundred thousand messages here and found none of 
that form. Is this perhaps a sign that current users of Sieve are carefull 
not to use it in situations where it might generate a DNS to a forged 
address, and that if a true early reject feature were available, Sieve 
might have much wider applicability and more users?

Daniel Feenberg

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 29 Nov 2006 20:39:39 +0100

Matthew Elvey wrote:

> purportedly came from.

I'm aware of that, e.g. the approved (?) or published (?) part about
vacation is firmly based on RFC 3834.  That's a sine-qua-non, normal
auto-replies go to the Return-Path, and their own Return-Path is of
course empty.  Same idea as for DSNs and MDNs.  Anything else is FUBAR,
Keith expressed it more politely in 3834.

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

You're not supposed to see any forged (= SPF FAIL) Return-Path in a
post-SMTP scenario.  For the NONE/NEUTRAL folks it's up to them to
change that if they don't like the effect.  After an SPF PASS mail
including DSNs, MDNs, SIEVE, C/R, vacation, and what else works as
designed (before they deprecated the reverse path routing in 1123).

> <http://www.ietf.org/internet-drafts/draft-ietf-sieve-refuse-reject-04.txt>,

I shortly looked into that some time ago, it's apparently about
using SIEVE in the DATA-phase of SMTP (= not yet accepted), like
SA 3.x can be used before the mail is accepted.  Or afterwards, but
then it's of course too late to deal with forged Return-Path issues.

> It was stated that Sieve is not used as part of spam-filtering 
> systems

Odd, SIEVE is the theory where SA is a part of the praxis, and SA is
certainly a part of spam-filtering.  Do you have a pointer for this
odd statement ?

> and that the current behaviour was not causing problems.

After you've rejected all SPF FAILs you're free to ignore some of the
blowback issues as far as I'm concerned.  My ISP uses SIEVE for their
spam-tagging and similar activities (on a hop between MX and MDA), 
too late for a reject at their border.  I hope that they don't reject
at all after their border, unless it's a rare hopelell situation...
Shit happened, the MXs received mails faster than the MDA could
handle it, and the SIEVE hop in the middle started to reject, and so
all mails were bounced.  They solved this within a few days.

> To date, the only support I've received has been off-list, from
> Spamcop Forum regulars, e.g. Miss Betsy, and Wazoo:

Most SC NG activists (excl. me) insist on a concept where "reject"
behind the border is _always_ wrong.  IMO that's a delusion, many
late rejects are avoidable, but not all.  If senders don't publish
a FAIL policy receivers can get into ugly situations.

The official SC policy (since early 2005) is that blowback can be
always reported as spam.  And my position was always that this is 
dubious if the senders didn't try to help that the receivers have
a fair chance to get it right, by publishing a no nonsense PASS or
FAIL SPF policy.

As it is all participants can decide that it's not their problem:

- Spam reporters can say they don't need a FAIL policy, it's the
  fault of the receivers
- Receivers can say they don't need to check SPF, and SC's "new"
  policy is anyway bogus (or rather "not covered by RFC 2821")
- In practice they need a separate IP for DSNs, because they'll
  be blacklisted permanently for their blowback
- Senders can use these blacklists, and in practice they won't
  get legit DSNs (or other auto-replies) from such receivers
- SMTP dies, let's all get jabber clients, thread on the IETF
  general list, film@11, what else is new ?

> the current draft doesn't discuss email authentication and how
> it could be used.

Good move, some folks will need some time until they're sure that
nobody's up to invent a better emulation of RFC 821 than v=spf1.
Talking about it where it's unnecessary would only muddy the waters.

It's okay to say that all auto-replies MUST go to the originator.
Just skip the part "as indicated by the Return-Path" in the 2821 PS,
because that's obviously nonsense in almost all scenarios behind the
border of the receiver (excl. SPF PASS, then it's okay).

> http://thread.gmane.org/gmane.ietf.mta-filters/3328/focus=3328

Of course MDNs are bad, Arnt answered that in this thread.  Or at
least MDNs without SPF PASS are utter dubious, most mail today is
spam with forged Return-Paths.

Frank

---

From: Matthew Elvey <[email-masked]>
Date: Thu, 30 Nov 2006 02:01:11 -0800

On 11/29/06 11:39 AM, Frank Ellermann wrote:
> post-SMTP scenario.  
Perhaps....  This is the case for folks who are under the illusion that 
SPF FAIL is a reliable indicator that the mail is forged, and hence are 
willing to bit-bucket it. It's also the case for folks who think it's 
reliable ENOUGH.
The sender can't control how is mail is forwarded, so legit mail can be 
marked SPF FAIL.  Not to say that SPF is totally useless.  But, I said 
email authentication, not SPF, intentionally.
> For the NONE/NEUTRAL folks it's up to them to
> SA 3.x can be used before the mail is accepted.  
Right.
> certainly a part of spam-filtering.  Do you have a pointer for this
It was said at the meeting, IIRC, which is archived.  I don't have a 
timestamp; sometime after 2:46:50
http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf67/ietf67ch2-mon-pm.mp3
> late rejects are avoidable, but not all.  
The more serious delusion is that reject behind the border is just 
fine.   I'm here trying to enlist help to make that illusion disappear 
among Sieve implementers.
> If senders don't publish
> Of course MDNs are bad, Arnt answered that in this thread.  

Well, that's nice and all, but the folks on the ietf-mta-filters list 
still think it's dandy; they didn't hear his arguments, or yours.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 30 Nov 2006 11:11:14 -0800

On Nov 30, 2006, at 2:01 AM, Matthew Elvey wrote:

> Perhaps....  This is the case for folks who are under the illusion  
> that SPF FAIL is a reliable indicator that the mail is forged, and  
> hence are willing to bit-bucket it. It's also the case for folks  
> who think it's reliable ENOUGH.  The sender can't control how is  
> mail is forwarded, so legit mail can be marked SPF FAIL.  Not to  
> say that SPF is totally useless.  But, I said email authentication,  
> not SPF, intentionally.

Of course, being of the rare opinion that even executing SPF scripts  
should be verboten, this is where an associative scheme with a DKIM  
signature could offer an alternative to confirm a sender's  
relationship with the MailFrom email-address.  DKIM does not suffer  
the path registration issues haunting SPF, where DSNs also being lost  
makes this issue even more problematic.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 30 Nov 2006 23:01:12 +0100

> who think it's reliable ENOUGH.

It's no illusion, it's the definition, and senders know that it can't
work reliably (if at all) if SPF is checked behind the border-MX.  In
that case it results in a "551 user not local" emulation, good enough.

An illusion would be any attempt to do something else than "reject",
any "annotations" or scoring in already invalid constellations could
cause losses of legit mails.    

> The sender can't control how is mail is forwarded

Yes, it's up to the receiver to get this right.  Either using a pure
STD 10 network with working reverse paths, or rewriting the MAIL FROM
in other appropriate ways, as done for mailing lists.  Or white list
the forwarder.  Or accept this odd 551-emulation, like the sender did:

It would be stupid to publish a FAIL policy without accepting this
consequence...

> legit mail can be marked SPF FAIL.

...not if it's recjeted.  With SMTP any "annotation" or "marking" is
the dangerous choice, rejecting is much cleaner.  I thought that your
article here was about this difference.

> But, I said email authentication, not SPF, intentionally.

With an SPF PASS you got the plea to procede as specified, reporting
errors "to the originator as indicated in the reverse path", a later
bounce cannot hit innocent bystanders.  And after a FAIL it will hit
innocent bystanders.  There are no other ways to figure that out.  

After all RFC 1123 5.3.6(a) is an ordinary bug, even if it's the 
most expensive bug in technical standards I've heard of.  And its
latency (more than a decade) is also impressive.

 [SIEVE not used for spam filtering]
> It was said at the meeting, IIRC, which is archived.  I don't have
> a timestamp; sometime after 2:46:50

No sound card on my box, tough.  IMO a statement in that direction
would be weird, unless there was a qualifier like "not solely".

> fine.

Yes, unfortunately the 2821 proposal isn't clear enough about that
for many readers.  Its "originator as indicated by the reverse path"
blurb fails miserably when the default state of this "indicator" 
today is "forged".  Naive interpretations only work after something
like an SPF PASS at the border.  Also true for RFC 3834 and MDNs.

> I'm here trying to enlist help to make that illusion disappear

You've posted a link to a recent thread here:  With folks like Alexey,
Arnt, Ned, and Ken I'm confident that they won't blindly believe in
any dubious "originator as indicated by the reverse path" illusions.

 
> Well, that's nice and all, but the folks on the ietf-mta-filters
> list still think it's dandy; they didn't hear his arguments, or
> yours.

About 10% of all mail traffic are misdirected bounces.  Some links
to statistics created by Ironport and/or MesageLabs in 2006 were 
posted here.  Systematic auto-replies to innocent bystanders are by
definition UBE, that's ordinary net abuse, spam.

Cheap solutions like "let others publish FAIL policies", "let others
reject SPF", "let's pretend that 1123 5.3.6(a) was no bug", "let's
pretend the reverse path is normally okay", "let's just trash all
mails with empty reverse paths", etc. cannot work.  Unlike spam it's
a design flaw, a technical problem in SMTP.

It took some years until folks accepted that open relays don't work,
Some still don't accept it.  For crying out loud section 6.1 in 4409
is only an option, it should be a SHOULD.

Frank