Scalix Forums

This is an odd one. I installed spamassassin a couple of days ago, and since then I've been seeing some odd error messages in my /var/log/maillog. Here's one example



It appears something is repeating the domain name so that jack@maildomain.com becomes jack@maildomain.com.maildomain.com. The message is then rejected and sent back to root as Returned mail.

I've checked out a few configuration files but can't really find anything I can explain this behaviour with. I'm assuming its something to do with the interaction of smtpd and sendmail. Are there any sendmail experts out there who have seen this thing before?

Jim

I haven't managed to track this one down yet, and now I'm seeing something even stranger -- emails to external domains are now having the local domain address appended to them and consequently can't be delivered. i.e. when someone at the scalix server at mydomain.com sends an email peter@example.com, I'm getting errors like the following in my maillog.

MX list for example.com.mydomain.com. points back to mail.mydomain.com: 1 Time(s)

Obviously this isn't happening all the time, and I can't figure out the circumstances under which it is occuring. However even if it is happening 5% of the time, this is not acceptable.

Anyone have any ideas before I get rid of spamassassin and roll back to the previous configuration?

As I understand it, without spam assassin, scalix uses its own smtpd to deliver mail. Once you install spamassassin, scalix passes mail to sendmail, which passes it to spamass-milter, which passes it to spamassassin before it is delivered. Is this correct?

Maybe if I can remove spam filtering on the outbound traffic, and only let it run on the incoming traffic, that will solve the problem. Clutching at straws here a little ...

this seems like a DNS issue. most likely one of your dns-records is not properly "."-terminated in your dns config file, so that the zone name is appended.

the exact way to troubleshoot this would be to check out the dns server config files for mycompany.com and the respective reverse-lookup domain.

cheers,
Florian.

What entries (if any) are in /etc/mail/local-host-names.

It's possible for sendmail to rewrite the sender headers. Are you aware of this being turned on?

Kev.

kanderson wrote:What entries (if any) are in /etc/mail/local-host-names.

Just mydomain.com
The fqdn of the server is mail.mydomain.com, and this is correct in the /etc/hosts file.

kanderson wrote:It's possible for sendmail to rewrite the sender headers. Are you aware of this being turned on?.

Not unless the spamassassin installation turned it on. How would I check this? Is it in the sendmail.mc file?

florian wrote:this seems like a DNS issue. most likely one of your dns-records is not properly "."-terminated in your dns config file, so that the zone name is appended.

This is something that suddenly started happening about a week ago, and nothing has changed in the DNS record for over 6 months.

In addition its only happening to some emails, not all of them. Most odd.

I've removed spamassassin, and have removed the offending emails from the sendmail queue. Lets see what happens.

OK, so I rolled back the configuration a few days ago. Returned sendmail.mc to its original state, and removed the Relay line from smptd.cfg. Restarted sendmail and smtpd.

But its still happening. The domain of the mailserver is being appended to some emails (around 3-5%) and they are not delivered. This happens seemingly at random to both internal and external emails. I can't replicate it at will, yet it happens several times each day. Very frustrating.

There are a few other problems which started happening simultaneously. I didn't mention them earlier as I didn't want to confuse the issue, but I might as well throw them into the fray now. I'm getting the following errors in logwatch. Once again they started happening as soon as I installed spamassassin, and didn't disappear when I rolled back the configuration.

All these errors seem to happen to blackberry related addresses: a couple of the guys have their email forwarding to their blackberry. I'm not sure if its related to the repeating domain problem, but its just as irritating.

This is still happening, but now I have some more information.

I sent out a broadcast message to a group. There are 10 people on the distribution list. 7 of them are on the local domain eg joe@mydomain.com, so they all receive email in their Scalix inboxes. Three of the people have their email forwarded to their blackberries. This is set up using the sxaa --redirect --retain command. The email appears in their Scalix mailboxes, and in two of the three cases is delivered externally OK. In one case, however, the relay server address is changed to append the local domain, mydomain.com, and the email is understandably undeliverable. Here's the log entry



I really can't understand it. In the first case the relay server is altered so that it sends the mail to the wrong place. In the other two cases, everything is fine. I've checked and re-checked the rules in sxaa. The only difference I can see is that the first email address contains numbers, while the other two contain letters or letters and numbers before the @ sign. Could this make a difference?

Any suggestions on where to look would be gratefully accepted. I'm not a sendmail guru and don't really know where these things are hidden.

Once again, this started happening shortly after I tried to install spamassassin. I'm not sure if its related to that. I have now rolled back to the pre-spamassassin configuration and its still happening. Going slowly nuts with this one ...

well, the key line seems to be



It selects a "constructed" hostname as the next-hop relay for this address.

can you try "mail 12348888@csl.ap.blackberry.net" from the command line? if it happens for that as well, then we'd know for sure at least that it happens within sendmail.

Florian.

Fast reply! ... and far too late on a Sunday night in Europe ...

OK, so yes, sending mail from the command line seems to work. Finds the right relay address. No problems:



If I could find a pattern, then it would be easier to troubleshoot, but it just seems so random.

well, i'm in san francisco and working on something else anyway, so it's not THAT bad!

hm. i'd actually like to see the SMTP dialog that happens between Scalix and sendmail.

Are you familiar with tcpdump and wireshark/Ethereal?

You should be capturing the SMTP conversation that goes on when the redirect happens. this will be between unix.out and sendmail on port 25/TCP, i.e. for tcpdump and the raw capture i would be starting something like:



(or if running wireshark on linux, do it directly in there)

If not running wireshark directly, i'd then load this file into my windows-wireshark and then look for an SMTP packet, right click on it and follow conversation (or however that option is called). This should provide a cleartext SMTP conversation, bidrectional. I

I'd like to see that.... obviously for a failed one.

Florian.

tcpdump, no problem. Thanks for the pointer.

I'll email a copy to your private email address (firstname at scalix dot com, right?) so that I don't have to try to hide all the real email addresses!

correct... if we find out what's going on here, I'll stil ask you to post summary or data with private information removed, so that everybody else knows what's going on. too valuable to be hidden.

Florian.

OK, that didn't work as expected ...

First of all I sent myself an email to my personal address from SWA. No problems. I received the email and the transaction appeared in the tcpdump file. A corresponding entry was found in /var/log/maillog.

However, when I sent an email from SWA to the group (ten internal users, three of which were additionally forwarded out to blackberries), the mail goes out, and appears in /var/log/maillog, but not in the tcpdump pcap file. Maybe this is because the emails are redirected/forwarded rather than sent direct? My knowledge of scalix/sendmail isn't good enough to answer this question myself.

In addition, the email address that failed this time was not the same as the one in the previous instance. This time it chooses a different blackberry user to reject, still sending two and rejecting one. Total insanity ...

OK, getting closer...

what do you see when you



and what do you see for



Cheers,
Florian.