The strange case of the repeating domain name.

[hkphooey]

Is this some kind of competition to see who can reply quickest? OK here we go...

Code: Select all

[root@mail ~]# grep -i smtp /var/opt/scalix/ml/webmail/swa.properties
swa.email.smtpServer=mail.mydomain.com
swa.debug.listOfUsersToLogSmtp=
[root@mail ~]# lsof -i :24
[root@mail ~]# lsof -i :25
COMMAND    PID USER   FD   TYPE  DEVICE SIZE NODE NAME
omsmtpd  19596 root    4u  IPv4 8338316       TCP mail.mydomain.com:smtp (LISTEN)
sendmail 26846 root    4u  IPv4 6650696       TCP localhost.localdomain:smtp (LISTEN)
[root@mail ~]# lsof -i :465
[root@mail ~]# lsof -i :587


[/code]

[florian]

ok, that looks as expected...

what does your

/var/opt/scalix/??/s/sys/unix.mapper

file look like?

Florian.

[hkphooey]

Contains only one line:

Code: Select all

transport-service = inet:localhost:25


[florian]

ok, now finally, if you ping "myhost.mydomain.com" - does it go to 127.0.0.1 or your official IP address? If the latter, than actually the message must be flowing through the Scalix system from SWA, no matter what the recipient is.

It should be

SWA --> SMTP --> Port25/hostname --> omsmtpd --> unix.in --> service.router --> unix.out --> SMTP --> Port 25/localhost --> sendmail --> RestOfWorld

The tcpdump idea should capture traffic on the Port25/localhost part of the journey.

Now, you can capture traffic on the Port25/hostname journey also through tcpdump or by setting up DEBUG_LOG=TRUE at the beginning of the file in smtpd.cfg and restarting the SMTP relay. Output will be in s/tmp/smtpd.log or so. similarly, you can see how the message progresses through the system by setting an audit level of 9 for internet gateway (that would cover unix.in, unix.out), for service router (that would cover the latter) and local delivery (this would be for local recipients as an alternate route out of the service router). Note that after changing the audit level (with omconfaud/omshowaud) for any of the components, you would need to restart the component using the omoff/omon commands!

OK, that's strong stuff. still i'd like to see how scalix talks to sendmail and if it doesn't get there, we should probably find out where those messages go.......

hm....

Florian.

[florian]

by the way, everything you've reported back so far looks perfectly normal!

Florian.

[hkphooey]

ok, now finally, if you ping "myhost.mydomain.com" - does it go to 127.0.0.1 or your official IP address? If the latter, than actually the message must be flowing through the Scalix system from SWA, no matter what the recipient is.

ping mail.mydomain.com goes to the external, public IP address. mail.mydomain.com is the hostname reported by "hostname" and "hostname -f" . Additionally, ping mydomain.com doesn't resolve to anything (which is correct from my point of view as there is no server there) but could this have an effect on the mail traffic?

SWA --> SMTP --> Port25/hostname --> omsmtpd --> unix.in --> service.router --> unix.out --> SMTP --> Port 25/localhost --> sendmail --> RestOfWorld
The tcpdump idea should capture traffic on the Port25/localhost part of the journey.

So from my answers above, it seems that emails from SWA to the rest of the world behave OK, but if they're forwarded using a rule, then they don't travel this path.

Now, you can capture traffic on the Port25/hostname journey also through tcpdump or by setting up DEBUG_LOG=TRUE at the beginning of the file in smtpd.cfg and restarting the SMTP relay.

Last time I did this I waited 12 hours for a repeat occurrence of this X, and ended up trying to wade through 20 Mb of logfile. Needless to say, everything behaved perfectly during this period.

similarly, you can see how the message progresses through the system by setting an audit level of 9 for internet gateway (with omconfaud/omshowaud)

This is a new approach to me. I'll try it and let you know.

[florian]

on the rules thing... well when you forward stuff by rule, what happens is that the incoming messages passes on through the service.router, then on to local.delivery. local delivery processes the rule, will create a new message with the forward recipient as the recipient and feed this into the service routers incoming queue. if the recipient is external, service router would then forward this on to unix.out and on to sendmail, so it should actually be visible through these stages as well!

Florian.

[hkphooey]

OK, well I thought I'd post a resolution to this problem, although its not a nice one. Basically I tried to track these problems down for a few months, and in the end I decided the only way to deal with it was to start fresh. I got a new server and reinstalled everything from scratch, using Centos 5 and the latest Scalix, copied the mail stores over, imported them and ... pretty much no change.

Then after a few more weeks, the problem stopped. My reading of the situation is that the problem was firmly with the blackberry mail servers. They were rejecting the mail from my server, which I think could have been due to two things:

a) They had just installed new IronPort antispam filters. I think they had probably got these turned up too aggressively and then they relaxed them recently in response to what I imagine were a lot of complaints.
b) My hosting company admitted to having some of their IPs on a blacklist, although not the ones I was operating from. Perhaps the whole netblock had been blacklisted somewhere in the blackberry empire.

So a pretty disappointing outcome. I fought with the local ISP for several months on this (blackberry won't deal with mail server admins directly, so I had to go through them). Needless to say I was stonewalled pretty effectively, but I like to think my complaints eventually triggered some action.

The repeating domain problem -- the initial impetus for this thread -- that problem seemed to disappear after a month. I'm not sure if that was due to the config changes I made for Spamassassin, or whether that was due to blackberry nonsense as well.

Ultimately everything is running smoothly again, and its now a joy, rather than a dread, to get my Logwatch logs again every day.