While you are talking about loops with "notify mailto", I would like to
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
university account to uni(_at_)mydomain, which has the following script:
if header :contains "X-Spam-Level" "+++++"
{
redirect "me(_at_)mydomain";
stop;
}
So, when a spam arrives, the responsibility for the mail is taken and
the mail is redirected to me(_at_)mydomain(_dot_) In the past me(_at_)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;
}
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.
and ereject does SMTP reject. Such redirecting script is also installed
for the postmaster(_at_)(_dot_) Now my question is, what happens with the spam
mail: it entered the system being accepted by uni(_at_)mydomain, but it
cannot end in a mailbox.
Quite the contrary, depending on various factors it can easily end up in a
mailbox somewhere. See above.
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 .
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