Topic: Remote host said: 553 malformed address: <<>>

[Luis]

Hi!..

I Have a SME 6.01 with SpamAssassin and Clamav installed by script from http://sme.swerts-knudsen.dk/

I configure some account to "forward only" to internal Ms Exchange Server.

On this account, all is ok with "normal" email but when recieve a NDR o mail form "MAILER-DAEMON" with a notification of delay/error delivery and SME try to fordward this message to Exchange server, the IMC(internet mail conector) of exchange REJECT the email with the error on Subject.

I try a regitry hack on Exchange like comented on Q191262 to accept malformed addres but can't obtain a solutions.

I look on email REJECT and this include a top of header a line like this:

Return-Path: <"<>">

my questions are..

what is a qmail script with forward this email?

Why qmail modify header only in this type of message?

Any body know a workaround?

Thank in advance!.. and sorry by my english 8(..

[thowden]

Hi

We have just reconfigured a server with 6.0.1 and have it set to pass all mail through to an exchange server in a similar config to Luis.

The pagefault.org clam setup has been done and appears to be working well for catching viruses etc.
However we have the same issue with emails being caught into the problem queue with blank to and from addresses.

The exchange server logs show messages in this state as well. What I cannot work out is if the message is originating as an error in the e-smith box or at the exchange server.

Any help appreciated.

cheers
Tony


http://www.marblebay.com.au

[NickR]

FWIW, I have seen this also, but there is no exchange server involved.  In my case, the user is running Outlook 2000 and every received email marked as "notify when read" causes this error when the notification is sent..  Other than that, it works perfectly, so I'm not too bothered about it.

I have a feeling that Outlook is responsible & is trying to insert a nul return path in the envelope header, but gets it wrong: <<>> should be <>

[thowden]

Hi

Thanks for the reply. There is certainly a possibility that its the client, although there appears to be an issue in the server as well.

I realised late this afternoon that I had setup the server as I normally do as 'server.domain.local' and then added the live domain name as a virtual domain. Part of the problem was then self-inflicted as I initiated the 'use internal mail server' option. This meant that any mail generated by the sme server to a domain.local address was also passed to the exchange server and was then rejected and bounced back to the sme server in a growing loop of emails.

That said, the interesting issue was that each of these emails started with a 'To' address from the sme server, but (at least appeared to) arrived at the exchange queue as <> which was then passed back as malformed 553.

Now I am trying to work out the sequence of processing of the mail and where the addresses are being 'nulled'.

We'll test alternate mail clients tomorrow, but it also appears that email addresses are being converted from first.last to first_last in the processing. I don't have any accounts on the sme server, but we also do not have any processing of email addresses in that format on the exchange box.

I am suspicious that clam or spamassassin or smtpfront or something on the sme server is incorrectly making assumptions about email addresses and as a result subsituting what might be a valid sme pseudonym instead of the valid internal email address.

Can anybody shed some light on this it was only after adding clam and spamassassin about 2 months ago that email went pear-shaped. It's taken us this long to work out that email receipts were failing, and that some emails were looping out between the servers.

cheers
Tony



http://www.marblebay.com.au

[NickR]

Can anybody shed some light on this it was only after adding clam and spamassassin about 2 months ago that email went pear-shaped. It's taken us this long to work out that email receipts were failing, and that some emails were looping out between the servers.

I don't use spamassassin at all, but ClamAV is installed everywhere.  On the 10 SME's I admin, only one site has this problem & only one client (Outlook 2000).  Everywhere else uses Pegasus Mail & has never had a problem of this sort.  Oh, one site uses Outlook 2002 exclusively, but again, no problems there.

I suspect you will need to try controlled tests via a telnet session to really see what is going on - good luck.

[thowden]

Hi Nick

Thanks for the reply. You have 10 SME's installed are any/all running as gateways to exchange ?

I have about 15 sme's running with two acting as mail gateways and only one as a gateway to exchange. All the stand-alones work as expected, its just the gateway to exchange that is an issue and I dont have enough of them to compare.

Anyone else got a working sme as a gateway to exchange ?

Spec:  SME 6.0.1 with clamav from pagefault.org and exchange 5.5 on a w2k box behind it.

[NickR]

Hi Nick

Thanks for the reply. You have 10 SME's installed are any/all running as gateways to exchange ?

Nope, they all act as the primary mailserver.  As I said some messages back, I have only one site that I've seen this 553 error from & that was caused by an automatic "read notification" being sent by Outlook 2000.  The 553 was returned from Sendmail 8.9.3 at the ISP, so no exchange involved at all.

I offer this as merely a clue as to where the problem may lie.  Based on evidence presented so far, I think we can eliminate the SME, ClamAV & non-MS MUA's (although Outlook 2002 hasn't thrown up the problem at the one site I have that uses it).

[thowden]

Hi

Thanks for the feedback Nick. We have this morning installed Thunderbird email client from Mozilla with exactly the same results.

I'll just try to clarify what I think is happening now that I have a fresh head at 0830 <g>

We have established that there are two issues.

#1. Qmail is responsible for the <<>> 'nulled' addresses. This is apparently a qmail thing with dealing with doublebounce email messages. It will process them and to avoid (supposedly) sending the message any further it strips the addresses. Having said that I have not read this from a qmail manual directly but as hearsay from a forum. I'll pursue this further for confirmation. The issue is that the emails are still being processed to the exchange server and to the administrators email account. Now that we know what they are, seeing these emails in the admin list is not a major hassle, just annoying.

#2. More importantly there is an issue with read receipts not being processed. This appears to be an issue with exchange and outlook as I can successfully process receipts using thunderbird client at each end. Outlook or exchange with outlook will not process a read receipt unless its done within the lan. For this client the read receipts are important for their work. I am told that changing exchange to send in RTF format may fix the issue, but thats a discussion for a different forum.

[thowden]

Hi All

More research and testing reveals that if we process manually via a telnet session we can generate <> or <"<>"> in the return-path depending on the server we use. What I am now trying to verify is what the differences are. I am looking at the clam-av install as being a major difference between two test servers I am using.

Can anyone with a 6.0.1 install with or without clamav help me verify where this is occurring.

If you are at your sme servers console (or via a putty session)

#telnet localhost 25
then at the prompt

Code: [Select]


mail from: <>              //enter
rcpt to: admin@localhost   //enter
data                       //enter
testing or some text       //enter
.                          //enter
quit                       //enter

then check the message in your admin mail and look at the headers.

Return-path will either be equal to <> or be equal to <"<>">  and what I need to know is what results you get and if you have clamav on your server (particularly) if you get the second result.

TIA

[NickR]

Return-path will either be equal to <> or be equal to <"<>">  and what I need to know is what results you get and if you have clamav on your server (particularly) if you get the second result.

TIA

Return-Path: <"<>">

Clam-av is installed. Do I deduce that this is the main suspect now?

As an interesting asside, I also tried this on a server that forwards admin mail to me on another server which is running ASSP - ASSP simply swallows the mail - no message, error or anything!  The sending server believes the mail was delivered sucessfully.

[thowden]

Hi

The culprit appears to be amavis-ng but that is as far as I have got. Seems that using a different fork of amvis is ok according to another source of mine. Clam apparently is not responsible for this on its own. However that is according to the clam-users mail list.

I do need some more feedback on this particularly from users with and without the clamav installs from jesper and damien. I have tried with both of the clam installs with the same results.

[thowden]

Hi All

After much searching I've found the cause and resolution. It is Amavis that does this.

Amavis when managing emails where the Return-path is null or <> processes this as a null and then returns the address as <"<>"> which is invalid to other MTA's like Exchange.

To fix this use your favourite editor (mine is mcedit):

mcedit /usr/lib/perl5/site_perl/5.6.1/AMAVIS/MTA/Qmail.pm

and locate line 135 which should read

Code: [Select]


    $$args{'sender'}='<>';

change this to remove the <>

Code: [Select]


    $$args{'sender'}='';

Note that this is two single ' quotes with nothing between them, not a double quote mark.

Save your file.

This should work instantly, no need to reset the server or anything.

[lpeg]

HI!.. thank for all. I am Luis, the writter of original message of this Thread.

I Try this hack and make comments about result.

Thanks again...

[kmac]

Tony,
Thanks for the tip. I have also been having this same problem. I have edited this file and will also advise back on results.
Thanks again.