Mercury C 'From:' header parsing problem

posted May 7 '09 at 6:09 pm

As for the other two fields (Sender: and X-Envelope-To:), neither
are in the headers section. It might help if I clarified that I'm using
Mercury's POP3 D connector for retrieval on these accounts, not SMTP.

Should not make any difference unless you are delivering directly to a users mailbox instead of allowing Mercury core to do this.

As for 4.01b, I just noticed the new version of Mercury and I have
put upgrading on my todo list. Will the new version install on top of
the old and maintain configurations or will it need to be a clean
uninstall/reinstall with a manual reconfiguration of all options?

Just install as an upgrade over the current setup. Have to shut down Mercury while you do the upgrade but other than that it should take seconds to do.

<blockquote>As for the other two fields (Sender:&nbsp;and&nbsp;X-Envelope-To:), neither are in the headers section. It might help if I clarified that I'm&nbsp;using Mercury's POP3 D connector for retrieval on these accounts, not SMTP. </blockquote>Should not make any difference unless you are delivering directly to a users mailbox instead of allowing Mercury core to do this. &nbsp; <blockquote>As for 4.01b, I just noticed the new version of Mercury and I have put upgrading on my todo list.&nbsp;Will the new version install on top of the old and maintain configurations or will it need to be a clean uninstall/reinstall with a manual reconfiguration of all options? </blockquote>Just install as an upgrade over the current setup.&nbsp; Have to shut down Mercury while you do the upgrade but other than that it should take seconds to do.&nbsp;

farmbelt

posted May 6 '09 at 7:45 pm

I have recently started using the SMTP relay module in Mercury 4.01b to relay some of my email to an Exchange server. One of my vendors uses an automated reply with a FROM: header that appears to be causing the SMTP C module some problems.

The header field looks like this:

From: Bush Hog, "L.L.C." <first.last@bushhog.com>

I've replaced the user name, however the rest of the line is verbatim; pasted directly from the raw message as stored locally by Mercury.

The module relays this (copied from the log file):

10:22:23.781: << MAIL FROM:<Bush Hog> SIZE=2877<cr><lf>
10:22:23.781: >> 501 5.5.4 Invalid Address<cr><lf>

Mercury tries to send an NDR to <Bush Hog> which results in 3 NDR's to the postmaster as the invalid address gracefully deteriorates. Mercury tries to followup the first failed address with the following:

10:26:27.093: << MAIL FROM:<> SIZE=5368<cr><lf>
10:26:27.093: >> 250 2.1.0 <>....Sender OK<cr><lf>
10:26:27.093: << RCPT TO:<<>><cr><lf>
10:26:27.093: >> 501 5.5.4 Invalid Address<cr><lf>

At the moment I'm filtering out these incoming messages while I work on a solution. I haven't received a reply from the vendor yet as to whether they can or will change their address field.

Is this a possible flaw in the module parsing routine or just a weakness exposed by a bad and/or invalid address field?

Any other thoughts or suggestions on this problem? I get 3-4 of these replies per day and they are necessary for verification and tracking of orders so I can't just dump them.

Thanks for any and all replies.

Regards,

Dave

