Mailing List Archive: Qmail: users

mailfront / qmail-qfilter / vmailmgr "spring'08 cleanup" required...

Index | Next | Previous | View Threaded

om-lists-qmail at omx

May 5, 2008, 2:56 PM

Post #1 of 11 (693 views)
Permalink

mailfront / qmail-qfilter / vmailmgr "spring'08 cleanup" required...

Hello,

Since a few years, I've been using this basic qmail-smtpd / cvm
validation setup on some servers based on qmail + vmailmgr:
http://qmail.omnis.ch/om/current_setup_20080505/
Then I added some basic antispam stuff (ospam, based on .qmail files),
and everything was fine.

But now since a few weeks/months, it seems it is not enough anymore
(cf. my mail with subject 'issues because of forwarded mails : "550 Too
many errors from your IP"') : even without local problems
(scripts/customers sending spams), servers are getting blacklisted from
time to time, and I would like to prevent that...

Now, I'm thinking about adding:
- spam check on smtp level as well (to prevent problems with spams
sent to local users with forwarding addresses), and reporting status
like this mail server for example (not just "message refused"):

@40000000481f7eaf0a90cfa4 starting delivery 10823: msg 940105 to remote
om1234[at]example.com
@40000000481f7eaf0a90e32c status: local 12/100 remote 2/120
@40000000481f7eb81ef77f74 delivery 10823: failure:
213.160.40.17_failed_after_I_sent_the_message./Remote_host_said:_554_5.7.1_Spamassassin-Score:_18.1
01_>=_7_:_Content_indicates_spam:_BAYES_50,DCC_CHECK,DIGEST_MULTIPLE,DNS_FROM_RFC_DSN,GIF_IMAGE_EXTRA_3,HTML_MESSAGE,IMPPYZOR_CHECK,LONGWORD,MIME_HTML
_ONLY,RAZOR2_CF_RANGE_51_100,RAZOR2_CF_RANGE_E4_51_100,RAZOR2_CHECK,RBL_COMBO_A_2,RBL_COMBO_PS_2,RCVD_IN_CBL_SPAM,RCVD_IN_UCE_SPAM,SPAMPIC_SUSPECT,SPA
MTRAP_COMBO_2,TDE_RO_BV_GRATIS,TDE_WS_BV_PREIS1/
@40000000481f7eb81ef7a684 status: local 3/100 remote 3/120
@40000000481f7eb8309412c4 bounce msg 940105 qp 25730

- greylisting in some cases (spamdyke looks promising?)
- better use of rbl's (with possibility for the users to turn this
on/off depending on the user preferences)
- stuff to detect expired mail forwarders (the one from Jeremy is good,
but maybe "too" strong for sensitive servers, for example with a
server sending a 554 like the one a few lines up)

So I just would like to know: how are you handling all that on your
servers? If you have some sample setup / scripts, that would be
nice... :) And it shouldn't if possible be based on qmail patches
(beside QMAILQUEUE). I spent a moment browsing & searching for
solutions this afternoon, but all I could find were old / outdated
scripts, and I'd be glad not having to reinvent the wheel again. The
solution may also cost a little bit if really necessary...

Thanks & regards from Zürich,
Olivier

hugo.monteiro at fct

May 5, 2008, 4:19 PM

Post #2 of 11 (676 views)
Permalink

Re: mailfront / qmail-qfilter / vmailmgr "spring'08 cleanup" required... [In reply to]

Olivier Mueller wrote:
> Hello,
>
> Since a few years, I've been using this basic qmail-smtpd / cvm
> validation setup on some servers based on qmail + vmailmgr:
> http://qmail.omnis.ch/om/current_setup_20080505/
> Then I added some basic antispam stuff (ospam, based on .qmail files),
> and everything was fine.
>
> But now since a few weeks/months, it seems it is not enough anymore
> (cf. my mail with subject 'issues because of forwarded mails : "550 Too
> many errors from your IP"') : even without local problems
> (scripts/customers sending spams), servers are getting blacklisted from
> time to time, and I would like to prevent that...
>
> Now, I'm thinking about adding:
> - spam check on smtp level as well (to prevent problems with spams
> sent to local users with forwarding addresses), and reporting status
> like this mail server for example (not just "message refused"):
>
> @40000000481f7eaf0a90cfa4 starting delivery 10823: msg 940105 to remote
> om1234[at]example.com
> @40000000481f7eaf0a90e32c status: local 12/100 remote 2/120
> @40000000481f7eb81ef77f74 delivery 10823: failure:
> 213.160.40.17_failed_after_I_sent_the_message./Remote_host_said:_554_5.7.1_Spamassassin-Score:_18.1
> 01_>=_7_:_Content_indicates_spam:_BAYES_50,DCC_CHECK,DIGEST_MULTIPLE,DNS_FROM_RFC_DSN,GIF_IMAGE_EXTRA_3,HTML_MESSAGE,IMPPYZOR_CHECK,LONGWORD,MIME_HTML
> _ONLY,RAZOR2_CF_RANGE_51_100,RAZOR2_CF_RANGE_E4_51_100,RAZOR2_CHECK,RBL_COMBO_A_2,RBL_COMBO_PS_2,RCVD_IN_CBL_SPAM,RCVD_IN_UCE_SPAM,SPAMPIC_SUSPECT,SPA
> MTRAP_COMBO_2,TDE_RO_BV_GRATIS,TDE_WS_BV_PREIS1/
> @40000000481f7eb81ef7a684 status: local 3/100 remote 3/120
> @40000000481f7eb8309412c4 bounce msg 940105 qp 25730
>
> - greylisting in some cases (spamdyke looks promising?)
> - better use of rbl's (with possibility for the users to turn this
> on/off depending on the user preferences)
> - stuff to detect expired mail forwarders (the one from Jeremy is good,
> but maybe "too" strong for sensitive servers, for example with a
> server sending a 554 like the one a few lines up)
>
> So I just would like to know: how are you handling all that on your
> servers? If you have some sample setup / scripts, that would be
> nice... :) And it shouldn't if possible be based on qmail patches
> (beside QMAILQUEUE). I spent a moment browsing & searching for
> solutions this afternoon, but all I could find were old / outdated
> scripts, and I'd be glad not having to reinvent the wheel again. The
> solution may also cost a little bit if really necessary...
>
> Thanks & regards from Zürich,
> Olivier
>
>
>

Hello Olivier,

i have never used vmailmgr, but from what i remember from the
documentation i once read, it lives along with a vanilla qmail install.
In that case, and although you've mentioned that you would prefer
approaches that wouldn't involve patching qmail, i'd like to share two
possibilities that have been of extreme benefit to me. Greylisting(++)
and Greeting Delay.

Apparently spamdyke allows similar features, although apparently they
announce greeting delay as being able to "stop earlytalkers", without
patching qmail but i find extra handy the additional goodies. Those are
provided by the not so new envelope scanning patch for qmail, in which i
altered the scanner call to allow passing the HELO from the connecting
server. This way, and making use of a scanner that connects to a policyd
server i have a centralized way to control greylisting, whitelisting and
blacklisting by IP address/netblock, dns name, sender and recipient with
wildcard support, preform HELO/EHLO checking with automatic
blacklisting, sender and recipient throttling in terms of message count
and preform automatic spamtrapping.

About the greeting delay patch, i'm using John Simpson's patch, with a
small change to allow automatic disabling in the case RELAYCLIENT is set
and/or the user has successfully authenticated himself (i also use the
smtpauth-tls patch that is part of netqmail).

You can read more and peek the code in the following links respectivelly,

http://hmonteiro.net/patches:qmail_envelope_scan

and

http://hmonteiro.net/patches:qmail_greetdelay

Best regards,

Hugo Monteiro.

--
ci.fct.unl.pt:~# cat .signature

Hugo Monteiro
Email : hugo.monteiro[at]fct.unl.pt
Telefone : +351 212948300 Ext.15307

Centro de Informática
Faculdade de Ciências e Tecnologia da
Universidade Nova de Lisboa
Quinta da Torre 2829-516 Caparica Portugal
Telefone: +351 212948596 Fax: +351 212948548
www.ci.fct.unl.pt apoio[at]fct.unl.pt

ci.fct.unl.pt:~# _

graham901 at webenhanced

May 5, 2008, 8:44 PM

Post #3 of 11 (669 views)
Permalink

RE: mailfront / qmail-qfilter / vmailmgr "spring'08 cleanup"required... [In reply to]

Olivier Mueller wrote:
> Hello,
>
> Since a few years, I've been using this basic qmail-smtpd / cvm
> validation setup on some servers based on qmail + vmailmgr:
> http://qmail.omnis.ch/om/current_setup_20080505/
> Then I added some basic antispam stuff (ospam, based on .qmail files),
> and everything was fine.

I also used vmailmgr for many years. Here is the way we used to do it.

smtp -> rblsmtpd -> mailfront -> cvm -> qmail -> QMVC(badloaders, clamav, etc) -> vdeliver

This chain took a bit installing and configuring to string it together properly, but was quite
effective. However, its effectiveness slowly declined.

We then put an IP address only based greylisting program in front of mailfront. This reduced the
spam load by over 50%.

But still it grows.

> - greylisting in some cases (spamdyke looks promising?)
> - better use of rbl's (with possibility for the users to turn this
> on/off depending on the user preferences)
> - stuff to detect expired mail forwarders (the one from Jeremy is good,
> but maybe "too" strong for sensitive servers, for example with a
> server sending a 554 like the one a few lines up)

I cannot comment much on all these points except greylisting. We have used greylisting now for a
couple of years and its effectiveness is really quite good once we based it on the triplet (IP,
sender, recipient). We don't even virus check on some of our servers as the greylisting seems to
knock them on the head too. Except for accounts that have unconsciously "opted in" to the
spammer network in the US, most of our client mailboxes get little or no spam at all now.

> So I just would like to know: how are you handling all that on your
> servers? If you have some sample setup / scripts, that would be
> nice... :) And it shouldn't if possible be based on qmail patches
> (beside QMAILQUEUE). I spent a moment browsing & searching for
> solutions this afternoon, but all I could find were old / outdated
> scripts, and I'd be glad not having to reinvent the wheel again. The
> solution may also cost a little bit if really necessary...

OK, this is what we now use instead of the above mentioned setup. We are migrating our servers
to Plesk and have tailored our solution to their qmail setup. But before you say "Argh", read
on.

Plesk uses qmail-spp to allow plugins into the SMTP conversation. So we wrote our own
greylisting plugin based on the greylisting-spp one available on the qmail-spp web site. We
basically wrote a new sqlite3 backend for that plugin so we could expand its functionality.

So now:
smtp -> rblsmtpd -> qmail-smtpd -> qmail-spp (rules below) -> qmail -> local delivery.
qmail-spp rules:

connection -> tcprules-spp (to give us env variables based on IP for things such as whitelisting
- like tcpserver as a plugin)

RCPT TO -> greylisting, then chkrcptto

This allows us to not only whitelist certain IP address ranges, but also handle large ISPs that
use email server farms. So what we do is look at the C class if the sender and recipient are the
same.

We will probably enhance this a bit more over time but it is working really well now. And
plugins do not seem too hard to write. It is a simple interface. We used C, but any language
could be used.

Cheers from Down Under.
Graham

jeff at doeshosting

May 6, 2008, 12:51 AM

Post #4 of 11 (669 views)
Permalink

Re: mailfront / qmail-qfilter / vmailmgr "spring'08 cleanup" required... [In reply to]

> Hello,
>
> Now, I'm thinking about adding:
> - spam check on smtp level as well (to prevent problems with spams
> sent to local users with forwarding addresses),
>
>
>
>

I do this with simscan with clamav (aka clamd) and spamassassin
(spamd / spamc)
along with john simpsons combined patch.
You may find this page helpful: http://qmail.jms1.net/simscan/
troubleshooting.shtml

> and reporting status
> like this mail server for example (not just "message refused"):
>
> @40000000481f7eaf0a90cfa4 starting delivery 10823: msg 940105 to =20
> remote
> om1234[at]example.com
> @40000000481f7eaf0a90e32c status: local 12/100 remote 2/120
> @40000000481f7eb81ef77f74 delivery 10823: failure:
> 213.160.40.17_failed_after_I_sent_the_message./=20
> Remote_host_said:_554_5.7.1_Spamassassin-Score:_18.1
> 01_>=3D_7_:_Content_indicates_spam:_BAYES_50,DCC_CHECK,DIGEST_MULTIPLE
> ,D=
> NS_FROM_RFC_DSN,GIF_IMAGE_EXTRA_3,HTML_MESSAGE,IMPPYZOR_CHECK,LONGWORD
> ,MIME_HTML
> _ONLY,RAZOR2_CF_RANGE_51_100,RAZOR2_CF_RANGE_E4_51_100,RAZOR2_CHECK,RB
> L_COMBO_A_2,RBL_COMBO_PS_2,RCVD_IN_CBL_SPAM,RCVD_IN_UCE_SPAM,SPAMPIC_S
> USPECT,SPAMTRAP_COMBO_2,TDE_RO_BV_GRATIS,TDE_WS_BV_PREIS1/
> @40000000481f7eb81ef7a684 status: local 3/100 remote 3/120
> @40000000481f7eb8309412c4 bounce msg 940105 qp 25730
>
>
>
>
>

as you will read in http://www.qmailwiki.org/Simscan/README
you do this:
If --enable-custom-smtp-reject is used, messages are rejected with a
custom message. You will need to apply the qmail-queue-custom-
error.patch patch located in the contrib directory in order to make
this work.

> Thanks & regards from Z=FCrich,
> Olivier
>
>
>
>
>
>
Good luck,
-krzee

om-lists-qmail at omx

May 6, 2008, 5:40 AM

Post #5 of 11 (671 views)
Permalink

Re: mailfront / qmail-qfilter / vmailmgr "spring'08 cleanup" required... [In reply to]

Hello Huge & thanks for your feedback!

On Tue, 2008-05-06 at 00:19 +0100, Hugo Monteiro wrote:
> [...] provided by the not so new envelope scanning patch for qmail, in which i
> altered the scanner call to allow passing the HELO from the connecting
> server. This way, and making use of a scanner that connects to a policyd
> server i have a centralized way to control greylisting, whitelisting and
> blacklisting by IP address/netblock, dns name, sender and recipient with
> wildcard support, preform HELO/EHLO checking with automatic
> blacklisting, sender and recipient throttling in terms of message count
> and preform automatic spamtrapping.

This sounds interesting and is probably the way to go for me: a central
policyd server for a few mail hosts. And about the patches and the
calls, I guess all of this can be done via some simple qfilter/mailfront
scripts.

I'll have a look at this policyd-based way, thanks for the suggestion!
regards,
Olivier

om-lists-qmail at omx

May 6, 2008, 5:50 AM

Post #6 of 11 (669 views)
Permalink

RE: mailfront / qmail-qfilter / vmailmgr "spring'08 cleanup"required... [In reply to]

Good afternoon Graham, and thanks a lot for your detailed answer!

On Tue, 2008-05-06 at 13:44 +1000, Graham Miller wrote:
> I also used vmailmgr for many years. Here is the way we used to do it.
> smtp -> rblsmtpd -> mailfront -> cvm -> qmail -> QMVC(badloaders, clamav, etc) -> vdeliver
> This chain took a bit installing and configuring to string it together properly, but was quite
> effective. However, its effectiveness slowly declined.

yes, I can understand why :)

> I cannot comment much on all these points except greylisting. We have used greylisting now for a
> couple of years and its effectiveness is really quite good once we based it on the triplet (IP,
> sender, recipient). We don't even virus check on some of our servers as the greylisting seems to
> knock them on the head too. Except for accounts that have unconsciously "opted in" to the
> spammer network in the US, most of our client mailboxes get little or no spam at all now.

not bad... :) Well, I tried greylisting already (but only based on IP
Address), and it was not really successful: many recipients were
complaining about mail delilvery delays: -> greylisting should occur
only for "suspect" hosts.

> So now:
> smtp -> rblsmtpd -> qmail-smtpd -> qmail-spp (rules below) -> qmail -> local delivery.
> qmail-spp rules:
>
> connection -> tcprules-spp (to give us env variables based on IP for things such as whitelisting
> - like tcpserver as a plugin)
>
> RCPT TO -> greylisting, then chkrcptto

interesting... May I ask how are you handling the VRFY check for
vmailmgr accounts ? (I see a "vpopmail_check_recipient" under
http://qmail-spp.sourceforge.net/plugins/ but nothing about vmailmgr).

And is everything working well, or what are/were the problems?

Regards & to be continued, I'll have a look at qmail-ssp too then,
Olivier

jbacksch-qmail at tca-os

May 6, 2008, 11:01 AM

Post #7 of 11 (668 views)
Permalink

Re: mailfront / qmail-qfilter / vmailmgr "spring'08 cleanup" required... [In reply to]

Olivier Mueller wrote:

> - spam check on smtp level as well (to prevent problems with spams
> sent to local users with forwarding addresses), and reporting status
> like this mail server for example (not just "message refused"):

spamassassin tagging can be done within a SMTP session with
qmail-qfilter and the QQF_QMAILQUEUE parameter, e.g.:

QQF_QMAILQUEUE=<your spamassassin script>

your spamassassin script:
/usr/bin/spamc | /var/qmail/bin/qmail-queue

> - greylisting in some cases (spamdyke looks promising?)

- Greylisting with SMTP AUTH support
- Greylisting control (delay, whitelisting, disable) via tcprules
- Greylisting sharing to all your MXs
- VERP support possible
- BATV support possible
- no DB needed
- no Perl needed
- very fast and simple

Please have a look at:

<http://www.backschues.net/qmail/>

> - better use of rbl's (with possibility for the users to turn this
> on/off depending on the user preferences)

My recommendation:

<http://morettoni.net/qmail-rblchk.en.html>

> - stuff to detect expired mail forwarders (the one from Jeremy is good,
> but maybe "too" strong for sensitive servers, for example with a
> server sending a 554 like the one a few lines up)

badmailfromint and badmailtoint of the qmail all in one patch:

<http://www.backschues.net/qmail/>

> And it shouldn't if possible be based on qmail patches (beside QMAILQUEUE).

Have a look at my web site.

--
Greetings
Jörg Backschues

graham901 at webenhanced

May 7, 2008, 2:56 AM

Post #8 of 11 (659 views)
Permalink

RE: mailfront / qmail-qfilter / vmailmgr "spring'08cleanup"required... [In reply to]

Olivier Mueller wrote:
> Good afternoon Graham, and thanks a lot for your detailed answer!

A pleasure Olivier.

> not bad... :) Well, I tried greylisting already (but only based on IP
> Address), and it was not really successful: many recipients were
> complaining about mail delilvery delays: -> greylisting should occur
> only for "suspect" hosts.

We started with the standard whitelist and then I did a lot of checking with the Australian ISPs
to get their mail server IP address ranges so I could white list them. About half published SPF
records which made it easy to gather the list and others responded to direct email requests sent
to postmaster@ (or other usual suspects). Others did not respond and so I do not whitelist them.

The greylisting plugin uses C class checking for return visits and that helps a lot with the big
email farms that move the delivery from one mail server to another on each attempt. Otherwise
delays of several hours can happen and even delivery failure in extreme cases.

I use lower timeouts than suggested on the greylisting web site as default.

Initial wait time = 2 minutes
Max wait time for second attempt = 1 day
Expiry time since last connection = 3 days

