I have a private website that every week sends e-mails with two different http links to a group of around 30 people. When a link is clicked, the answer is registered in a database. Starting last week, one of the recipient's links is automatically followed by either a network sniffer or some malware on the recipient's computer.

Each e-mail is sent individually since the links contain each recipient's e-mail adress:

Yes, I will attend:
http://mywebsite.com/[email protected]&answer=yes

No, I can't attend:
http://mywebsite.com/[email protected]&answer=no

Around 20 minutes after the e-mail has been sent, I get the following request to my website:

UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2; MS-RTC LM 8)
Browser: IE 7.0
Platform: WinXP
HttpMethod: GET
Path: /default.aspx
Url: http://mywebsite.com/default.aspx?answer=ab&[email protected]

There are some strange things to observe here:

  • The e-mail adress and answer are both ROT13-encoded (but not the parameter names).
  • The order of the parameters are reversed.
  • Only the second link, with answer=no, is followed.


  • The IP-adress, UserAgent, Browser and Platform fields do not match those of the recipient's computer (but they might be spoofed, of course).
  • The IP-address used last week was Both addresses seems to be dynamically allocated at the above.net domain, performing a tracert yields the hostname
  • Checking the e-mail headers, the e-mail was sent from my web hotel binero.net via messagelabs.com to the recipients mailserver.
  • It is only this single recipient that have these problems.

Does anyone recognize the pattern of following e-mail links and encoding the parameters with ROT13?

1 Answer 1


Hah, 5 minutes after posting the question I found the answer myself. Ever had that happen to you? :-)



It took a few calls with AboveNet (now part of Zayo), but we were finally able to determine that one of their customers is an anti-malware firm based in the UK, providing services to two of our common customers. They were scanning all incoming emails and probing any hyperlinks to identify potential hazards and/or vulnerabilities in the destinations.

  • Ditto for us. Once I realised just the values in the params were ROT13 a quick google led me here. IP probing our 'unsubscribe' links was also an AboveNet server
    – jaygooby
    Commented Oct 8, 2014 at 10:46
  • 1
    Been tearing my hair out wondering what was causing this for a month. Finally coming to the same conclusion after adding logging for IP and user-agent, then came upon this - confirmation. Thanks.
    – Chris
    Commented Feb 3, 2015 at 11:04
  • BTW, did you come up with a way a to avoid the problem? I've added a constant param that is now the only thing being ROT13d that I can check and discard if it doesn't match original. Concerned it could be a bit brittle though. They could easily change their algorithm.
    – Chris
    Commented Feb 3, 2015 at 11:09
  • 1
    No, at the moment I'm only checking for ROT13:d parameters and discard the request if found.
    – Anlo
    Commented Feb 3, 2015 at 15:01
  • 1
    We lost so MUCH time trying to figure out were those calls where coming from... Thanks for this answer. We're considering responding to those calls with a HTTP response "418 I'm a teapot" since it looks like this is the more appropriate answer i could find in the spec.
    – nfroidure
    Commented Jun 21, 2016 at 8:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .