John Peacock (jpe...@rowman.com)

David Summers wrote:
> I know I can hack the current plugins to do more of that but I was
> wondering if there was any development work to both reduce the amount of
> logging and/or make it more concise?

The whole logging system could definitely handle some reorganization, to
rationalize what gets logged at which level.  However, if you take a look at
some of the logging plugins, it should be really easy to adapt one to do exactly
what you want.  I'm pretty sure there was a logging plugin that collected all
elements of a single message and logged it on a single line, check the wiki:

http://wiki.qpsmtpd.org/

Another thing to consider (and is what I do), is to use the adaptive logging
plugin, which lets you log at two different levels. I did this internally at my
previous company, so the full debug logs were rolled every ~36 hours and the
minimal logs were around for months.

> QMAIL/QPSMTD/TMDA/(CourierIMAP|BincIMAP) combination provides a dynamite
> and customizable mail server and SPAM prevention package.

You might also want to take a look at dovecot:

http://www.dovecot.org

which is a *very* scalable IMAP/POP server that works well with qmail delivery
(i.e. maildir).

John

Ask Bjørn Hansen wrote:
> Cool! Pretty funny that qpsmtpd makes a good test tool for an SMTP
> client.  :-)

Yeah, well, qpsmtpd is a lot lighter weight and yet feature complete (not to
mention easier to configure) than any other MTA I've yet encountered.  ;-)

I have grandiose plans to write an abstract RFC2821 class that could be quickly
turned into a stub server with a single subclass.  Oddly enough, if I go that
route, I will probably wind up rewriting qpsmtpd to use that class (since it
will have a true finite state machine) and everything will come full circle.

> If we made Qpsmtpd installable via CPAN then it could just see if
> Qpsmtpd is available and if so then start a server instance on a high
> port.

The only caveat with that is that I explicitly test SMTPS, which the qpsmtpd
code only supports on port 465.  I could test everything else, however, but I'd
like to support the tlsinit required for a fully SSL connection (even though the
RFC's suggest this is legacy only).  Maybe if I go forward on my AUTH rewrite,
to get those hardcoded bits out of the core...

John

Brad Fitzpatrick wrote:
> But postfix/dovecot were only using the .crt and .key, as far as I can
> see. Why does qpsmtpd need the CA file? Isn't Geotrust in clients'
> default CA lists?

It isn't the client, rather it is the server that needs the Geotrust CA in it's
own CA file.  OpenSSL on the server has to have the entire chain available to
it, so that it can send the correct signature to the client to have a fully
trusted certificate chain.  You should just be able to append the Geotrust CA
into the qpsmtpd .ca file and you'll be good to go (though to be honest I
haven't tested that, as you'll see below).

On the other hand, this is one of those times when paying the CA cartel's money
for signing your cert is pretty pointless.  When I finished the rough edges of
the TLS feature, I made the reasonable assumption that in the simple case, the
majority of people would use self-signed certs.  That is why the default script
just dummies up a selfsigned cert automatically.

The reason for this is that you only need to "Trust forever" the server-signed
cert once, when you first configure your client to use TLS. After that, I'm not
aware of any mail clients that even give you any feedback that you are using a
TLS connection (i.e. there isn't any "Padlock" icon).

YMMV

John

vvitkov wrote:
> I have a mail relay machine on which i want simple checks performed.
> Checks like early talker, dnsbl and some very simple sanities.
> Then the mail should be relayed to the real MX which will perform
> spam/av detection/marking/clearing

What Robin said, but more directly:

MAKE SURE YOUR RELAY SERVER DOES NOT ACCEPT ANY E-MAIL YOU DON'T
[POTENTIALLY] INTEND TO DELIVER.

By this I mean, make sure that whatever method you are using to
authenticate e-mail addresses on the real MX server (LDAP, MySQL
database, whatever) is also available to the relay server.  If you just 
accept any e-mail address here, and bounce it later, you will be sending
bounce messages to forged return addresses (i.e. you will be part of the
problem, not part of the solution).  This is the single most common 
mistake people make when they set up a MX-relay box.

One thing you can consider is queue/smtp-forward, which will start a
SMTP session with your real MX box.  This will have the effect of acting 
like a transparent relay, and any RCPT TO: addresses which would be
denied will be denied back to the remote server.  This happens very late 
in the transaction, however (you've already received the DATA), so if
you can push the RCPT check back up to earlier in the transaction, you
will be better off.

John

Along with the other suggestions you've been given (e.g. make sure you are
validating the destination e-mail address as early as possible), you might want
to consider adding a different blacklist.  I just recently added
dul.dnsbl.sorbs.net to our list (along with zen.spamhaus.org and our internal
listing), because I was getting a lot of spam from Chinese IP blocks which were
too diverse to play whack-a-mole.  The DUL list specifically blocks known
dynamically allocated IP blocks.

If this is a true DDOS, and not just blowback from a distributed spam run, the
hosts that are hitting you are very likely to be zombies located on dynamic
blocks, *not* legitimate e-mail servers.  Your risk of blocking legitimate
e-mail should be very low (i.e. I have not, in the last month, had a single
report of a legitimate server with a dynamic IP address being blocked).
Obviously if you go this route, you are strongly urged to have an internal DNS
whitelist ready to go, just in case you do need to whitelist more than a few
servers.

HTH

John