[SOLVED] Problem with mail from Wordpress

Raise/discuss any potential issues with MailEnable for consideration in project issue register.
Post Reply
Zaph
Posts: 11
Joined: Mon Jan 03, 2011 10:54 am

[SOLVED] Problem with mail from Wordpress

Post by Zaph »

Hi,

on my server I host a Wordpress that send email using PHP's mail function and sets the FROM header to something like "My Name <myemail@mydomain.com>".

The email however does not arrive, and the activity logs show me this. First the email arrives at MailEnable:

Code: Select all

MAIL FROM:<My Name <myemail@mydomain.com>>	250 Requested mail action okay, completed	
after which it tries to send the email to the remote mailserver

Code: Select all

MAIL FROM:<My Name <myemail@mydomain.com> SIZE=698	550 5.1.2 Sender rejected.
Note the missing > at the end of the email address in the second line. Is this a bug, or perhaps a malformed from header?

Thanks!

Zaph
Posts: 11
Joined: Mon Jan 03, 2011 10:54 am

Re: Problem with mail from Wordpress

Post by Zaph »

Hello? Is anybody there?

MailEnable-Ian
Site Admin
Posts: 9738
Joined: Mon Mar 22, 2004 4:44 am
Location: Melbourne, Victoria, Australia

Re: Problem with mail from Wordpress

Post by MailEnable-Ian »

Hi,

My guess is a malformed FROM header. Are you able to edit the PHP application so that it adds the FROM header as: My Name <myemail@mydomain.com> and not <My Name <myemail@mydomain.com>>
Regards,

Ian Margarone
MailEnable Support

Zaph
Posts: 11
Joined: Mon Jan 03, 2011 10:54 am

Re: Problem with mail from Wordpress

Post by Zaph »

As you can see in the first line of my opening post - that's exactly what it does.

Edit: just to be clear - in the activity log all email addresses are enclosed in <>. I guess that's the way MailEnable chooses to display them there. So if we remove those for clarity, the first line in my original post would refer to
My Name <myemail@mydomain.com>
and the second one to
My Name <myemail@mydomain.com

Zaph
Posts: 11
Joined: Mon Jan 03, 2011 10:54 am

Re: Problem with mail from Wordpress

Post by Zaph »

Too bad you don't take this forum as seriously as sending all those "MailEnable Annual Upgrade Protection has Expired" emails...

MailEnable-Ian
Site Admin
Posts: 9738
Joined: Mon Mar 22, 2004 4:44 am
Location: Melbourne, Victoria, Australia

Re: Problem with mail from Wordpress

Post by MailEnable-Ian »

Hi,

We have created an article that you can review which explains the issue you are experiencing:

http://www.mailenable.com/kb/Content/Ar ... D=me020587
Regards,

Ian Margarone
MailEnable Support

Zaph
Posts: 11
Joined: Mon Jan 03, 2011 10:54 am

Re: Problem with mail from Wordpress

Post by Zaph »

A couple of remarks:
- if you look at example 4 in the PHP manual page you linked to, you'll see that the addresses are formatted as friendly and sent without the use of $additional_parameters
- it happens when sending mail from WordPress, which in its default configuration uses the PHP mail() function and fills $additional_parameters with "-oi -f myemail@mydomain.com"
- if you look at my original post you'll see that the email gets processed twice, and that the > at the end disappears in between these two processing runs, which logically suggests that the email itself is fine - otherwise the first processing run would have failed as well

Zaph
Posts: 11
Joined: Mon Jan 03, 2011 10:54 am

Re: Problem with mail from Wordpress

Post by Zaph »

Okay, if you guys insist on simply ignoring this the message you're sending to your customers is very, very clear.

Goodbye.

MailEnable
Site Admin
Posts: 4441
Joined: Tue Jun 25, 2002 3:03 am
Location: Melbourne, Victoria Australia

Re: Problem with mail from Wordpress

Post by MailEnable »

Whilst the forum works well for discussion, its not an ideal place to report and track integration problems like those you mention. Managed responses for specific integration problems/defects/whatever are best dealt with by the support ticketing system. The issue you are having seems to be very specific to wordpress integration /php mailer scripts. In this instance, the SMTP client application (wordpress/php mailer) is sending a malformed command to MailEnable, and ideally the mailer should be patched/adjusted to prevent this (it is perhaps skewed to talking to a particular mail server rather than following the RFC).

http://www.ietf.org/rfc/rfc2821.txt (search for "3.3 Mail Transactions")

