Mailing List Message #100473
From: Bill Cole <>
Subject: Re: SMPTI log tags not tracking unauthorized relaying
Date: Mon, 26 Jul 2010 12:50:45 -0400
To: CommuniGate Pro Discussions <>
W Sanders wrote, On 7/25/10 2:44 PM:

We are seeing some suspicious activity in our log files. A few external
IP addresses are connecting to our SMTP relay service without
authenticating. The problem is that incoming SMTP relay is closed except
to authenticated users.

I am trying to find the origin of the SMPTI connection by grepping the
log files. One example:

# grep SMTPI-63782 2010-07-2[345].log
2010-07-25.log:06:28:13.11 2 SMTPI-63782([]) [134381327]
received, 68157 bytes

Another example:

# grep 2010-07-22.log
09:53:57.24 2 SMTPI-91478([]) [134316328] received, 2344
09:53:57.50 3 SMTPI-91478([]) read failed. Error
Code=connection reset by peer
10:10:36.74 1 SMTPI-92192([]) Recipient rejected: prohibited. We do not relay

You do see that there are two completely distinct inbound SMTP sessions there, right? SMTPI-91478 shows acceptance then the client dropping the connection, SMTPI-92192 shows a rejection.

In both examples, spam was successfully sent to one of our users (the
first one had a Mydoom virus attached, but our filters caught it.) This
is very odd, because normally I see the SMTPI connection and
disconnection as part of the log if authentication is successful

The word "relay" is not normally used to refer to acceptance of mail for local users. "Relay" usually is defined as transporting mail that arrives via SMTP outbound via SMTP. You seem to be saying here that you don't want to accept any mail for your own users unless the inbound SMTP session is authenticated or from a trusted system. That sort of configuration would be useless for a system that is expected to act as a world-facing mail exchanger (i.e. that has a MX record pointing at it) but it would be reasonable for a host with some other SMTP relay between it and the Internet at large.

# grep SMTPI-68328 2010-07-25.log
10:21:41.38 2 SMTPI-68328([]) ''
connected from []
10:21:41.38 2 SMTPI-68328([]) ''
disconnected ([])
10:21:41.63 2 SMTPI-68328([]) [134383478] received
encrypted, 722 bytes

Normally, anyone not coming from one of our "internal" IP addresses to
ports 25 or 587 should hang, except for users who have authenticated via
POP, IMP, HTTP, etc, who are allowed to connect using the "temporary
client" feature.

If you have some other system acting as your MX and relaying mail in to your CGP system, then you should not need to allow port 25 at all from anywhere else. You could either restrict the port 25 listener in CGP or firewall it externally. I am not aware of any way to make CGP require authentication on port 25 for messages addressed to local users.

Somehow these IPs authenticated, or were allowed to relay without
authentication - but I see no other log entries for them. Authentication
attempts via all protocols - POP. IMAP, HTTP, etc are logged.

Repeating myself to make sure I'm being clear: mail delivery to local users is not relay, CGP's relay controls do not apply to it, and I know of no way to make CGP require SMTP authentication as a condition of local delivery.

So, those IP's did not authenticate, nor were they allowed to relay. They offered mail for local delivery which was accepted and delivered.

Does anyone have any tips on why the SMPTI would not log the connection
and disconnections, or the authentications? Perhaps these are
authenticating via some other service? I am baffled....

You have to do "Low Level" logging in CGP to capture actual connection events. The level 2 connected/disconnected events you see logged by the SMTPI module are really for a logical authenticated session inside the SMTP session, not the actual TCP-level session. You don't see anything logged because there is no authentication being done and you are apparently only logging at level 3 ("Problems").
Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster