Community Discussions and Support
utf-8 encoded Reply-To causing delivery failures in autoreplies

Hi Brian,

first of all: happy new year and all the best for 2020!

[quote]My thinking is to create a global filter in Mercury that could detect and delete such autoforward messages. 

Would a filter that looks for "To:*utf-8*" work?[/quote]

Yes ... but this will filter all mails with utf-8-encoded header TO. Because you only want autoreplies to be filtered, you should add someting like:

AND "Subject:*Autoreply*"

 Bye    Olaf

 

<p>Hi Brian,</p><p>first of all: happy new year and all the best for 2020! </p><p>[quote]My thinking is to create a global filter in Mercury that could detect and delete such autoforward messages.  </p><p>Would a filter that looks for "To:*utf-8*" work?[/quote]</p><p>Yes ... but this will filter all mails with utf-8-encoded header TO. Because you only want autoreplies to be filtered, you should add someting like:</p><blockquote><p>AND "Subject:*Autoreply*"</p></blockquote><p> Bye    Olaf</p><p> </p>

I'm starting to see more utf-8 encoded headers which seems to only be a problem when the Reply-to header is encoded and a autoreply is generated by a FORWARD file.

Of course the autoreply fails but what I'm curious about is what the message attached to the delivery failure notice shows the header as decoded yet the body of the rejection message itself shows the header encoded (examples are per below).  I would be grateful for an explanation of why this is so as to get an idea how to create a filter that will block such autoreplies.

Message headers as per attachment to delivery failure message:

    To:    partstownsurveys@partstown.com
    Subject:    [Autoreply] Re: The Talk of the Town Starts with You!
    Date sent:    Mon, 30 Sep 2019 11:20:23 -0400

 

Delivery failure message shows:

 The attached message has failed delivery and has been referred
to you as postmaster. The following error report or reports
were given to explain the problem:

   *** =?utf-8?q?partstownsurveys=40partstown=2Ecom?=
   User =?utf-8?q?partstownsurveys=40partstown=2Ecom?= not known at this site.

 

This is the Reply-To header of the original message:

   Reply-To: =?utf-8?q?partstownsurveys=40partstown=2Ecom?=


<p>I'm starting to see more utf-8 encoded headers which seems to only be a problem when the Reply-to header is encoded and a autoreply is generated by a FORWARD file.</p><p>Of course the autoreply fails but what I'm curious about is what the message attached to the delivery failure notice shows the header as decoded yet the body of the rejection message itself shows the header encoded (examples are per below).  I would be grateful for an explanation of why this is so as to get an idea how to create a filter that will block such autoreplies. </p><p>Message headers as per attachment to delivery failure message:</p><p>    To:    partstownsurveys@partstown.com     Subject:    [Autoreply] Re: The Talk of the Town Starts with You!     Date sent:    Mon, 30 Sep 2019 11:20:23 -0400</p><p> </p><p>Delivery failure message shows:</p><p> The attached message has failed delivery and has been referred to you as postmaster. The following error report or reports were given to explain the problem:    *** =?utf-8?q?partstownsurveys=40partstown=2Ecom?=    User =?utf-8?q?partstownsurveys=40partstown=2Ecom?= not known at this site.</p><p> </p><p>This is the Reply-To header of the original message:</p><p>   Reply-To: =?utf-8?q?partstownsurveys=40partstown=2Ecom?= </p><p> </p>

Hi Brian,

the answer is very simple: the answering mailhost (Mercury?) doesn't decode the header lines prior to put it into the error message. The same "problem" comes up on error messages with encoded subject. A little bug and not that big problem as long as the header is encoded "q" (quoted printable). If the header is encoded "b" (base64) you have no chance reading it. You have to copy the string and decode it (i.e. with Notepad++).

Advising a filter ... there is poor information. Which mailhost (Mercury ?) at which domain (partstown.com ?) sent this mail to postmaster at which domain?

Bye

   Olaf

<p>Hi Brian,</p><p>the answer is very simple: the answering mailhost (Mercury?) doesn't decode the header lines prior to put it into the error message. The same "problem" comes up on error messages with encoded subject. A little bug and not that big problem as long as the header is encoded "q" (quoted printable). If the header is encoded "b" (base64) you have no chance reading it. You have to copy the string and decode it (i.e. with Notepad++).</p><p>Advising a filter ... there is poor information. Which mailhost (Mercury ?) at which domain (partstown.com ?) sent this mail to postmaster at which domain? </p><p>Bye</p><p>    Olaf </p>

[quote user="FJR"]Advising a filter ... there is poor information. Which mailhost (Mercury ?) at which domain (partstown.com ?) sent this mail to postmaster at which domain? [/quote]

My thinking is to create a global filter in Mercury that could detect and delete such autoforward messages. 

Would a filter that looks for "To:*utf-8*" work?


<p>[quote user="FJR"]Advising a filter ... there is poor information. Which mailhost (Mercury ?) at which domain (partstown.com ?) sent this mail to postmaster at which domain? [/quote]</p><p>My thinking is to create a global filter in Mercury that could detect and delete such autoforward messages.  </p><p>Would a filter that looks for "To:*utf-8*" work?</p><p> </p>
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft