Forwarding to users home addresses

In today's busy information age more people are connected to their office email at all times than ever before. Smart phones, webmail or even VPN connections to their office network are more and more common.

One unfortunately common idea to help facilitate connectivity to work email during vacations or for off site users is to set up forwarding rules. So, if I'm on vacation (like that'll ever happen ;-) ) you could email me at my email address NotA.RealAddress1@theemailauthority.com (that's not a real address, so spammers can't harvest it) and I'd just set that address to forward to MyHome.Address2@PersonalAddress.com. Then when I check my home email, I'll be able to see the work I have to respond to as well.

Seems like a very convenient way to give people access to their email while on vacation or for offsite users in general, huh? Think again.

If I had a penny for all the reasons I'm about to list I'd have, well a few more cents, but you know what I mean.

I. Habituation

Social Engineering is often used in hacker terminology to mean gaining access to restricted material by direct human contact. Although almost the exact opposite of this usage, it's still the admin's responsibility to "engineer" their end users into acceptable behavior. It's not only our job to facilitate technological requests, it's our job to explain why some things shouldn't be accomplished a certain way, if at all. If a user said "this whole logging in thing, it's a pain to deal with. Let's get rid of it" you'd look at them as if they had two heads. Similarly, there are times when we must take an almost mentor type role and explain the repercussions of user's decisions and guide them to become used to a more sound solution or adapt the solution in a way that's secure and doesn't create even more issues down the road.

Here are some examples of how users can create issues with email forwarding.

1. Reply/Reply All

OK, so a client's email gets sent to HomeUser@gmail.com or whatever. Now, if your user has to respond, where does the email come from? Their home address, that's where. This causes confusion to the sender since now they have a new address, and it can take weeks for the senders to stop just clicking "reply" or finding the old thread and "replying all".

2. Address books

In addition to the threads going back and forth to the user's home address, how many times do your users bother to look at the actual email address they're sending to? Often they rely on their address book entry, which can now be compromised with the new entry for "John Doe", but "John Doe's" home address. This can indefinitely prolong the above "replying all" issue as each new thread will be sent to whatever address "John Doe" has in the remote address book.

3. Multiple mailboxes

Skip forward a few days. Now the user is back in the office and looking at their normal email client. Where are the messages? In their home email, that's where. Now they have two places to check, again sometimes for weeks until the thread dies, offering the possibility of lost email, delayed responses, or any number of other issues that make your company look bad.

4. Misplaced blame

Ok, so your user receives a spam message (or a message they think is spam). They click the "this is spam" button in their gmail/hotmail/etc. If the message is being forwarded from your server, their home email provider often simply sees the connecting IP which if you're forwarding the email from your mail server is now you. Now the user's home provider views you as a spammer, and the legitimate emails you're trying to get to your user get caught in the spam trap as well as the spam. I've seen AOL for instance do this several times causing admins no end to headache (try getting a decent AOL support tech on the phone to fix a problem, I dare you).


II. Technology issues

In addition to the user based issues above, there are obvious technical issues as well.

1. Routing of complaints

Although mentioned above, I cannot stress this enough. If you do this with the average user, sooner or later you take a strong risk of getting blacklisted. Depending on a few factors this can have tremendous impact on your infrastructure. If your user is sending spam reports to their provider, and you have many other customers on the same provider, your email will end up not only in your user's spam box, but any other customer who uses the same provider. For instance, if you forward to AOL, and your user gets you blacklisted by AOL then you try to send a legitimate piece of email to another AOL user, you will not get it through. I simply cannot stress this enough.

2. Bad practices

Anyone remember the post about the "border MTA's" role? If not, click that link and read it right now. Now you've got your email passing through your border MTA with all of it's antispam, antivirus, DDOS protection, etc, then you're passing it to ANOTHER border MTA to handle the same things again. You can see above for one instance of how this can cause headaches, but there are so many more. Rate limiting, spam complaints, automated processes, greylisting, availability, the list goes on and on.

3. Backscatter

I'll have a whole post at some point on this topic if you're not familiar with the term. In the meantime you can click here for more info. Including multiple border MTAs will almost always result in some type of backscatter. There are RBLs that focus exclusively on the source of backscatter, and many include backscatter sources at least incidentally in their lists. If you've ever tried to get off of some of these RBLs you'll probably agree you don't want to do it again anytime soon. Additionally, I guarantee if you've ever been the victim of a spoofing attack you'll understand how frustrating backscatter can be, and you'll never want to inflict it on anyone.

4. Archiving and other requirements

Many companies are required by law to archive email sent on the company's behalf. How are you going to archive messages that were sent from the user's gmail/hotmail/yahoo account? How are you going to archive messages that were replied back to those addresses? Is it more or less likely that someone on vacation would respond in an unfavorable (and therefore liable) manner when they're sucking down Pina Coladas on a beach somewhere than when they're in the office? Don't you think these messages above all others should be archived?

5. "too many hops"

Many mail servers have rules in place for how many other servers can be listed in the headers. If there are too many, you can generate bounces that claim there were "too many hops". Since this is entirely out of your control once it leaves your network it's something to take very seriously unless you enjoy talking to other support reps all day while troubleshooting this error. Although a couple additional hops should be fine, you have no idea how badly mangled your user's home email routes are. Maybe they've had the same email address for years, but they tried Hotmail first, then used AOL, then gmail. If they set forwarding rules (which are often the home user's only option outside of changing their email address) you'll have several hops per provider, not including yours. You can see how this would quickly add up. Also, there are outbound routes too, so it could be that some of your senders place several hops before it even reaches your network. Therefore any testing you do would be moot, and those senders will still get "too many hops" errors.

III. Easy solutions

So, your user needs remote access. This is an understandable need. There are literally too many options to mention, but here are a few

1. Give them access.

Look, we have to be security conscious. There are simply too many threats out there to leave your firewall wide open for all email traffic. However, there are plenty of ways to mitigate the risk without making your users' lives harder. If you don't want to open POP/IMAP/SMTP ports, dont. But use other ports and NAT them to the correct ports on your server. Of course this doesn't stop port scans, but it will lessen the number of available threats to the point you can sleep most nights ;-)

2. Require encryption

If you feel safe logging in to your bank account via the web, then you trust SSL. Require SSL/TLS connections at least from your outside users. This will both change the default port (which you should again change), and also prevent snoops from intercepting potentially sensitive information. Sure, they could have a keylogger, etc at home, but they might in your organization too.

3. Control the hardware

Provide them with a laptop if possible that contains all of the security software you use at the office and require them to return it when they're back home. This way you know at least as of the day they left they have up-to-date virus definitions, patches, and all of the other things users forget to do at home, but it's your job to do at work.

4. Use webmail, or get a vendor

Quite simply, webmail is a must. If you don't want to offer the webmail service directly on your server, offer it through a vendor and grant them access to your server. Zimbra for instance allows you to sync multiple mailboxes via IMAP in their webmail interface. as long as you grant access from the vendor to your IMAP port they can interface with their email just fine. Zimbra also offers the option of smart hosting to your mail server for outbound communication to help with your archiving/discovery software.

5. Give them a smart phone

If it's a power user who is always on the go, give them a smart phone. Personally, I prefer typing emails on many smart phones. Maybe it's all the years of gaming, but I actually find it more convenient to type on some of the keyboards with my thumbs than on my desktop with my whole hands/wrists/etc. Then, depending on the method of delivery to/from your mail server you can enforce policies to only allow connections from the specific devices, or their carrier will often offer (in the case of Blackberries) an option for them to deliver messages for you. Just be sure to allow the carrier to send from your domain in your SPF record.

To summarize, there are just too many simple solutions that offer more security and audit trails, as well as much less risk of headache. If you're an end user who has to deal with whatever your provider gives you, feel free to use email forwarders. If you're an admin you have the power to handle these issues the "right way", or really in any of the "right ways" you see fit. Remember the K.I.S.S. principle applies to your email's path, not your setup. Think of the slight inconvenience of doing it right as an investment on all the time you won't have to spend troubleshooting later.


TEA