SMTP-Auth code wrong and broken

The SMTP-Auth in the current version of QPSMTP (v0.28) is broken and wrong. I have fixed it and attached a diff. Problem 1: The AUTH PLAIN method This method is described in RFC2554 and RFC2595. The client forms a string of the form "usernamepassword" and encodes this string using base64. The c

Re: SMTP-Auth code wrong and broken

> The SMTP-Auth in the current version of QPSMTP (v0.28) is broken and > wrong. I have fixed it and attached a diff. Err, not in v0.28 (which has no SMTP auth) but in CVS. -kju -- It's an insane world, but i'm proud to be a part of it. -- Bill Hicks

SMTP auth checkpassword plugin

I've programmed an plugin for the SMTP auth system which can use a regular checkpassword binary. One need to configure the full path of the binary in config file 'smtpauth-checkpassword'. The code is attached. -kju -- It's an insane world, but i'm proud to be a part of it. -- Bill Hicks #!

(Again) checkpassword auth module

I already sent this some time ago, but it seems it remained unnoticed. This is an auth module which can use a traditional checkpassword binary. Great for people who have customized checkpassword-programs which can still be used with qpsmtpd. There are quite some people who use this approach, in fa

Re: (Again) checkpassword auth module

> There are quite some people who use this approach, in fact there are patches > for qmail available, which makes qmail-smtpd a checkpassword binary. "which makes qmail-smtpd call a checkpassword binary" was meant here. This is a popular way of making smtp auth with the original qmail-smtpd. -kju

SMTP Auth: Problem with Client 'Vivian Mail'

I just got a call from a customer which was unable to send Mail using SMTP Auth. Doing some analysis with tcpdump revealed, that the Client in use (Vivian Mail) seems to violate the SMTP auth standard. In particular it introduces itself to the mailserver with HELO instead of EHLO, therefore does n

Re: SMTP Auth: Problem with Client 'Vivian Mail'

> I suggest making this change upstream. I can't see any problems with beeing > more tolerant to broken clients. I made some further investigations. Although the client is in violation of the standard (and the bug was already fixed long ago, seems that my client uses stoneage software), it seems t

Re: SMTP Auth: Problem with Client 'Vivian Mail'

> In particular RFC-1123 specifies that only MAIL, RCPT, DATA, RSET, > VRFY, NOOP, and QUIT be mandatory in response to HELO. Yes, but on the other hand we try to be compatible with the standard qmail-smtpd, which recognizes (but has no further support for) the AUTH-Command both when the client u

Re: SMTP Auth: Problem with Client 'Vivian Mail'

> In particular RFC-1123 specifies that only MAIL, RCPT, DATA, RSET, > VRFY, NOOP, and QUIT be mandatory in response to HELO. And one addition to this: The fact that this are the only _mandatory_ commands after HELO does not state in any way that one is forbidden to accept other commands as well.

Re: SMTP Auth: Problem with Client 'Vivian Mail'

> And even if it were accepted, it should never be implemented by deleting > perfectly legitimate code; it could be a config option if at all. I'm currently trying to make it configurable but it seems that i can not access config files out of the Qpsmtpd::SMTP::auth method. Any hint? I tried:

A suggestion for handling SMTP extensions (was: Re: SMTP Auth: Problem with Client 'Vivian Mail')

> The code in Auth.pm checks to make sure that the client signaled it's > willingness to support extensions (by using EHLO) before proceeding with > the negotiation. I understood that, but that code will never be called if the client did not used EHLO. So it seems that the additional check is po

Re: A suggestion for handling SMTP extensions (was: Re: SMTP Auth: Problem with Client 'Vivian Mail')

> On initialisation the extensions can register new commands like > 'AUTH' with the qpsmtpd core. Oh, and of course specify additional output for the response to the EHLO command. Imagine somethink like this: ...register_extension ("EHLO"); ...register_capability("AUTH PLAIN LOGIN"); -k

Re: A suggestion for handling SMTP extensions (was: Re: SMTP Auth: Problem with Client 'Vivian Mail')

>...register_extension ("EHLO"); Should of course be AUTH, not EHLO. -kju -- It's an insane world, but i'm proud to be a part of it. -- Bill Hicks

Re: $ENV{RELAYCLIENT} (was Re: Problem with check_goodrcptto)

> But RELAYCLIENT being set in the environment is an external requirement > (for some backends, at least qmail-queue). Why do you think it is needed for qmail-queue? I can't see that that's true. -kju -- It's an insane world, but i'm proud to be a part of it. -- Bill Hicks

Plugin 'require_resolvable_fromhost': Why a config file?

Short question: Why has the 'require_resolvable_fromhost' a config file in which one needs to put '1' for enable and '0' for disable? It can be enabled or disabled by putting it into the plugins-configuration or leaving it out. Having an additional config file only makes things more complicated. I

New plugin 'maillog'

rld, but i'm proud to be a part of it. -- Bill Hicks # # maillog # a qpsmtpd plugin for mail logging # # This plugin logs the relevant details like sending host, envelope sender, # envelope recipient and size to the logfile after a mail got accepted # # written by Michael Holzt, # last modifi

Re: New plugin 'maillog'

# a qpsmtpd plugin for mail logging # # This plugin logs the relevant details like sending host, envelope sender, # envelope recipient and size to the logfile after a mail got accepted # # written by Michael Holzt, # last modified on September 3th, 2004 # sub register { my ($self, $qp) = @_; $s

New module 'check_relay_mx'

aying is not allowed, it will check 'rcpthost' and 'morercpthosts' # to see, if we accept mail for that domain. If not found, it can optionally # also accept the mail if we are any (rcptmx=1) or top priority (rcptmx=2) # mail exchanger (mx) in the DNS for that domain. This feature

Re: New plugin 'maillog'

> I don't understand why this is especially useful (and it indeed seems to be > a duplication of existing log information). Yes, all the data is logged already, but that information is unusable. First this data is logged with a very high loglevel, so you need to setup your own loglevel way up to

New plugin 'qppoprelay' plus scripts forming a POP-before-SMTP solution

So this will be my last submission for this night before someone calls the doping police :-) There are still clients out there who are unable to use SMTP AUTH. A solution for a long time which is still usable today is the use of POP-before-SMTP. In this scenario a user authenticates himself by fet

Re: New plugin 'maillog'

> >Is there any way to get rid of the "maillog plugin: " part? > Yes, log through $plugin->qp->log() instead of $plugin->log(). Thanks for the hint. I've changed this in a new version of 'maillog' which is available on http://qpsmtpd.kju.de/. Also new is the possibility to enter '1' into the confi

session->relaying instead of transaction->relaying? (was: Re: New plugin 'maillog')

> Transaction notes are cleared at MAIL FROM. You need to use connection > notes. Ok, this leads to another problem/question. We store the allowance to relay in transaction->relaying. But because this seems to be cleared as well, modules like Auth.pm can not use this, but have to set $ENV{RELAYCLI

Re: session->relaying instead of transaction->relaying?

> I suspect because the only time the code cares about whether this > transaction is permitted to relay is at FROM. I guess you mean at 'RCPT TO'. > a) the mail will be accepted for local delivery (and it isn't really > relaying) Hmm. My intention is to be able to log the associated user even

Re: session->relaying instead of transaction->relaying?

> b. Plugins which authenticates the user (like my qppoprelay) will not >be called at RCPT TO level but on start of the connection. They also >can set session->authenticated. Ok, i just tried that with my 'qppoprelay' plugin (updated version at http://qpsmtpd.kju.de/). It will now be calle

SMTP Auth: Patch for storing user

Here is my patch for Auth.pm, which stores the authenticated user in the Session Notes, which can be later used by plugins like my 'maillog'. I would be thankful if this would be included into the upstream Auth.pm. --- /usr/src/qpsmtpd/lib/Qpsmtpd/Auth.pm2004-07-29 16:40:32.0 +020

Re: SMTP Auth: Patch for storing user

> Michael - I wonder if your quest to create a summary log wouldn't be better > served if the ->log call itself were extended with your own code. What I > am considering is that log() itself would have hooks that could be > registered: your code could then collect the lines it was interested in

Re: mailgraph integration

> >BTW, is trunk working again, then? Excuse my ignorance, but: What is trunk? I might have missed something. -kju -- It's an insane world, but i'm proud to be a part of it. -- Bill Hicks

Re: Files left in ~smtpd/tmp

> This has come up quite a few times, but with no resolution. Is anyone > else getting files filling up ~smtpd/tmp? Over the last few days we've had > literally gigabytes on a single relay. Hmm, qpsmtpd left 34 files since July 29th, but as i have a throughput of arround 2000 mails per day this

Re: Are single character sub-domains allowed in the envelope?

> That to me looks like a sub-domain *can* consist of a single character? Yes, thats fully standards conform and not too unusual. -kju -- It's an insane world, but i'm proud to be a part of it. -- Bill Hicks

Re: Files left in ~smtpd/tmp

> This relay is handling 60-80K connections per day. The files seem to be a > repetition of the same email repeatedly failing e.g. No, it is not the same message, it is just failing after the same amount of data. I have some files of the same size too, but all are different messages truncated in t

Wiki totally filled with Spam

The plugin developer Wiki has totally been taken over by Spammers who removed virtually any content by their shit. Until this get fixed (eg. by installing a Wiki which needs a user account or something like that) i suggest removing the link from the qpsmtpd-Homepage. Additional i would be thankful

DNS Blocking lists also blocking authorized clients

I have added some dns blocking lists which lists for example dialup ips. But now even my authorized clients can not send mail over me when they come from one of these blocked IPs. Blocking plugins should probably check for $ENV{RELAYCLIENT} and $transaction->relaying. -kju -- It's an ins

Re: DNS Blocking lists also blocking authorized clients

> Blocking plugins should probably check for $ENV{RELAYCLIENT} and > $transaction->relaying. I also suggest splitting the "check_relay" plugin into two parts. One part which checks $ENV{RELAYCLIENT}, relayclients and morerelayclients and sets transaction->relaying accordingly, but DECLINING anyway

Re: DNS Blocking lists also blocking authorized clients

> Blocking plugins should probably check for $ENV{RELAYCLIENT} and > $transaction->relaying. Ok, i've done the changes. Please find attached: - a patch for dnsbl which adds a check for transaction->relaying - a plugin check_relayclient which should be called as the very first one in rcpt

Re: DNS Blocking lists also blocking authorized clients

> - a plugin check_relayclient > - a plugin check_relayfinal Forgot to correct the comments in the plugins, so i've attached two new versions. -kju -- It's an insane world, but i'm proud to be a part of it. -- Bill Hicks # # check_relayclient # # this plugin checks $ENV{RELAYCLIENT}

Re: DNS Blocking lists also blocking authorized clients

> Hmmm. Might work better if you used a positive list instead of a > negative list. That way you could more easily choose where you get your > mail from. For clients coming from some (prior unknown) dialup isp with dynamic isp whitelists are impossible. -kju -- It's an insane world, bu

Re: DNS Blocking lists also blocking authorized clients

> 1: Why call the first one in the rcpt chain at all? Just make it a > connect plugin. I could do this, and in fact i have attached an modified version of 'check_relay' which just does that. As it has otherwise the complete same functionality as 'check_relay', you might think about replacing the

Re: DNS Blocking lists also blocking authorized clients

> I think i already suggested adding a connection->relaying flag, which > value is copied to transaction->relaying when a new transaction is startet. > This would allow us to get rid of using $ENV{RELAYCLIENT} as a flag, we > just should set it right before calling a queue plugin. If the others ag

Logging rejected Mails

I like to log mails i rejected for content reasons (virus, spam score). But as i do not want to crank up loglevel (and this would also not give a nice compact log entry), i modified both clamav and spamassassin to make a log entry with an configurable priority (configure in 'loglevel_reject'). Exam

Even More Reject-Logging (was: Re: Logging rejected Mails)

I added the same logging functionality to dnsbl and rhsbl to see rejected mails by this plugins as well (i use this to check for false positives, it gives me a better feeling to have logged this rejects). I also slightly fine-tuned the format printed out by spamassassin and clamav. Log entry exam

Re: DNS Blocking lists also blocking authorized clients

> The default relaying setting is based on IP, which is part of the > connection. But is AUTH part of the connection or part of the > transaction? After SMTP AUTH has been completed successfully, the client becomes an relayclient of the rest of the connection. Currently we do this by setting $EN

Re: Even More Reject-Logging (was: Re: Logging rejected Mails)

> Looks like you could do this a bit cleaner with a deny hook. Sound like a good idea, but when trying to register a plugin: Sep 19 15:33:45 mir qpsmtp: denylog : Invalid hook: deny at lib/Qpsmtpd/Plugin.pm line 19. Something broken? -kju -- It's an insane world, but i'm proud to be a

Re: Even More Reject-Logging (was: Re: Logging rejected Mails)

> Something broken? Fix: --- Plugin.pm.orig Sun Sep 19 15:37:03 2004 +++ Plugin.pm Sun Sep 19 15:40:25 2004 @@ -4,7 +4,7 @@ my %hooks = map { $_ => 1 } qw( config queue data data_post quit rcpt mail ehlo helo auth auth-plain auth-login auth-cram-md5 -connect reset_tr

New plugin 'denylog'

In response to Matts suggestion of doing the logging in a deny hook, i just created a 'denylog' plugin, which can be configured for which plugins a deny should be logged and with which loglevel. It can also help catching your own users doing abuse (see below). You can find the plugin here: http:/

Patch for 'spamassassin'

I suggest the following patch for spamassassin, which will also log the actual spam score and threshold: --- spamassassin.orig Sun Sep 19 16:04:34 2004 +++ spamassassinSun Sep 19 16:05:20 2004 @@ -179,8 +179,9 @@ my $score = $self->get_spam_score($transaction) or return DECLINED; $

Re: check_relay

> Unfortunately, it caused problems with the flow because check_relay does > two conflicting functions: > 1) sees if the IP address can relay > 2) sees if the domain is acceptable This is related to my suggested change a few days ago. > 1) check_relay now only sees if the IP address can relay H

Re: check_relay

> No, I didn't see a reason to make it a connect plugin, perhaps you can > argue that point. The IP address will stay same for the whole session. It does not make sense to call the plugin for every rcpt to. > I'll was also going to take a look at making $transaction->relaying(1) > actually aff

Re: check_relay

> Another thing to consider if we are changing some of this anyway would > be renaming relaying to something else. ("relaying_allowed"?) Or am I > the only one who finds "relaying" alone really backwards? Agreed. I would vote for the classic 'relayclient' :-) -kju -- It's an insane wo

Re: check_relay

> it sets the $connection->{_relay_client} variable to 1 > 2) Qpsmtpd/Connection.pm now includes a relay_client() method (guess what > that does ;). Hmm, this seams to be a major change from the current handling. Currently we call a function to set relaying ($transaction->relaying(1)), and dire

Re: check_relay

> set_relay_client(); > if ( is_relay_client() ) { ... } Of course with $connection-> or $qp->self->connection-> prefix. -kju -- It's an insane world, but i'm proud to be a part of it. -- Bill Hicks

Re: check_relay

> I like that rcpt_ok is named different from the other check_* plugins; it calls > attention to the fact that something special is happening here... Maybe call it 'rcpt_final'? -kju -- It's an insane world, but i'm proud to be a part of it. -- Bill Hicks

Re: Hmm, bounce_verp

> That's sad, I really think that BATV/VERP is the best thing since sliced > bread. Never heard of that, any pointer to an doc whats this about? -kju -- It's an insane world, but i'm proud to be a part of it. -- Bill Hicks

Re: connection->relay_client and check_relay/rcpt_ok committed to CVS

> Does anyone have a strong opinion? My 2 ct (EUR of course): Ditch transaction->relaying. -kju -- It's an insane world, but i'm proud to be a part of it. -- Bill Hicks

Bug in plugin 'spamassassin'

I believe there is a bug in the 'spamassassin' plugin. It seems to leave older 'X-Spam-Status' Header lines added by another System intact, and add his own 'X-Spam-Status' Line, leaving the mail with two different X-Spam-Status. This should never happen, old X-Spam-Status Lines need to be removed

Re: Bug in plugin 'spamassassin'

> I believe there is a bug in the 'spamassassin' plugin. It seems to leave > older 'X-Spam-Status' Header lines added by another System intact, and add > his own 'X-Spam-Status' Line, leaving the mail with two different > X-Spam-Status. This should fix it: --- spamassassin.orig Wed Sep 22 23:08

Re: Mystery messages

> I'm pretty sure that an empty body is valid RFC2821. This is because RFC2821 is indifferent about what it transports. In fact it does not even need to be a RFC2822 style message. Section 3.3 says: |When RFC 822 format [7, 32] is being used, which makes clear that it does not have to be us

Re: Mystery messages

> For one thing, confirmation messages to scripts are often legally empty > - the scripts rely only on data in the headers including the Subject > header. We were talking about _complete_ empty mails, which do not even contain a header and are 0 Bytes in total. -kju -- It's an insane wo

Re: Mystery messages

> >Server SMTP systems SHOULD NOT reject messages based on perceived > >defects in the RFC 822 [...] > Except it's not an empty MIME body; it is no header or body data at all. > But you did lead me to the appropriate citation (from RFC-2822 3.6): ..

Re: cvs commit: qpsmtpd/plugins spamassassin

> Personally I have only modified the SA plugin to replace the > X-Spam-Status header while leaving the other pre-existing headers > intact, but in fact it should be possible to avoid even this by > modifying sub get_spam_score() to retrieve only the most > recent X-Spam-Status header. No. 1.)

Re: Mystery messages

> Michael Holzt wrote: > >>>Server SMTP systems SHOULD NOT reject messages based on perceived > That's SHOULD NOT and not MUST NOT. You should check RFC2119 what the phrase "SHOULD NOT" means exactly in an internet standard: | 4. SHOULD NOT This phrase, or

Re: cvs commit: qpsmtpd/plugins spamassassin

> How about making it an option to the SA plugin then? You set it, it > replaces the headers; you don't set it, the new headers are added? And here we are (warning: untested). --- /home/kju/qpsmtpd/qpsmtpd-cvs/plugins/spamassassin 2004-09-24 18:41:51.0 +0200 +++ spamassassin20

Re: cvs commit: qpsmtpd/plugins spamassassin

> > 2.) X-Spam-Status does not contain an identifier which allows > > to check for a specific hosts scoring. > Trivial to add one. Can still be forged. -kju -- It's an insane world, but i'm proud to be a part of it. -- Bill Hicks

Re: cvs commit: qpsmtpd/plugins spamassassin

> And here we are (warning: untested). Arrgl. Missed to change the last two replace by add. See attached for the correct diff. -kju -- It's an insane world, but i'm proud to be a part of it. -- Bill Hicks --- /home/kju/qpsmtpd/qpsmtpd-cvs/plugins/spamassassin 2004-09-24 18:41:51.

Re: cvs commit: qpsmtpd/plugins spamassassin

> It seems unlikely that spammers would forge X-Spam-Status headers that > mark the message as being spam. Of course there are no guarantees, but > at this stage I have little reason to disbelieve such headers. So you would believe a 'X-Spam-Status: No, hits=0 [...]" line forged by a spammer? Thi

Re: Mystery messages

> Empty messages (no data at all) are irretrievably broken. There is no > diagnostic information available in the message (since there isn't one). A message does not need "diagnostic information" to have a purpose. Everything related to mail transport (and _thats_ what the qpsmtpd core is about

Re: cvs commit: qpsmtpd/plugins spamassassin

> Perhaps if the spamassassin module stored the local spamd scoring in the > transaction header we wouldn't have to re-scan to find the value. I could > think of other modules I use which would find the spamd score useful. Agreed, but this is unrelated to the header issue, because the multiple h

Re: Are single character sub-domains allowed in the envelope?

> and it did seem to correctly match the pattern we are looking for. I've > put it into production here (after testing it); shall I commit the change? I'm still trying to decode that regexp (will have a look in the camel book later), but if it works: go for it :) -kju -- It's an insane

Re: Are single character sub-domains allowed in the envelope?

