Personally, I probably cut people a bit of slack by going through whois to check if the domain belongs to some well-recognized mass mailer, but I wouldn't blame the MUA for just spamming anything that mentions a "login" along with a domain that isn't a descendant of the sender's domain.
1. User clicks http://links.example.com/?redirect=example.com/reset_passwor...
2. The server running on links.example.com makes a request to the third party web server
3. The server redirects the user to http://example.com/reset_password
Not that I'm particularly a fan of either practice, but there's probably some use cases there that would have to be accounted for in some way that the 3rd party service could accommodate.
I agree that neither approach is ideal, but it would prevent users from receiving third party links in their emails.
Better yet, simply point your DNS "passwordreset.evernote.com" to the same server.
If the user requests (from a link in the mail) "mkt5371.evernote.com/foo123", redirect to "links.evernote.mkt5371.com/foo123"; If they request "/bar456?id=asdask", redirect to the same query under the mailer's domain.
1) Silverpop doesn't have an option to disable tracking for specific links included in emails sent from their system or
2) The person creating the email failed to take advantage of this feature.
If Evernote wanted to take advantage of this feature on purpose in order to determine what percentage of their userbase has reset their password, then I'm baffled why they decided to trust a 3rd party lead management system instead of the updated_at fields in their database.
Either way, the whole point of purchasing Silverpop is that you can avoid having to code your own solution.