I run a small mail server with all the usual functionality: Sending of local mail, receiving mail for local folders, redirecting mail according to alias and a mailing lists.

The redirections go to addresses at other domains, including Google, so all spam going to one of these redirected addresses harm my server’s reputation with Google, causing even my locally generate mails to be rate-limited.

I could imagine that one way to reduce the problem is to never store mails that is bound to be redirected. This way, if Google rejects some message as spam, so do I. And instead of my server retrying its delivery, the original server has to which, being a spam sending server, hopefully doesn’t try again.

So the question is: Can I somewhere in the ACLs tell exim to

  • figure out if the mail is going to be delivered using a redirection to a remote location,
  • attempt this right away,
  • and accept the mail only if the relay was successful?


  • Spammers have used real addresses for Return-Path from the same lists they have used for Envelope-To header. You have to use more complex filtering. – Kondybas Jan 21 '15 at 13:49
  • But it still would help to not accept mail that the server I redirect to wouldn’t accept anyways. – Joachim Breitner Jan 21 '15 at 14:20
  • you seem to be asking for cutthrough_delivery (see exim docs) but that won't protect your reputation much. – Jasen Feb 9 '18 at 0:07

This isn't going to be an answer, so much as an explanation of the complexity of what you are trying to do.

You have to ALWAYS remember that an email can be addressed to more than one recipient. You said "I want to not queue it if it's a forwarder". Well, what do you do when one is forwarder and one is a local mailbox? You only know the content of the message (headers and body) during the DATA phase, at which point you will have already accepted the recipients (one forwarder and one local).

This is MUCH more complicated to do what you want because the SMTP Protocol didn't allow for per-recipient preferences to be applied. There is a new feature that's in Exim that is called PRDR (Per Recipient Delivery Responses). It's a draft protocol from years ago that is an extension to the SMTP protocol. Almost no other mail servers support it other than Exim. It requires a mail server to connect to your Exim mail server and say "I see you allow PRDR, so I'm going to request it and will allow you to reject an email for each individual user, not just all or none."

It requires you to configure a PRDR ACL to check for specific things (spam score, recipient marks specific senders as spam, etc). THe ACL is called once for each recipient AFTER the message has been recieved (which is not allowed in regular SMTP), and in that PRDR ACL you can deny or accept for each recipient. Since the sending mail server requested PRDR mode, it will understand it.

Otherwise, you either accept it for all (and risk negative reputation with google) or reject it for all (and risk rejecting wanted email).

You can alternately specify a maximum of 1 recipient per inbound message. When you limit it that way, then you can make a forwarder/not_forwarder designation during the data phase and decide what to do based on spam score. But on emails with 10 recipients, you'll get 1 email to the first one, tempfail the remaining 9, and the sending mail server will queue it and retry later. After some time (depends on the sending mail server queue retry time) you'll get the email again to the second recipient, tempfailing the remaining 8. Repeat for 1, 7 remaining. Repeat for 1, 6 remaining. And remember, inbetween each delivery will be a pause that you cannot control because it depends how long the sender will retry the queued message.

The options for this are not great :-/

** Ironically, LMTP is a subset of the SMTP protocol which is designed for delivering from an inbound SMTP server to a backend mailbox server (i.e. not over the internet, only internally). LMTP does allow for per recipient rejection. So if you want to consider it this way, think of PRDR as applying a specific feature of LMTP to the SMTP protocol.

| improve this answer | |
  • Thanks for the insight! Maybe I need to find another way to make my server more Google-friendly. – Joachim Breitner Jan 21 '15 at 18:50

Sender verification creates an additional load on the foreign MTA's so it isn't recommended. But you can setup a general spam-proof MTA.

My experience shows that two simple conditions helps to detect about 90% of spam:

  1. Senders without PTR-record are definitely spammers. Those who can't setup PTR for a legal MTA are even worse.
  2. Senders with dynamically assigned IP-addresses should send their email via provider's relays. All that static-dynamic-123-456.789-client.fiber.peer.tld are spammers and should be filtered out by simple list of regexes.

Every message that comes from the hosts described above, should be feeded to the bayes. My choice is the spamassassin's one. All the rest messages should be tested by bayes.

That approach allows to filter out about 99.9% of spam and have a big advantage - bayes is updated automatically. All that you have to do - is periodically add some extremely active spammer hosts to the regex list from rule #2.

Having spam detected you can easily prevent its forwarding to the gmail or elsewhere.

| improve this answer | |
  • Of course filtering out spam as good as possible is useful, and I do that. But it’s unlikely that my setup will employ make the same decisions as Google’s, and I’d expect them to have better spam filters than me... – Joachim Breitner Jan 21 '15 at 18:49
  • Yes, google's spamfilter is good, but doesn't it matter whether you redirect 100% of spam or 0.1%? – Kondybas Jan 21 '15 at 18:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.