> Sorry, this is better (I think): I'm not sure. But i honestly do not understand the whole canonify routine, but some things i observed about your regexp: > my $subdomain = qr' > (?: # group but no backreferences > [a-zA-Z0-9]+? # match one or more ALPHA / DIGIT

Re: Are single character sub-domains allowed in the envelope?

> > my $subdomain = qr' > > (?: # group but no backreferences > > [a-zA-Z0-9]+? # match one or more ALPHA / DIGIT > ..^ > > Why a + here? I tried your regexp in a test programm, and for a testdomain > 'bla.fasel.org' this had the effect, that only

Re: Trohpie Plugin for qpsmtpd

> Hello everyone. Just want to start by saying that I think qpsmtpd > is an absolutely awesome smtpd server. I have been working with > it for a little while now and decided that it needed a trohpie > plugin so I wrote one for it. Care to explain what trophie is? I'm sure i'm not the only one w

Some (unfinished) thoughts about configuration and per user configuration

Summary first: I think the current configuration system is getting more and more messier as new plugins are added, it has some shortcomings and the possibility for a per user configuration is a good idea for many uses. Let me think about it step by step: 1. With every new plugin we end up wit

Re: Some (unfinished) thoughts about configuration and per user configuration

> I think the general direction we agreed to go earlier is to develop a > configuration interface such that everyone can have what they want. This is what my proposed "conf" hook would allow. -kju -- It's an insane world, but i'm proud to be a part of it. -- Bill Hicks

Re: Some (unfinished) thoughts about configuration and per user configuration

> This is what my proposed "conf" hook would allow. Oh, it seems i have missed that a "config" plugin is already present. But it seems this currently does not provide enought information for the different things i proposed. I will play around with that and see what i can do. -kju -- It's

Re: Are single character sub-domains allowed in the envelope?

> I don't understand what problem you and Michael are trying to > solve with the messages after this one. What doesn't match? The old code did not match for single character sub-domains. > All the examples you provide match fine, assuming we're talking > about /^$subdomain(?:\.$subdomain)*$/.

Re: Mystery messages

> I'd like to hear a valid reason you actually want these messages. And a > serious example of when you might, not just quoting RFCs again. I can't. But sorry: I really do not feel an urge to break RFCs in the qpsmtpd core. After all we still do not know whats the reason for that broken mails, a

Re: Some (unfinished) thoughts about configuration and per user configuration

> >This is what my proposed "conf" hook would allow. > And like magic, there already is a config hook :-) Yes, after having some hours of sleep and with the hint in the other mail i found out about that too :-) But currently it seems unable to fulfill my requirements. The config hook plugin does

Re: Some (unfinished) thoughts about configuration and per user configuration

> This I can confirm at any rate. All rcpt plugins get called after the > client has sent the RCPT TO: line but before qpsmtpd has acknowledged that > the rcpt is valid or not. Otherwise what would be the point... So i would need to send the current (not already processed) recipient also to the

Re: Some (unfinished) thoughts about configuration and per user configuration

> > It would almost be better to fork the message handling after the rcpt > > phase and effectively do a single delivery for each rcpt. On the other hand: In a per-user config environment it might make sense to do not have any configuration dependant datapost plugin (like spamassassin or clamav)

Re: Some (unfinished) thoughts about configuration and per user configuration

> I don't quite see why a config hook plugin should have to know from > which plugin or hook it is called. See my posting yesterday. With every new plugin we are running into the danger of having collisions within config names. This could be solved by either prepending 'pluginname_' to each config

Re: Some (unfinished) thoughts about configuration and per user configuration

> On purpose. I think that depending on plugin and hook is horrible, and > if you really want to do that, you should have to write it explicitly. Knowing which hook it was is not really necessary. > Namespaces are fine. If every plugin starts, by convention, all its > configuration parameters wi

Re: Mystery messages

> i.e. nothing in the DATA section whatsoever. This isn't "legitimate > mail" in any sense whatsoever (since there's no mail there, only an > envelope). It's completely illegitimate. It violates RFC 2822. I think we all agreed on that. However: As i already pointed out, i believe that RFC 2821

Re: (again) Proposed Patch for Spamassassin

> I still think that the patch should emulate current behavior as a default, > i.e. anyone upgrading /now/ should get the current SA plugin behavior, no > matter how much I prefer stripping the previous headers. In my opinion the current behaviour is bad, wrong, unusual and dangerous and we shou

Re: (again) Proposed Patch for Spamassassin

> 2) I am only stating that the behavior of _Qpsmtp_ will change if the > default behavior of the _SpamAssassin_ plugin is changed. I agree with > Michael that the current behavior of Qpsmtpd/SA is arguably wrong, but > it _is_ the current behavior and I question whether it should be > casuall

Re: (again) Proposed Patch for Spamassassin

> If Robert is happy with the ability to preserve the headers, but having > the default behavior change, I'm satisfied and would commit the change. So Robert, please make a comment on this. -kju -- It's an insane world, but i'm proud to be a part of it. -- Bill Hicks

Updated proposed fix for spamassassin

Now that we got quorum from two spamassassin maintainers, i've updated my patch accordingly. The parameter is now a string, either: "keep", "rename" or "drop". Default is now "rename". Patch is attached. -kju -- It's an insane world, but i'm proud to be a part of it. -- Bill Hicks diff -

Re: New plugin 'denylog'

