Understanding X-Loop forwarding headers


2012/11/10

How the X-Loop header works and how Cpanel apparently breaks it.

Perusing email headers is not something most of us spend much time doing, and some headers only appear under certain circumstances, so you may never have seen or heard of the "X-Loop" header. It appears (or should appear) when email is forwarded from one person to another. For example, if I have a forwarding rule that sends an email from my "[email protected]" account to my Gmail account, the headers will include these lines:


Resent-From: <[email protected]>
Resent-To: <[email protected]>
Resent-Date: Fri, 9 Nov 2012 12:53:07 -0500
X-Loop: <[email protected]>
 

(Note that if I just select a message and click "Forward", I won't get these headers - this has to be done by a forwarding rule.)

The purpose of that header is to prevent mail loops from auto-responders. If my Gmail account had an auto-responder set because I planned to be out today, it wouldn't be good if the response that it sent back to me also got forwarded back to them again. Unless one of the machines was smart enough to realize that they were playing ping-pong, that loop could go on forever, bouncing emails back and forth, wasting time and filling up both INBOXes.

Of course there are ways to stop such loops. Many auto-responders include a rule that prevents them from responding more than once each day to the same email address. Such a rule requires a database of responses made; the X-Loop header is much more simple. My mail server at Aplawrence.com simply refuses to accept any mail coming to "[email protected]" that has an "X-Loop: <[email protected]>" header.

It's that simple: if it's sent to me and has an X-Loop header that has my address, it has to be because some foolish email server responded to what I forwarded to it. Simple and effective.

Until somebody breaks it, that is.

Broken X-Loop

A customer wrote to me explaining that he had a problem with an auto-response. A CPanel system had been configured to respond to emails notifying the sender that they should be using another address. When this customer tested that by sending email to the dormant address at the Cpanel system, he never saw the response. Examining his Kerio logs found this:

[05/Nov/2012 18:33:32] Sent: Queue-ID: 50984ccb-00025ee0,
Recipient: < [email protected]>,
Result: failed, Status: 5.5.2 5.4.6 Routing loop detected
 

My first suspicion was that either the Cpanel domain thought it was also responsible for his Kerio server's domain or vice-versa, but that was not the case. I also thought that perhaps the Kerio mail address might include some forwarding that was somehow looping back to itself, but that wasn't true either (and would have produced a different result, as well). Puzzled, I bumped it up to Kerio support who suggested stopping the Kerio server and editing the mailserver.cfg file as follows:

<variable name="LoopDetectionEnabled">0</variable>
 

That's normally set to "1"; setting it to 0 disables checking for a matching X-Loop header. Once he had made that edit and restarted the mailserver, the autoresponse from the Cpanel system did arrive in his mailbox and sure enough, it contained an offending X-Loop header.

I say "offending" because the header was incorrect - it contained the address that he used to send email to the dormant address. The X-Loop header should have had the dormant address in it, not the address of the person being responded to. That was confirmed to be true by sending a message to the dormant address from Gmail. The return message contained an X-Loop header set to the sending Gmail address.

Why didn't Gmail reject that as the Kerio server does by default? That's a good question - it should, but apparently Gmail does not. Maybe Gmail just assumes that enough other people have properly configured auto responders that it need not bother or it may keep a database count of such problems and feel that the extra check is unnecessary.

In any case, the Cpanel server is dead wrong when it puts the sender's address into that X-Loop header, but when my customer pointed that out to the folks who are responsible for it, they insisted that it comes from Cpanel and they can't change it. I don't know if that is true, but that was the end of any conversation they were willing to have, so it's true for that site at least.

If it is more generally true - if all Cpanel sites work this way - then it's quite possible that Kerio and other mail servers that enable X-Loop detection will never see any automatic responses from those servers. If that's of concern to you, you might want to disable the setting, though doing so could cause problems for you if you accidentally create a mail loop with some other server that doesn't check for these headers. As long as at least one server involved also has the rule that limits responses to one per day, that should be safe. Kerio "vacation" settings have that logic, so I think it would be safe to leave the loop detection set to disabled as long as you don't create your own internal forwarding loops. Unfortunately, creating such accidental loops is not all that hard to do!



Got something to add? Send me email.





(OLDER) <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> Understanding X-Loop forwarding headers




Increase ad revenue 50-250% with Ezoic


More Articles by

Find me on Google+

© Anthony Lawrence



Kerio Connect Mailserver

Kerio Samepage

Kerio Control Firewall

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us





There are two ways to write error-free programs; only the third one works. (Alan Perlis)

The idea of "work, then get paid" has been deeply ingrained in our culture by employers who want to limit their risk. Well, I like to limit my risks also. I like to get paid before I do work. (Tony Lawrence)








This post tagged: