Email Server Design: Avoiding Loops [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center. Closed 9 years ago.

Lets say you are designing a fancy email server with rules support (like conditional forwarding, etc.). The age-old problem of email loops stares you in the face:

1) Say you set up a rule that forwards all of your mail to another address. What if that address doesn't exist, and the postmaster at that domain sends messages back to you telling you this. Of course, your rule doesn't make a distinction for these messages and forwards them as well, creating a loop.

2) Another situation is two users, using this client client, set up forwarding rules to each other's address. All we need is a single starter message and they are going to spin off into a loop.

3) Or, how about an auto reply case, where the client forwards to an address that auto replies back, causing yet another loop.

I'm not an expert on this stuff, but it doesn't look like detecting the loops would work. We could certainly come up with some heuristics, but a catch-all algorithm doesn't seem to exist.

One solution I've been thinking about doesn't involve detection at all. Instead, we just watch accounts for high mail send activity (or high send activity caused by rules), and temporarily disable email / rules for these accounts until they correct the problem. However, this solution has to walk the line between accounts causing loops, and accounts that simply receive开发者_Python百科 a lot of mail and are forwarding it somewhere else.

We could also apply throttling to all accounts, and make sure that if loops start, they don't suck up a ton of bandwidth. This won't stop loops from running until mailboxes fill up though.

Are there any good solutions I'm missing?

---

First, start by reading RFC 3834. It gives some good insights into what you care about. (It covers autoresponders, not forwarding, but it's still useful.)

In general, you'll want to add an X-header to the message during forwarding to indicate that the message has been delivered to the user's mailbox once. (This is what the Sieve RFC mentions in its redirect section.) If a message comes in for bob@example.com and there's an X-header mentioning bob@example.com, you have a loop. So something like this:

X-YourServer-Delivered: bob@example.com

You'll also want to avoid forwarding message delivery notifications, which should have <> as the SMTP MAIL FROM. And don't forward autoresponder messages, which should have an Auto-Submitted header with a value other than "no".

Look over RFC 3834 for more ideas on what not to forward, but the above should cover most cases.

---

1) Say you set up a rule that forwards all of your mail to another address. What if that address doesn't exist, and the postmaster at that domain sends messages back to you telling you this. Of course, your rule doesn't make a distinction for these messages and forwards them as well, creating a loop.

Well think about it, you'd get back the same "mailbox unreachable" message once, twice, three times. If you just consider it spam and stop applying rules to it after the 3rd identical copy, you're set!

The same applies to your 3rd example too, the autoreply would be identical. Stop running your rules on it after the 3rd identical message.

The 2nd is a bit trickier, and a lot less likely. I'm not sure of a best solution, but you could for example check the differences and see if all the new message is doing is adding a FW: in the title or adding a quote. I don't know..

---

You could include a bit in the rules processor that checks the recipient of the auto-generated email, and if that exact same email (perhaps via a hash) has already been send to that recipient, then it doesn't send the email.