Subject: redirect / ereject loops

From: Дилян Палаузов<[email-masked]>
Date: Tue, 22 Jul 2008 23:33:51 +0200

Hello,

While you are talking about loops with "notify mailto", I would like to 
ask you about loops with "redirect". I redirect the mail for my 
university account to uni@mydomain, which has the following script:

if header :contains "X-Spam-Level" "+++++"
         {
                 redirect "me@mydomain";
                 stop;
         }

So, when a spam arrives, the responsibility for the mail is taken and 
the mail is redirected to me@mydomain. In the past me@mydomain moved 
such mails to INBOX.Spam, but recently I changed the script to

require ["ereject"];

if header :contains "X-Spam-Level" "+++++"
         {
         ereject "Your mail was evaluated as spam and was not delivered.
However you can contact me at +49 721 755345(h) or +49 176 20700494(m).";
         stop;
         }

and ereject does SMTP reject. Such redirecting script is also installed 
for the postmaster@. Now my question is, what happens with the spam 
mail: it entered the system being accepted by uni@mydomain, but it 
cannot end in a mailbox. At the end it enters the postmaster mailbox, 
bypassing somehow (to be figured out) the spam filter and growing to 
500k. I have uploaded one such message at 
https://mail.aegee.org/~didopalauzov/Automatically%20rejected%20mail.eml .

Is this normal? Any ideas what to do?

	Със здраве,
		Дилян

---

From: Philip Guenther <[email-masked]>
Date: Tue, 22 Jul 2008 16:51:40 -0600

On Tue, 22 Jul 2008, ????? ???????? wrote:
> for the postmaster@.

When you say "Such redirecting script", do you mean the one for 
uni@mydomain which uses redirect, or the one for me@mydomain which uses 
ereject?

> Now my question is, what happens with the spam 
> cannot end in a mailbox.

_That_ message, the one with "X-Spam-Level: +++++", can't, but the ereject 
*may* result in a new message, a DSN (aka "bounce").  Whether it does so 
depends on the configuration of the mydomain sieve implementation.

If the redirect just queues the redirected message without immediately 
trying to process it, then the ereject will result in a DSN coming back to 
the envelope sender of the redirect, which may be either uni@mydomain or 
the original envelope sender of the spam.

If the redirection is processed to completion, including the ereject by 
the target address, then the original redirect will fail, which will then 
result in the original message being delivered to uni@mydomain's INBOX 
(c.f., rfc 5228, section 2.10.6, particularly the last paragraph).

(Those are just two of the possible scenarios.  Staring a log files may 
give you ideas for other possibilities.)

> At the end it enters the postmaster mailbox, 
> 500k.

If the DSN went to the original envelope sender, it will may be rejected 
by the far end, in which case it's a "double bounce", which often go to 
postmaster by default.

For the postmaster account, ereject is just a Bad Idea.  Use discard.

Perform spam rejection early/at the edge: forwarding spam to some other 
account is just a problem waiting to happen.

 I have uploaded one such message at 
> https://mail.aegee.org/~didopalauzov/Automatically%20rejected%20mail.eml 

Ha, nice.  Looks like a bounce loop all right.  Note that the sieve 
implementation there is violating the MIME spec by using multipart 
boundary strings that are present in the message being wrapped: 
"$pid/$host" ain't good enough.

Philip Guenther

---

From: Ned Freed <[email-masked]>
Date: Tue, 22 Jul 2008 15:04:43 -0700 (PDT)

> ask you about loops with "redirect".

These are very different cases. Perhaps the biggest difference is that loop
detection via Received: fields is much easier with redirect since its the same
message rather than a different one.

> I redirect the mail for my

> However you can contact me at +49 721 755345(h) or +49 176 20700494(m).";

First of all, using any sort of SMTP level reject on an interior MtA is a bad
idea. The problem is once a message enters an administrative domain your
options narrow down to discarding it, delivering it, or returning a nondelivery
notification. The option of simply telling the outside sender the message was
rejected no longer exists, and that's the one case where ereject is useful.

Now, in this specific case, you have two sieves on different systems, the first
redirecting to the second and the second performing an ereject. What happens is
going to depend on what redirect did to the envelope from address. The
base Sieve specification allows substantial leeway here.

If it is left unchanged then the nondelivery notification will go back to the
(likely forged) original sender's address. And lo and behold you've just become
a blowback spam generator. But this is the result of improper use of ereject,
not a problem with redirect.

Alternately, the Sieve implementation could have changed the envelope from to
the owner of the Sieve script. In this case what should happen is that the
nondelivery notification will go to the Sieve owner, causing the script with
the redirect to be invoked again. If in the process the message has again been
checked for spam and has been judged to be spammy, the nondelivery notification
will then be redirected. But since the nondelivery notification is required to
have a blank envelope from address and redirect is forbidden from changing a
blank envelope from into a nonblank envelope from, when the ereject is reached
again this time it will cause the message to be silently discarded. So in this
case the message ends up getting silently dropped. And your ereject has turned
into a discard after taking several extra hops and comsuming a bunch more
resources.

It is also possible that wrapping the original spammy message inside a
nondelivery notification will prevent it from be found to be spammy a second
time. In this case the redirect won't trigger and the message will get
delivered on the first system. In this case your ereject led to a pointless
nondelivery notification being sent to someone.

One final possibility is that the Sieve implementation elected to put some
other address in the envelope from. In that case what happens would depend on
where that address leads, but once again you have a pointless nondelivery
notification being sent somehwere it's not needed.

The main takeaway here is that in no case is the use of ereject actually of
benefit.

> mail: it entered the system being accepted by uni@mydomain, but it

Quite the contrary, depending on various factors it can easily end up in a
mailbox somewhere. See above.

> https://mail.aegee.org/~didopalauzov/Automatically%20rejected%20mail.eml .

This shows that you have managed to create a notification loop. This in turn
means that something in your setup is not in compliance with the relevant
standards. More specifically, either (1) The SMTP client receiving the result
of the ereject is generating a nondelivery notification with a nonempty
envelope form - an egregious violation of several standards documents or (2)
Something along the path is filling in the empty envelope from - a violation of
the requirements in RFC 5228 section 4.2. My guess is it's (2) - this case is
exactly why the "don't muck with empty envelope froms" rule was imposed.

> Is this normal?

No. The only way this can happen is if there's breakage somewhere.

> Any ideas what to do?

Fix whatever is incompliant in your setup and reconsider your use of ereject
in this context.

				Ned