>> So now:
>> smtp -> rblsmtpd -> qmail-smtpd -> qmail-spp (rules below) -> qmail -> local delivery.
>> qmail-spp rules:
>>
>> connection -> tcprules-spp (to give us env variables based on IP for things such as
>> whitelisting - like tcpserver as a plugin)
>>
>> RCPT TO -> greylisting, then chkrcptto
>
> interesting... May I ask how are you handling the VRFY check for
> vmailmgr accounts ? (I see a "vpopmail_check_recipient" under
> http://qmail-spp.sourceforge.net/plugins/ but nothing about vmailmgr).

I am not actually using vmailmgr as a backend anymore. Plesk uses the qmail USERS mechanism with
control panel access. And on a sole remaining non-plesk server, I maintain the users manually.
But I use the chkrcptto plugin which handles that mechanism. Not sure if that is a plesk only
thing or not. But what I did was install a couple of Plesk rpms to get the qmail handling
running quickly, then added our tcprules and greylisting plugins. I had pre-built the basic
qmail-users file ready to go and the conversion went fairly easily. Only some 5 minutes without
mail.

Another thought I have just had. Perhaps you could keep mailfront (you are using that right?)
with its CVM access to vmailmgr backend, and add a greylisting plugin into mailfront. I seem to
remember that Bruce had some plugin hooks in there at connection time, recipient, sender etc.
The plugin nature of qmail-spp is quite simple and plugins made for it would probably be easily
adapted to mailfront. They just pass control to the plugin which relies on environment variables
to determine values of certain things like recipient and sender etc.

How handy with coding are you. I'd happily send you our source code for the greylisting plugin
(in C) so you could have a go at converting it into a mailfront plugin. I could give you
pointers along the way probably.

You would not need our tcprules plugin as that is only needed on a plesk server because they use
xinetd instead of tcpserver. Go figure!

> And is everything working well, or what are/were the problems?

I am quite happy with results. Our main problem was converting from vmailmgr to qmail-users
style mailboxes but I was able to transfer the encrypted passwords from vmailmgr into the users
file by using "strings passwd.cdb".

We had dedicated mail servers with the custom mailfront-qmail-vmailmgr setup on them, and as we
migrated mail, domain at a time, from them to the plesk control panel environment with the
domain's web site, we had to do quite a bit of work. But this was good for our relations with
our customers as we talked to each one and showed them the new facility. Previously they had no
control panel access at all. So now they can manage their mailboxes and access the horde webmail
client as well. If we chose to implement it, we can offer spamassassin and some form of virus
scanning, but as yet we have resisted this.

Regards
Graham

hugo.monteiro at fct

May 9, 2008, 5:37 PM

Post #9 of 11 (614 views)
Permalink

Re: mailfront / qmail-qfilter / vmailmgr "spring'08 cleanup" required... [In reply to]

John Simpson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2008-05-05, at 1919, Hugo Monteiro wrote:
>>
>> About the greeting delay patch, i'm using John Simpson's patch, with
>> a small change to allow automatic disabling in the case RELAYCLIENT
>> is set
>
> wouldn't it have been easier to change this:
>
> RELAYCLIENT=""
>
> to this:
>
> RELAYCLIENT="",GREET_DELAY="0"
>
> wherever it appears in your tcpserver control file, and not have to
> change the code at all?
>
>
Hello John,

You are right. I'll drop that code as soon as possible.

>> and/or the user has successfully authenticated himself
>
> how does that work? the GREET_DELAY check is done before the user is
> able to send an AUTH command.
>
> i looked at the patch file on your site and i don't see that happening...
>
>

Yep, when i wrote that line i was also thinking one the envelope
scanning procedure. Of course it makes no sense to talk about
authentication in that stage.

>> (i also use the smtpauth-tls patch that is part of netqmail).
>
> i didn't know netqmail had support for AUTH or TLS. i always thought
> they were following a "bare minimum of patches" policy, and the only
> non-trivial patch they included was the QMAILQUEUE patch?
>
> and if so, what's the difference between it, and the AUTH/TLS patch
> which is part of my combined patch?
>
>
Once again, bad choice of words on my part. The patch i'm refering to is
Bill Shupp's netqmail-1.05-tls-smtpauth-20070417.patch
<http://shupp.org/patches/netqmail-1.05-tls-smtpauth-20070417.patch>. I
should have said "patch FOR netqmail" instead of "part of". My bad.

As for the differences between that and what's in your combined patch i
can't say. I didn't go through the code in your combined patch for that one.

I praise your effort and i'm sure that your combined patch is just right
for many people besides you. You state in your website that you decided
to make your own patchset because there were things you liked and things
you didn't like about other patchsets. Same applies to me. There are a
few things i want to skip on yours, mainly because i have other thoughts
for my installs.

I liked the greetdelay part, and since it was rather easy to "rip off",
i used it. If you had decided to keep separated patches for all the
other enhancements along with the patchset, i'd probably pick your
smtpauth+tls stuff. But that didn't happen, so i chose another that was
rather easy to combine with the rest of the stuff i use and that i knew
it wouldn't cause me any grief. I'm actually using it temporarily, since
my main goal is to port the auth+tls stuff from qmail-ldap, or change
Bill's patch a little to provide some other interesting approaches, like
being able to choose to use AUTH even if TLS isn't used, and vice-versa.
Time will tell.

Although you sent your reply to my email address only, i felt like i had
to reply to the list also. The originating message was from an earlier
reply. Hope you don't mind.

Thanks for pointing out those "goofs".

Hugo Monteiro.

--
ci.fct.unl.pt:~# cat .signature

Hugo Monteiro
Email : hugo.monteiro[at]fct.unl.pt
Telefone : +351 212948300 Ext.15307

Centro de Informática
Faculdade de Ciências e Tecnologia da
Universidade Nova de Lisboa
Quinta da Torre 2829-516 Caparica Portugal
Telefone: +351 212948596 Fax: +351 212948548
www.ci.fct.unl.pt apoio[at]fct.unl.pt

ci.fct.unl.pt:~# _

jms1 at jms1

May 9, 2008, 9:22 PM

Post #10 of 11 (611 views)
Permalink

Re: mailfront / qmail-qfilter / vmailmgr "spring'08 cleanup" required... [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2008-05-09, at 2037, Hugo Monteiro wrote:
>
> I liked the greetdelay part, and since it was rather easy to "rip
> off", i used it. If you had decided to keep separated patches for
> all the other enhancements along with the patchset, i'd probably
> pick your smtpauth+tls stuff.

most of the stuff in my patch is actually copies of other peoples'
patches. the validrcptto.cdb patch is the only one i felt was actually
worth releasing as a separate patch... that and the AUTH_CDB patch,
but that requires most of the existing AUTH patch, so there was no
easy way to make a stand-alone AUTH_CDB patch. i thinking the closest
i could do would be an AUTH_CDB+AUTH+TLS patch, if i ever get some
free time to work on it.

there was originally an AUTH patch, and about the same time somebody
wrote a TLS patch... and somebody else combined the two. (i forget the
names of the people involved, but it's all on qmail.org.) that
combined AUTH+TLS patch is part of my patch, part of bill shupp's
patch, and part of probably every other "mega-patch" out there.

so what i was asking was how the AUTH+TLS patch you're using differs
from the one which is already part of my combined patch, and how you
managed to "add" it when it was already in there.

> ... my main goal is to port the auth+tls stuff from qmail-ldap

again, which differs how, other than using an LDAP server to validate
the credentials? if there are general improvements for the AUTH+TLS
patch, i'd like to see them and possibly include them in my own patch.

> ... or change Bill's patch a little to provide some other
> interesting approaches, like being able to choose to use AUTH even
> if TLS isn't used

you mean like the ALLOW_INSECURE_AUTH variable lets you do with my
patch?

although, other than "PHB syndrome" (i.e. having to deal with a
"pointy-haried boss", from the "dilbert" cartoons) i don't understand
why anybody would WANT to allow their users to send an AUTH command
over a non-encrypted connection... it's too easy for a spammer to pay
some low-level flunkie at an ISP to plug into the right switch and run
a packet sniffer to harvest passwords, and then use your server to
send spam. if it can happen to somebody like AOL (last year) with
their huge security budget, it can happen to any of us.

> Although you sent your reply to my email address only, i felt like i
> had to reply to the list also. The originating message was from an
> earlier reply. Hope you don't mind.

no, i don't mind- i forgot to hit "reply to all" and didn't notice it
was going directly to you instead of to the list anyway.

- --------------------------------------------------------
| John M. Simpson -- KG4ZOW -- Programmer At Large |
| http://www.jms1.net/ <jms1[at]jms1.net> |
- --------------------------------------------------------
| Hope for America -- http://www.ronpaul2008.com/ |
- --------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkglIu4ACgkQEB9RczMG/PtvmACfSyEJHHTPBUQxIqf+1X34RXdA
htoAoO4RcZLb0f1gb/6kNDt+1l8TLGM5
=Wr5N
-----END PGP SIGNATURE-----

hugo.monteiro at fct

May 10, 2008, 5:00 AM

Post #11 of 11 (608 views)
Permalink

Re: mailfront / qmail-qfilter / vmailmgr "spring'08 cleanup" required... [In reply to]

John Simpson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2008-05-09, at 2037, Hugo Monteiro wrote:
>>
>> I liked the greetdelay part, and since it was rather easy to "rip
>> off", i used it. If you had decided to keep separated patches for all
>> the other enhancements along with the patchset, i'd probably pick
>> your smtpauth+tls stuff.
>

Still about automatically disabling greeting delay if relayclient is
set, after some thought, your sugestion of not doing so by setting
GREETDELAY to 0 it's actually a good idea. In some situations it could
be used to try to contain some infected intranet clients which almost
always disregard the greeting from the server before sending data.

> most of the stuff in my patch is actually copies of other peoples'
> patches. the validrcptto.cdb patch is the only one i felt was actually
> worth releasing as a separate patch... that and the AUTH_CDB patch,
> but that requires most of the existing AUTH patch, so there was no
> easy way to make a stand-alone AUTH_CDB patch. i thinking the closest
> i could do would be an AUTH_CDB+AUTH+TLS patch, if i ever get some
> free time to work on it.
>

Yeah, i know the feeling...

> there was originally an AUTH patch, and about the same time somebody
> wrote a TLS patch... and somebody else combined the two. (i forget the
> names of the people involved, but it's all on qmail.org.) that
> combined AUTH+TLS patch is part of my patch, part of bill shupp's
> patch, and part of probably every other "mega-patch" out there.
>
> so what i was asking was how the AUTH+TLS patch you're using differs
> from the one which is already part of my combined patch, and how you
> managed to "add" it when it was already in there.
>
>

I think you're confusing things ... I'm not using your combined patch,
so there's no way i could've added anything to it.

>> ... my main goal is to port the auth+tls stuff from qmail-ldap
>
> again, which differs how, other than using an LDAP server to validate
> the credentials? if there are general improvements for the AUTH+TLS
> patch, i'd like to see them and possibly include them in my own patch.
>
>
>> ... or change Bill's patch a little to provide some other interesting
>> approaches, like being able to choose to use AUTH even if TLS isn't used
>
> you mean like the ALLOW_INSECURE_AUTH variable lets you do with my patch?
>
> although, other than "PHB syndrome" (i.e. having to deal with a
> "pointy-haried boss", from the "dilbert" cartoons) i don't understand
> why anybody would WANT to allow their users to send an AUTH command
> over a non-encrypted connection... it's too easy for a spammer to pay
> some low-level flunkie at an ISP to plug into the right switch and run
> a packet sniffer to harvest passwords, and then use your server to
> send spam. if it can happen to somebody like AOL (last year) with
> their huge security budget, it can happen to any of us.
>
>

Like i said earlier, if you had the AUTH+TLS stuff as a standalone
patch, i might have used it instead of Bill's patch. I do not wish to
use your combined patch.

>> Although you sent your reply to my email address only, i felt like i
>> had to reply to the list also. The originating message was from an
>> earlier reply. Hope you don't mind.
>
> no, i don't mind- i forgot to hit "reply to all" and didn't notice it
> was going directly to you instead of to the list anyway.
>
>

One other consideration that i'd like to share is that also my approach
is to keep the original code changes to a minimum. For that, i'm
thinking about an approach using calls to external programs to provide
the functionalities. For instance, for recipient validation, i'm
struggling to make a program to provide multiple backend
lookup/verification so that i can use Soffian's realrcptto patch. I'm
already using that for approach for envelope scanning, and it's in my
plans to get something similar for sender checking (for mail relay) and
authentication too.

Regards,

Hugo Monteiro.

--
ci.fct.unl.pt:~# cat .signature

Hugo Monteiro
Email : hugo.monteiro[at]fct.unl.pt
Telefone : +351 212948300 Ext.15307

Centro de Informática
Faculdade de Ciências e Tecnologia da
Universidade Nova de Lisboa
Quinta da Torre 2829-516 Caparica Portugal
Telefone: +351 212948596 Fax: +351 212948548
www.ci.fct.unl.pt apoio[at]fct.unl.pt

ci.fct.unl.pt:~# _

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com