email forwarding

The Register’s Thomas Claburn details a recently shared research paper exposing troubling examples of loopholes in email authentication, allowing bad guys to spoof messages via email forwarding. Thankfully, some of the potential loopholes reported have already been addressed by specific email service providers. Some might say “don’t share this, as we don’t want to give the bad guys more ideas,” but I think it’s important for everyone to read and understand potential limitations and/or bugs in how things are implemented today, so that we can focus on addressing those problems, sooner, rather than later.Click on through to read “If you’re struggling to secure email forwarding, it’s not you, it’s … the protocols” over at The Register. (Great title, though it’s not always the protocols — sometimes it’s the implementation thereof.)

ARC (Authenticated Received Chain) is an email authentication mechanism, sort of. The point of ARC is to encapsulate a check of email authentication results and include it in forwarded mail.If I receive email at an address, then I forward mail to another address, authentication results are difficult for the mail server at the second receiving site to interpret correctly. SPF works on a “last hop” methodology, meaning that a server doing an SPF check can only check the server that just connected to it — making it incompatible with email forwarding, because email forwarding involves more servers and thus more “hops.” A DKIM authentication signature is supposed to be compatible with email forwarding, but there are enough glitches out in the wild — encoding problems, rewriting headers for forwarding (or adding headers or footer text for mailing lists) that it just doesn’t work perfectly 100% of the time. And then