|
|
|
|
|
|
by duxup
2054 days ago
|
|
|
In the early days of Exchange I was curious what would happen if I setup a rule for two clients to just reroute emails to each other back and forth. So a buddy of mine and I tried it. The rerouting was done (as far as we could tell) client side and it seemed there was no inherent server side method of detecting such scenario. Company email for a few thousand folks went down after the two clients took off doing their thing for a short while. IIRC the client wasn't immediately inclined to forward other forwarded emails (again enforced on the client) but an easily crafted rule would bypass that easily. At the time I was surprised there wasn't any automatic prevention of such things, as my career has gone on, I just assume such things aren't there ;) |
|
|
Mail loops in mail servers have always been a thing, and there are various ways to detect and stop them, usually by adding headers to a message and detecting it's the same one that was seen previously.
If there's actually a client side forward (which mail servers can't prevent because running mail through a local program, whether it be procmail, spamassassin, or some other mail categorization and filtering program) is a valid use case with a long history. There's also the case where the mail client is applying it's own complex rules and sending responses automatically. If the message is actually a new one, there's not an easy way to detect the loop.
There's a reason why Gmail for a long time (still?) didn't allow you to forward your mail to another Gmail address. I would argue that for Exchange, where it's generally much easier to track down individuals, erroring on the side of allowing administrators to do what they want to block this (whether that be company policy, exchange policy, or whatever) is the correct design choice.