supporting pop-before-smtp

Edward Capriolo <[email protected]>
Newsgroups gmane.mail.qmail.ldap
Message-ID <[email protected]>
All,

We are using qmail-ldap on 4 nodes with a large NFS-Filer with
takeover capabilities. We are actually only using qmail for SMTP
services, courier is providing POP & IMAP functionality.

Everything in our setup is redundant or has fail over capabilities
with the exception of pop-before-smtp. We are using the
pop-before-smtp daemon (perl) to generate the smtp cdb file.
My setup looks like this:

server1->courier->syslog-ng -> /mnt/filer/maillog
server2->courier->syslog-ng -> /mnt/filer/maillog
server3->courier->syslog-ng -> /mnt/filer/maillog
server4->courier->syslog-ng -> /mnt/filer/maillog

This ran well for a time, but load was corrupting the maillog where
entries would be written inside each other (not one per line). This
would happen say 15 times an hour.

I adjusted my syslog-ng.conf and added.

OS is freeBSD 7.2 and all the NFS locking stuff is on.

destination maillogalt{ file("/mnt/na1/log/maillog" fsync(yes) ); };

This definitely lowered the corruption to maybe twice an hour, but
there is still corruption.

Also pop-before-smtp is writing the cdb file to nfs space. Qmail logs
periodically show a stale file handle. This happens because qmail-smtp
is trying to read this file as pop-before-smtp is writing it.

tcpserver -H -v -URl $ME -x/mnt/filer/etc/tcp.smtp.cdb

Also I cant find documentation on how to use tcprulescheck.. It never
produces any output, (strings shows plenty of rules)

[root@nymail1 ~]# tcprulescheck /var/qmail-smtpd.cdb
rule :
allow connection

The only person I found with a solution for this exact problem was this.

http://www.tnpi.net/internet/mail/toaster/patches/tcpserver-mysql.shtml

Mysql has its own set of problems, and unless I do active active mysql
we just have a mysql single point of failure.

So does anyone have any suggestions/tips for high volume/multinode
pop-before-smtp? (I know I don't want to support it either but such is
life)

Thank you,
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.