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).