The British Caving Association

Posted: **Mon 26 Aug 2019 13:20**

Some email products now make use of Advanced Threat Protection (ATP), which has the potential to thoroughly mangle any server-generated emails that you send. Essentially, it replaces any URLs in your message with so-called "safe links", which can render your emails illegible. Here is an outline of the problem and how to avoid it. Thanks to Gary Douthwaite for alerting me to this problem.

If you are in the habit (as I am) of using server-generated plain-text emails that contain URLs (or more specifically, web site addresses) then you might find that certain email packages - Outlook, gmail etc - replace your compact url, like, e.g. http://hidden.earth, with a much longer and illegible URL that directs the reader to a site that checks the email address for validity. As far as I can determine, the algorithm for this is

If the email is in plain text, parse it for http addresses and replace them
if the email is in HTML then parse and replace only the href attribute of the <a> tag

Thus, the simplest "cure" is that you send an HTML message instead of plain text. To do this in a way that preserves your original intention regarding line breaks, you should...

add a MIME header for HTML content (how to do that is not covered in this post)
encapsulate the content in <pre> tags, possibly adding a style setting for the font as well (or it may default to Courier (yuk!) in your customer's email viewer

There is one difficulty with the above, which is that a mail reader might no longer make the links clickable. For example, Thunderbird seems to do...

If the email is in plain text, parse it for http addresses and display them as clickable links
if the email is in HTML then leave it to the HTML renderer to do this task

...which means that, not only do you need to send an HTML message, but you need to parse it for http addresses and create the <a> tags yourself. This is simple, but here is a tip: make sure that you correctly identify the end of an address. Addresses do not only end in a space, they can also be terminated by punctuation (e.g. a comma or full stop). Something like this perhaps...

Code: Select all

function parse_for_URLs($message)		// returns a modified $message
{  
  // in a supposed plain-text email, replace http addresses with <a> tags
  return preg_replace('/(http.*?)(?=[\.,;\'\"]?\s)/', '<a href="$1">$1</a>', $message);  
}

although that does not allow for URLs that might span more than one line. To encapsulate the text, do something like ...

Code: Select all

function add_HTML_wrapper($message)		// returns a modified $message
{
  $message_top = <<<EOT
  <!--This message requires an HTML text viewer-->
  <pre style="font-family: Consolas, 'DejaVu Sans Mono', 'Lucida Console', 'Andale Mono', monospace">
EOT;
  $message_tail = "</pre>\n";
  $message = $message_top . $message . $message_tail;
  return $message;
}

I am in the process of applying these changes across all the sites that I maintain. I use a single custom function to send email, so its relatively easy to say "if the email does not contain any MIME info then add a MIME type of HTML, encapsulate in <pre> tags and parse for URLs". The problem occurs, for me, if the message is already a multipart MIME message. That's trickier to handle and probably means (for me) "manually" modifying the message when it is generated.

hope this helps

The British Caving Association

Generating emails and avoiding ATP problems

Generating emails and avoiding ATP problems