How to avoid mail forward bounce loops?

Submitted by Locutus on Thu, 12/02/2010 - 17:12

Let's assume I have a vserver user user@mydomain.com with an email account configured, who also gets his mail forwarded to another address user@otherdomain.com.

To be able to spam and virus filter mail before forwarding, I've setup the forwarding as procmailrc for the user (via Usermin) and not as a Postfix Virtual Domain entry.

Problem now is: If a spam slips through my spam filter and gets forwarded, but is caught by the spam filter sitting on the target mail server, the mail is rejected with a 550 error. Which entices Postfix to send a non-deliverable report, which in and of itself is okay, since the originating SMTP session is already over.

Unfortunately the NDR goes to to user@mydomain.com though instead of the sender of the original mail. Consequently it gets forwarded to user@otherdomain, and since it contains the original spam, it gets rejected again.

Result: Mail loop.

To resolve that, I currently set up a Procmail rule for the user to sort mail into their local mailbox if the From line starts with MAILER-DAEMON, and not forward it.

But, is there not a "nicer" way around this issue? Like sending that NDR to the original sender instead of the "forwarding" local address? I don't wish to expect my users, if they are to set up their own forwarding rules, to know about this problem and begin their ruleset with such a MAILER-DAEMON entry.

Thanks for insight in advance! :)

Status: 
Closed (fixed)

Comments

Submitted by JamieCameron on Thu, 12/02/2010 - 19:29

Personally I would recommend not bouncing spam email with a 550 error - instead just drop it or save it in some spam folder. How did you set this up exactly?

Bouncing spam can lead to bounce messages being sent to bogus addresses that spammers put in the From: field.

Submitted by Locutus on Fri, 12/03/2010 - 04:28

Thanks for the reply! Yeah of course, you're right... Sending NDRs to the From address is a bad idea indeed. :)

Oh, I forgot to mention that the server rejecting the spam with 550 is not one under my control. The concrete situation here is:

I have a domain invertoforum.de. Mails to the vserver owner account should not be locally stored, but forwarded to "personal" email addresses of mine and of another administrator of the forum. The latter has an address @t-online.de (a huge German ISP). (In this case, the address of mine happens to be one also hosted on the same Virtualmin machine, but that's rather "coincidence" for the general issue.)

The latter mail server is the one rejecting spam with 550, causing the loops.

It would probably be the best in this case to do the forwarding by Postfix Virtual Domain entries instead of user's procmailrc. Still I wanted to try if I can offer spam filtering for users, who afterwards wish to forward the mail to a (non-filtering) external address.

So if that external address rejects the mail, the local Postfix should react accordingly. I.e. not generate an NDR, automatically direct it to a place to collect it (like I did manually with the procmailrc rule) or something.

Hope this info helps for some further insight on your end. :)

Submitted by JamieCameron on Fri, 12/03/2010 - 12:29

So I think the issue here is that the forwarding is being done by Procmail, which effectively re-delivers the mail to the new destination with the forwarder's address as the envelope sender. The envelope sender then gets the resulting bounce..

If you were to do the forwarding using a Postfix alias, the original sender's envelope address would be preserved and the bounce would go to him.

There isn't really much you can do about this other than using an alias to forward email. This can be setup in Virtualmin at Edit Mail and FTP Users -> your username -> Mail forwarding settings -> Forward to other addresses.

Submitted by Locutus on Fri, 12/03/2010 - 15:43

Yeah, that's exactly the issue. :)

So yeah, I suppose it's either "forward without spam checking", or "setup that delivery rule to locally file NDRs to avoid bounces".

Might it be possible to have an appropriate rule in the global procmailrc, you know, the one where Spam Assassin and ClamAV get called? Maybe controlled by a switch in Virtualmin, like the one for spam checking?

So that bounces are appropriately processed on a global level, instead of each user having to add that in Usermin (where most of them will have no idea what they are doing there and why)? :) I think other users might profit from this too, since the wish to spam-check mail before forwarding it is probably not too exotic?

Submitted by JamieCameron on Fri, 12/03/2010 - 15:56

Yeah, you can't do spam checking and forwarding using procmail in this case. But since the remote system is already doing spam checking, that seems OK ..

Submitted by Locutus on Fri, 12/03/2010 - 17:28

In this case, it's okay, yep.

Question that remains is, if I allow my users to create their own forwarding rules in Usermin, and they set one up. How do I avoid this mail bounce loop problem? It would seem that I can't, except I somehow force this special treatment of MAILER-DAEMON mails, as outlined before.

Submitted by JamieCameron on Fri, 12/03/2010 - 18:10

I can't really think of any method either unfortunately :-(

A global entry in /etc/procmailrc to not forwarding MAILER-DAEMON messages would help in this specific case, but wouldn't be a good idea in general as it could lead to users not getting bounce messages forwarded when the really should be.

The only real fix is to do forwarding using aliases rather than procmail rules.

Submitted by Locutus on Sat, 12/04/2010 - 04:12

Okidoki, I guess this'll do for now. Thanks for your time!

Maybe you can consider it as a "feature request" to put some appropriate warning in the switch where you can set if users are allowed to create their own Procmail rules... as in "if you allow them to, they might cause mail loops if they don't know very well what they're doing" etc. :)

It's a bit of a pity actually. Allowing users to create their own forwardings would be a very nice feature. Not really an option though letting them do that unsupervised, if it can lead to such effects.

Submitted by JamieCameron on Sat, 12/04/2010 - 12:18

I think the only workable solution would be for users to create their own entry in /etc/postfix/virtual via some mechanism, perhaps a Usermin module with root permissions but strictly limited functionality (only editing one alias).