I have recently started using the SMTP relay module in Mercury 4.01b to relay some of my email to an Exchange server. One of my vendors uses an automated reply with a FROM: header that appears to be causing the SMTP C module some problems. The header field looks like this: From: Bush Hog, "L.L.C." &lt;first.last@bushhog.com&gt; I've replaced the&nbsp;user name,&nbsp;however the rest of the line is verbatim; pasted directly from the raw message as stored locally by Mercury. The module&nbsp;relays this (copied from the log file): 10:22:23.781: &lt;&lt; MAIL FROM:&lt;Bush Hog&gt; SIZE=2877&lt;cr&gt;&lt;lf&gt; 10:22:23.781: &gt;&gt; 501 5.5.4 Invalid Address&lt;cr&gt;&lt;lf&gt; Mercury&nbsp;tries to send an NDR to &lt;Bush Hog&gt; which results in 3 NDR's to the postmaster as the invalid address gracefully deteriorates. Mercury tries to followup the first&nbsp;failed address with the following: 10:26:27.093: &lt;&lt; MAIL FROM:&lt;&gt; SIZE=5368&lt;cr&gt;&lt;lf&gt; 10:26:27.093: &gt;&gt; 250 2.1.0 &lt;&gt;....Sender OK&lt;cr&gt;&lt;lf&gt; 10:26:27.093: &lt;&lt; RCPT TO:&lt;&lt;&gt;&gt;&lt;cr&gt;&lt;lf&gt; 10:26:27.093: &gt;&gt; 501 5.5.4 Invalid Address&lt;cr&gt;&lt;lf&gt; At the moment I'm filtering out these incoming messages while I work on a solution. I haven't received a reply from the vendor yet as to whether they can or will change their address field. Is this a possible flaw in the module parsing routine or just a weakness exposed by a bad and/or invalid address field? Any other thoughts or suggestions on this problem? I get 3-4 of these replies per day and they are necessary for verification and tracking of orders so I can't just dump them. Thanks for any and all replies. Regards, Dave &nbsp;

Thomas R. Stephenson

posted May 6 '09 at 8:37 pm

Mercury 4.01b

You really should upgrade.

From: Bush Hog, "L.L.C." <first.last@bushhog.com>

This is two addresses in the from field and when used in a reply it will send mail to the addresses Bush Hog and "L.L.C." <first.last@bushhog.com>. When this is auto forwarded though Mercury/32 is going to use the first address as the MAIL FROM: address. The sender should either remove the comma from the address or enclose the entire text in quotes, i.e. "Bush Hog, L.L.C." <first.last@bushhog.com> Until they fix their from address you really need to use a filter or alias to catch this one and forward it to a local account for manual handling.

FWIW, what is shown in the Sender: field and the X-Envelope-To: of a delivered message.

<blockquote>Mercury 4.01b </blockquote>You really should upgrade. <blockquote>From: Bush Hog, "L.L.C." &lt;first.last@bushhog.com&gt;</blockquote>This is two addresses in the from field and when used in a reply it will send mail to the addresses Bush Hog and&nbsp; "L.L.C." &lt;first.last@bushhog.com&gt;.&nbsp; When this is auto forwarded though Mercury/32 is going to use the first address as the MAIL FROM: address.&nbsp; The sender should either remove the comma from the address or enclose the entire text in quotes, i.e. "Bush Hog, L.L.C." &lt;first.last@bushhog.com&gt;&nbsp; Until they fix their from address you really need to use a filter or alias to catch this one and forward it to a local account for manual handling. FWIW, what is shown in the Sender: field and the X-Envelope-To: of a delivered message.

farmbelt

posted May 7 '09 at 5:13 pm

Thank you for the reply. It confirms my suspicions. Perusing RFC2822 also pointed to the ',' and mailbox-list layout of the problem field.

As for the other two fields (Sender: and X-Envelope-To:), neither are in the headers section. It might help if I clarified that I'm using Mercury's POP3 D connector for retrieval on these accounts, not SMTP.

As for 4.01b, I just noticed the new version of Mercury and I have put upgrading on my todo list. Will the new version install on top of the old and maintain configurations or will it need to be a clean uninstall/reinstall with a manual reconfiguration of all options?

Thanks again for the swift response.

Thank you for the reply. It confirms my suspicions. Perusing RFC2822 also pointed to the ',' and mailbox-list layout of the problem field. &nbsp;As for the other two fields (Sender:&nbsp;and&nbsp;X-Envelope-To:), neither are in the headers section. It might help if I clarified that I'm&nbsp;using Mercury's POP3 D connector for retrieval on these accounts, not SMTP. As for 4.01b, I just noticed the new version of Mercury and I have put upgrading on my todo list.&nbsp;Will the new version install on top of the old and maintain configurations or will it need to be a clean uninstall/reinstall with a manual reconfiguration of all options?&nbsp; Thanks again for the swift response.

Related Topics

Pending draft

Confirm move posts

Insufficient permissions

Select a different topic

Edit history