Hello,

I have moved a new customer to my DA / FreeBSD 5.3 Box recently.

The customer has a point of sale system that uses email to communicate with other remote POS systems at other stores.

Their system, sends emails out with the addresses in the 'to' field like this:

Code:
<[email protected]>;<[email protected]>
Exim knocks this back with:

Code:
2005-11-21 12:17:03 1Ee0Ik-000KsD-MV H=x.x.x.x (STATION104A) [x.x.x.x] F=<[email protected]> rejected after DATA: malformed address: ;<[email protected]> may not follow <[email protected]>: failing address in "CC" header is: <[email protected]>;<[email protected]>;<[email protected]>
I've emailed the author of this POS software & thir response was:

We are going to have a look at this in our code, as you are correct that we separate this by using a semi-colon. However, and equally not pointing blame, RMMS has used this same code for 5 years (and 700 users on all sorts of different mail servers) without any dramas at all (which is why we were scratching our heads a little bit when Ant raised it...). Anyway, if you go into Outlook Express and send an email to an cc it to multiple addresses, OE also uses a semi-colon to separate the addresses, and we all know how standard-concious Microsoft is....
When I sent an email using Outlook, although outlook shows the emails as being seperated by semi-colons, the log file shows them as being seperated by spaces.

Can I change exim to allow this?

I have tried commenting out:
Code:
 require verify = header_syntax
which didn't help.

I also tried commenting out the system filter, which also did not help. That being said, I don't think I am looking in the right place, because neither exim.conf or the system filter file have the error message "malformed address"

Can anybody suggest what I can do to overcome this issue?

I've suggested to the author that their software is not following the rules, but their counter response was that 1000's of people use this software with 1000's of hosts, and they have never encounted the issue at all.