[quote user="olic"]
Here is the lines sent by the old program which Mercury don't like :
MAIL FROM:artemis@serv1.sim[/quote]
RCPT TO:olivier@serv1.sim
There was a time when Mercury would have accepted these addresses, in the spirit of "Be tolerant in what you accept and strict in what you send", but the advent of open relay testers and spambots meant that I had to change that policy to one of being much stricter about what I will and will not allow. There are also complications introduced by certain ESMTP extensions to the MAIL FROM: command that force me to be more stringent about syntax.
The only suggestion I can offer is the same as Thomas's - that you try entering the address in the old program with the < and > characters already in place. The address is still legal in all cases where a compliant RFC2822 parser would be reading it, and it will work around the problem. Of course, if the string is hardwired or there's some other reason why you can't change it, then I'm afraid you have a bit of a problem.
Cheers!
-- David --
[quote user="olic"]<p>Here is the lines sent by the old program which Mercury don't like :</p><pre wrap="">MAIL <a href="mailto:FROM:artemis@mail.ville.montreal.qc.ca" mce_href="mailto:FROM:artemis@mail.ville.montreal.qc.ca" class="moz-txt-link-abbreviated">FROM:artemis@serv1.sim</a>
RCPT <a href="mailto:TO:olivier@oliserv.net" mce_href="mailto:TO:olivier@oliserv.net" class="moz-txt-link-abbreviated">TO:olivier@serv1.sim</a></pre>[/quote]
There was a time when Mercury would have accepted these addresses, in the spirit of "Be tolerant in what you accept and strict in what you send", but the advent of open relay testers and spambots meant that I had to change that policy to one of being much stricter about what I will and will not allow. There are also complications introduced by certain ESMTP extensions to the MAIL FROM: command that force me to be more stringent about syntax.
The only suggestion I can offer is the same as Thomas's - that you try entering the address in the old program with the &lt; and &gt; characters already in place. The address is still legal in all cases where a compliant RFC2822 parser would be reading it, and it will work around the problem. Of course, if the string is hardwired or there's some other reason why you can't change it, then I'm afraid you have a bit of a problem.
Cheers!
-- David --