> I'm guessing I include "denylog" in the /config/plugins file, but where? As this is a plugin for the deny chain, and is independent of other plugins (you probably don't have another deny chain plugin anyway), it does not matter. I've always felt that the stock config/plugins file order is not v

Re: New plugin 'denylog'

> How does denylog_level relate to loglevel? It will set the loglevel which denylog uses to log. This is because you normally have the loglevel on a rather high level because you do not want all the trash in the logfile. So denylog must log at a high level too, to appear in the logfile. -kju -

Re: SpamAssassin 3.0

> Has anyone tried to run this with qpsmtpd yet? and if so what plugin > works the best with it? I have it running with the standard spamassassin plugin. My config entry is: 'spamassassin reject_threshold 8 spamd_socket /etc/mail/spamassassin/spamd.socket'. I'm very impressed with SpamAssassin 3

Re: SpamAssassin 3.0

> I know this is kind of off subject from my original post, but is there any > software/plugins which will give you stats as far as rejected/accepted > messages then break it down as far as sa/rhsbl/dnsbl? I'm not sure if this is what you want, but i think you are looking for my plugins 'maillog'

Re: Getting around DUL blocks

> I want to set up qpsmtpd to try direct smtp first, and on failure, > use comcast's smtp (they rate limit pretty tightly, so I can't > send all mail this way). The delivery of mails to remote addresses is not covered by qpsmtpd but by your MTA (e.g. qmail, postfix). So qpsmtpd is not responsibl

Re: A test when DATA is called, but before data is posted?

> > There is a "data" hook in CVS. > But doesn't that run _after_ the data is received, i.e. when > the . is posted? No, thats what the datapost-hook is for. Please read the docs. -kju -- It's an insane world, but i'm proud to be a part of it. -- Bill Hicks

Re: Per Domain Config

> You might try my per_user_config plugin available here: > http://www.openfusion.com.au/labs/qpsmtpd/ Some time ago i tried to get it running with the latest CVS version but had no lock. Has this changed? -kju -- It's an insane world, but i'm proud to be a part of it. -- Bill Hicks

Re: check_relay - strange behavior

> I have a bit of a different plugin running that handles > pop-before-smtp by reading a list of recent IPs that have popped an > account, and if there is a match with the connecting IP, it sets a > transaction note: You might want to try out my 'qppoprelay' plugin which just does that, and

Re: "greylisting"

> http://www.greylisting.org/ I have another interesting URL for you: http://smtpd.develooper.com/ If you would care to READ first, you would have noticed, that greylisting is nothing new for us, and a plugin was available for many months already. Regards Michael -- It's an insane world,

Re: "greylisting"

> I tried greylisting for two months on my primary mail server. I enjoyed > the (slight) reduction in spam but I also couldn't live with important > emails being deferred and not tried again. This is common with > financial institutions, for exactly the same reasons they stamp things > like

Re: develooper.com down?

> develooper is back up for me at least, so you can try CVS again. By the way, i registered qpsmtpd.org some time ago, and installed it so that www.qpsmtpd.org redirects to the develooper page. > FWIW, I've abandoned SpamAssassin in favor of dspam: > > whi

clamav plugin broken

It seems that the invocation of clamav in the current plugin is using deprecated parameters: Feb 14 23:00:53 zeus qpsmtpd: WARNING: Ignoring option -i: please edit clamd.conf instead. Feb 14 23:00:53 zeus qpsmtpd: WARNING: Ignoring option --max-recursion: please edit clamd.conf instead. I was a

Re: fuzzy honeypot detects dictionary spam

> >Right now all I can say is "kathey" is invalid, but might be > >a mis-spelling of "cathy" by a harmless stalker. You might want to check soundex coding which should catch such errors. Regards Michael -- It's an insane world, but i'm proud to be a part of it. -- Bill Hicks

Re: [ANNOUNCE] qpsmtpd 0.29

> 0.29! I haven't announced it on Freshmeat or even on the website yet. Congratulations! Regards Michael -- It's an insane world, but i'm proud to be a part of it. -- Bill Hicks

Re: queue/maildir spooling for spamassassin report

> I would add a line to queue/maildir to check if a third plugin > had set a note for queue/maildir to spool a spam message > for spamassassin -r. You should _never_ use -r to report spam which was automatically detected (e.g. by a plugin). Read the manpage: -r, --report Report this mess

  1   2   3   >