I have every intention of sharing both the message tracking system AND
the failure detection scripts once I've completed (to a certain degree)
debugging them.
Dan
IT4SOHO
On 2/16/2014 2:04 PM, LHTek wrote:
Could you please share your script for detecting failed massages with
us? It sounds like a good stop-gap treatment for this insidious issue.
------------------------------------------------------------------------
*From:* Dan McAllister <q...@it4soho.com>
*To:* qmailtoaster-list@qmailtoaster.com
*Sent:* Sunday, February 16, 2014 12:33 PM
*Subject:* Re: [qmailtoaster] Re: Spamming via valid vpopmail account
Wicus' issues are not uncommon:
An "attacker" gains a password (through guesswork or other means)
of a
user on your system, then proceeds to spam the hell out of the world
from your system.
Alternatively, some user gets a malware infection on their system
that
uses their mail program (usually Outlook) to spam the hell out of the
world from your system.
So how can you head it off?
I am in the finishing stages of writing a script that, if I am not
mistaken, will be obsoleted rather quickly.
This script is designed to look through the send log file and
essentially build a "message log" for each message:
- who its from
- who its addressed to
- results of each send
- when it is done (final act of removing it from the queue)
The "sticky wicket" in this is that qmail uses the inode number of
the
message body in the queue as the tracking ID, thus the same numbers
appear over and over. This is what breaks all other attempts to do
this
that I have encountered, and this is the biggest stumbling block
that I
can see so far.
I hope to have this completed in the coming week or 2.
How this applies, it that I already have a script that attempts
(albeit
with many instances missed currently) to count the number of failed
messages from any single user in any given day. When that number
reaches
50, I automatically change the password on the user account (thus,
stopping their authentication) until I can investigate further.
So that will help with DETECTION -- what about deterrence?
Well, for one -- and I've talked about this before -- you can stop
allowing users to AUTHENTICATE on port 25. Port 25 SHOULD be used
SOLELY
for inbound messages to your hosted (or relayed) domains. Thus,
when you
ran your telnet attempt and used a destination of a gmail address,
your
server should have (and did) refused the message.
The problem is that we enable authentication on port 25 because we
seem
to think we should be running the same code for submission (port 587)
and smtp-ssl (port 465). IMHO, THOSE ports should be the OPPOSITE of
port 25:
- Port 25 should allow anonymous connections (non authenticated)...
ports 587 and 465 should not
- Port 25 should NOT accept messages for non-local domains... ports
587 and 465 must
- Port 25 must not require SSL or AUTH; ports 587 and 465 SHOULD
(or,
as I prefer -- allow it on 587, require it on 465).
This STOPS spammers from connecting on your port 25 interface and
sending all kinds of messages through an authenticated "work
around". Of
course, it doesn't stop the same hacker from just switching to
ports 587
or 465... but I haven't seen them use those ports YET.
Just my thoughts....
Dan McAllister
IT4SOHO
Dan McAllister
---------------------------------------------------------------------
To unsubscribe, e-mail:
qmailtoaster-list-unsubscr...@qmailtoaster.com
<mailto:qmailtoaster-list-unsubscr...@qmailtoaster.com>
For additional commands, e-mail:
qmailtoaster-list-h...@qmailtoaster.com
<mailto:qmailtoaster-list-h...@qmailtoaster.com>