For clarify, MailEnable displays the MAIL FROM command exactly as it receives it... so it actually received it like this:
MAIL FROM:<My Name <myemail@mydomain.com>>
In terms of any MailEnable, it *could* perhaps reject the invalid SMTP transaction at the connector rather than relaying it and relying on the downstream mail server to do so (but the internet standard does not say to do this - and its possible that doing so could break other applications). Even if MailEnable did do this, it is not likely to fix the actual problem - since thie problem is a shortcoming in the php mailer - or irs configuration in specifying additional parameters.

But the better solution is to determine if there is an updated/fixed mailer script, or if you can pass the additional parameters to it. I vaguely to recall this being a problem with some older forum software that relied on a sendmail php script (and that there was a patch available - or perhaps it was solved using the additional parameters mentioned in the article).
Regards, Andrew

Zaph
Posts: 11
Joined: Mon Jan 03, 2011 10:54 am

Re: Problem with mail from Wordpress

Post by Zaph »

Whilst the forum works well for discussion, its not an ideal place to report and track integration problems like those you mention. Managed responses for specific integration problems/defects/whatever are best dealt with by the support ticketing system.
I didn't know that, and it would have been nice if someone had told me that from the start. When I saw a forum called "Error resports and issues" I assumed it was meant for error reports and issues. It doesn't change the fact that my posts aren't being read very well, or that the response terribly slow.

I just tried these commands.

Code: Select all

1: mail("someone@remotedomain.com", "Mailenable test", "So...did you get this?", "From: Mailenable Test <me@mydomain.com>", "-fme@mydomain.com");
2: mail("someone@remotedomain.com", "Mailenable test", "So...did you get this?", "From: Mailenable Test <me@mydomain.com>", "-f me@mydomain.com");
3: mail("someone@remotedomain.com", "Mailenable test", "So...did you get this?", "From: Mailenable Test <me@mydomain.com>\n", "-fme@mydomain.com");
4: mail("someone@remotedomain.com", "Mailenable test", "So...did you get this?", "From: Mailenable Test <me@mydomain.com>\n", "-f me@mydomain.com");
5: mail("someone@remotedomain.com", "Mailenable test", "So...did you get this?", "From: Mailenable Test <me@mydomain.com>\r\n", "-fme@mydomain.com");
6: mail("someone@remotedomain.com", "Mailenable test", "So...did you get this?", "From: Mailenable Test <me@mydomain.com>\r\n", "-f me@mydomain.com");
7: mail("someone@remotedomain.com", "Mailenable test", "So...did you get this?", "From: me@mydomain.com", "-f me@mydomain.com");
8: mail("someone@remotedomain.com", "Mailenable test", "So...did you get this?", "From: me@mydomain.com");
Of these, only the last 2 worked, the first 6 displayed exactly the same problem as my original post. Note how the extra parameter is used, and how the From header is 100% conform the specifications listed in the PHP mail() function you linked to in your KB article, and the thousands of examples found all over the internet forums. If you feel I made an error in those tests, I'd be very happy to hear about it.

Quoting RFC 2821:
The first step in the procedure is the MAIL command.

MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>

This command tells the SMTP-receiver that a new mail transaction is
starting and to reset all its state tables and buffers, including any
recipients or mail data. The <reverse-path> portion of the first or
only argument contains the source mailbox (between "<" and ">"
brackets), which can be used to report errors (see section 4.2 for a
discussion of error reporting).
Here, 'reverse-path' is the email address from the From-header, which is enclosed in <> by the mailserver to conform to this specification. So, to determine what is actually being sent to the mailserver we should leave these out of the log messages. Which leads us, once again, to the conclusion that MailEnable correctly receives the literal "Mailenable Test <me@mydomain.com>", which is being logged in the first pass. In the second pass, however, the closing ">" is missing.

Some further testing reveals that if I look at the From-header, and enclose it in "<>", everything after the first > is being stripped. Using "Mailenable Test <me@mydomain.com>>", which should theoretically lead to a MAIL FROM containing "<Mailenable Test <me@mydomain.com>>>", gives me the same results as tests 1 through 6 above:
Pass 1: MAIL FROM:<Mailenable Test <me@mydomain.com>>> 250 Requested mail action okay, completed
Pass 2: MAIL FROM:<Mailenable Test <me@mydomain.com> 550 5.1.2 Sender rejected.

Please correct me if I'm wrong, but to me this leads to the conclusion that the missing > at the end is caused by MailEnable incorrectly formatting the From header - it does not simply enclose the header in <>, but also, after doing that, cuts the result off after the first >. I have honestly no idea how I could possibly circumvent that.

