2

We send out password-reset emails to business partners who use our intranet. The body of the email contains a hyperlink:

  `http://www.ourdomain.com/ResetPassword.aspx?token=....`

But some of the people who receive these emails are saying there's an extra dot in the domain name:

  `http://www.ourdomain..com/ResetPassword.aspx?token=....`

I do not see where that could be happening in the program I've written. I store the base url in the web.config:

  `http://www.ourdomain.com`

and attach the name of the aspx page and append the token to it.

Are there any corporate anti-virus programs out there which deliberately mangle hyperlinks discovered in the body of emails, to render them invalid and thus unclickable?

Tim
  • 8,669
  • 31
  • 105
  • 183
  • I cannot say definitively but I know that some versions of Outlook throw away any text/plain multipart message and show their own converted plain text version when you choose to view text only emails. Do you know if this issue is restricted to certain mail clients? Can you view the entire mail headers of a mangled email and look for any headers that start with X- ? – chugadie Mar 09 '15 at 21:00
  • We are still trying to get that important piece of info. Don't have it yet, unfortunately. So far, one is MS-Exchange with "ironport-av" – Tim Mar 09 '15 at 21:04
  • This seems to be spec behavior. http://stackoverflow.com/questions/6602318/system-net-mail-creating-invalid-emails-and-eml-files-inserting-extra-dots-in-h It's possible some clients are not interpreting correctly. Solution is to use a different transfer encoding. – chugadie Mar 09 '15 at 21:12

1 Answers1

1

This seems to be per the spec of quoted-printable encoding. It just so happens that the length of text in the message breaks to a new line right at the .com (72 characters maybe?). Please verify that this is the case by sending yourself a message and analyzing the quoted-printable source of the message.

System.Net.Mail creating invalid emails and eml files? Inserting extra dots in host names

The solution would be to not use quoted-printable encoding if some email programs cannot correctly interpret the spec.

 plainText.TransferEncoding = System.Net.Mime.TransferEncoding.SevenBit;
 //or base64
Community
  • 1
  • 1
chugadie
  • 2,786
  • 1
  • 24
  • 33
  • I looked at the quoted printable source and the domain-name isn't straddling a line-break. I would see `www.ourdomain=` correct, with the `.com` on the next line? The `.com` is about the 26th position on the line. – Tim Mar 09 '15 at 21:32
  • Perhaps some mail agents are altering the quoted printable source? But combine that with failing user agents and the possibility of hitting both bad MTA and bad email client seems quite small. – chugadie Mar 09 '15 at 21:44
  • Should the receiving server "adjust" the quoted-printable double-dot back to a single dot, if that is indeed what is happening? (I've changed to UTF8 in any case, but I'm curious.) – Tim Mar 10 '15 at 12:28