MailEnable
Site Admin
Posts: 4441
Joined: Tue Jun 25, 2002 3:03 am
Location: Melbourne, Victoria Australia

Re: Problem with mail from Wordpress

Post by MailEnable »

I think your interpretation of what is occuring is not correct.

This is exactly what is occuring (at least from the perspective of the MailEnable server):

1. MailEnable is receiving this from the PHP Mailer: "MAIL FROM:<Mailenable Test <me@mydomain.com>>>".

2. MailEnable parses the address from that (in accordance with the RFC) to strip out the e-mail address portion (enclosed between angle braces).
As such, it gets this: "<Mailenable Test <me@mydomain.com>" as the reverse-path address (note the missing trailing angle bracket).
The client should NOT be sending it in that format - and that is the cause of the problem. It should be sending the mail from like this:

MAIL FROM: <mailbox>
or
MAIL FROM: "Alias" <mailbox>
or
MAIL FROM: User <mailbox>

(I think the rfc suggests a preference for the first example - but any of them will do)

MailEnable reports a success for the MAIL FROM command - and sends back a "250 Requested mail action okay, completed" (even though the return-path address is not valid).
It possibly should better check the validity of the return-path and return back an error, but even if it did, it would not help solve the issue.

Note: the "Second Pass" you refer to is the relay attempt to the remote mail server - ie: the SMTP-OU (outbound transaction). In this case, MailEnable is actually attempting to send the message to the remote recipient.
It does this using the FROM address provided by the client in the SMTP Inbound transaction - which was parsed out as : "<Mailenable Test <me@mydomain.com>"

The downstream mail server rejects it - because it is now even more malformed that the smtp inbound transaction MAIL FROM passed to MailEnable.

+++++++++

Now, with respect to the root cause of the problem, there are only two ways this can be fixed.

1. The PHP mailer script (or params) should be modified to prevent this from occuring (the thread indicates that we have been doing our best to provide assistance in this respect - it is somewhat out of our core area of expertise though - because it is not developed by MailEnable) - more on that later though.

2. MailEnable could be modified to interpret the malformed address differently and parse out the e-mail portion of the address in situations where a mailer is sending the double wrapped angle brackets (*again this is not what the RFC deems to be appropriate).

With respect to making the script RFC conformant, it would need to be determined how to stop the mailer from to send MAIL FROM: command string without double wrapping the address in an extra set of angle braces.
Again though, it is the mailer that is adding the extra angle braces. If you dont believe the mailenable logs, then a packet sniffer will show you this.
The php mailer doc suggests that if the return path parameter is not specified, the mailer will attempt to parse the return-path address from the headers.
It seems that that approach is not working and the parser is adding additional angle braces - possibly because the address includes the displayname rather than just being address@domain.
(This is reinforced by the tests you performed)

A workaround suggested is to pass the return-path address to the mailer, so it does not attempt to parse the address from the message headers. ie: to ensure that it gets it right.
ie: According to the PHP Mail docs, this command should set the mail from address used in the envelope transaction ie: MAIL FROM

mail("someone@remotedomain.com", "Mailenable test", "So...did you get this?", "From: MailEnable Test me@mydomain.com", "-f me@mydomain.com");

It seems from your tests that the -f parameter is not working (there is an indication that the -f param is not guaranteed to work on all installations of the mailer.

In terms of accomodating the problem, a registry option could be added to mailenable to make it accept and parse invalid recipient addresses.
That is a B-Grade solution however, since the server REALLY should not need to be modified to handle the lameness of a client mailer though. I will ask whats involved in this respect (I would guess that sendmail servers handle the erroneous double angle brackets).
Regards, Andrew

Zaph
Posts: 11
Joined: Mon Jan 03, 2011 10:54 am

Re: Problem with mail from Wordpress

Post by Zaph »

Hello Andrew,

thanks for your lengthy response. It helped me understand where I made an error - I though the first logged message was originating in ME as well. Also my apologies for being so cocky - I was honestly convinced ME was doing something wrong

As an addition to the KB article (which in it's current form is not correct, since it describes exactly what I was doing, and still with no result):
Older versions of PHP will not handle these headers correctly. This can be solved by using the $additional_parameters as follows:

Code: Select all

mail("someone@remotedomain.com", "Mailenable test", "So...did you get this?", "From: Mailenable Test <me@mydomain.com>", "-F");
The -F parameter tells the mail() function that it should look for a display name, and adjust the handling of the header accordingly.

Thanks again!

Peter

Post Reply