Re: Whitelisting
On Thu, 06 Sep 2007 10:11:38 -0700 JT Moree [EMAIL PROTECTED] wrote: My idea would be that there are only two things that can be whitelisted: connections and transactions. On the base of what logic, and at what stage, is up to the plugin, but if the whitelist flag is set, any DENY* return value from subsequent plugins' hooks should be treated as DECLINED. The real question is what does whitelisting mean? This is one thing it can mean. It could also mean that a plugin MUST return DECLINED when the whitelist flag is set. Your case allows for OK. My case does not. (I kinda like yours better). [...] The problem seems to be that whitelisting means different things to different plugins. I started thinking of creating a whitelisting subsystem where each plugin could share in a global whitelist or have one of it's own. If we can narrow the definition, scope, and effects of 'whitelisting' it may then be possible to implement something that all/most plugins could use. I'm not really happy with the all or nothing approach of whitelisting / blacklisting. There should be a score based whitelist, which can be fine tuned by the admin. The current dnsbl plugin returns DENY if the client is in one of the given lists, but there are some lists I trust more than others. I'd like to see something where I can set a score right below the threshold for (e.g.) the geoip plugin and then add the scores from the dnsbl plugin. Whitelisted clients can be given a large negative score, that this client never reaches the threshold of being blocked. Hanno
Re: Whitelisting
On Sat, Sep 15, 2007 at 08:27:19AM +0200, Hanno Hecker wrote: I'm not really happy with the all or nothing approach of whitelisting / blacklisting. There should be a score based whitelist, which can be fine tuned by the admin. Blacklisting and whitelisting _are_ all or nothing, by definition. They're absolute concepts. Scoring based on (other people's) blacklists also makes sense though - I do that with dnsbl, as you suggest. But that's not whitelisting, it's something different. qpsmtpd needs both. Cheers, Gavin
Re: Whitelisting
On 15-Sep-07, at 2:27 AM, Hanno Hecker wrote: The current dnsbl plugin returns DENY if the client is in one of the given lists, but there are some lists I trust more than others. I'd like to see something where I can set a score right below the threshold for (e.g.) the geoip plugin and then add the scores from the dnsbl plugin. Whitelisted clients can be given a large negative score, that this client never reaches the threshold of being blocked. Why not just use SpamAssassin for that?
Re: Whitelisting
Fuelled by some of the recent discussions, I think the whitelisting concept needs to be re-thought. i agree My idea would be that there are only two things that can be whitelisted: connections and transactions. On the base of what logic, and at what stage, is up to the plugin, but if the whitelist flag is set, any DENY* return value from subsequent plugins' hooks should be treated as DECLINED. The real question is what does whitelisting mean? This is one thing it can mean. It could also mean that a plugin MUST return DECLINED when the whitelist flag is set. Your case allows for OK. My case does not. (I kinda like yours better). Maybe, for the sake of efficiency, we could think of a mechanism for some plugins that only to checking (no logging and no queuing) to be bypassed altogether when whitelisting is in effect. The problem seems to be that whitelisting means different things to different plugins. I started thinking of creating a whitelisting subsystem where each plugin could share in a global whitelist or have one of it's own. If we can narrow the definition, scope, and effects of 'whitelisting' it may then be possible to implement something that all/most plugins could use. -- JT Moree
Re: Whitelisting
On 6-Sep-07, at 11:33 AM, Johan Almqvist wrote:
My idea would be that there are only two things that can be
whitelisted: connections and transactions. On the base of what
logic, and at what stage, is up to the plugin, but if the whitelist
flag is set, any DENY* return value from subsequent plugins' hooks
should be treated as DECLINED.
The way I see it is that whitelisting is basically meant as a bypass
for anti-spam filters, but not (for example) certain other filters
(like recipient checks). So I wondered if hooks should declare
themselves as skippable if whitelisted, via sub attributes:
sub hook_helo : skip_if_whitelisted {
...
}
Or something like that.
Re: Whitelisting
On 6-Sep-07, at 1:47 PM, Johan Almqvist wrote: Matt Sergeant wrote: The way I see it is that whitelisting is basically meant as a bypass for anti-spam filters, but not (for example) certain other filters (like recipient checks). So I wondered if hooks should declare themselves as skippable if whitelisted, via sub attributes: I agree. But can't this be achieved by ordering the plugins in such a wat that the non-skippable get loaded before the whitelisting and the skippable ones get loaded after, and the whitelisting plugin returning something like OK_BUT_NOT_QUEUED - then we only need one attribute, 'queues' to mark plugins that do the queueing. Nope, because ordering doesn't help when you have a data_post plugin come before a helo plugin. Matt.
Re: whitelisting recipients
csere matyas wrote: we have a client that doesnt want to loose any mail, and asked us not to scan any mail addressed to him. is there a way to do recipient whitelisting, eg if the mail is to [EMAIL PROTECTED] it would always pass, and get delivered? Make a copy of plugins/check_badrcpto and replace 'bad' with 'good' everywhere. Then change the code that returns no_such_user and replace it with return OK instead. Lastly, make sure that this is the first rcpt hook that is loaded (basically move it higher in the config/plugins file). However, this will only shortcircuit the rcpt tests. If you have any blacklists running at connect time, there is no general way to stop them from blocking messages (since you haven't found out the RCPT yet). Similarly, if you are running any antivirus plugins (and you should at least run clamav since it costs you nothing), you should not send those messages on (it would be grossly irresponsible). If I was in this situation, I might be inclined to suggest that this client take his business elsewhere, as he is part of the problem. There are so many messages that can be safely blocked during SMTP, with almost neglible false positives, and plenty of spam that still gets through. The only times I have had legit messages get blocked, I determined later that it was due to gross misconfiguration of the remote MTA. And I am in a corporate environment where lost messages are not acceptable either. John p.s. Please start a completely new thread, not by replying to a previous message. Most mail/news clients thread using hidden headers, so changing the subject line is not sufficient to start a new thread.
Re: whitelisting recipients
On 2006-01-31 11:09:55 +0100, csere matyas wrote: we have a client that doesnt want to loose any mail, and asked us not to scan any mail addressed to him. is there a way to do recipient whitelisting, eg if the mail is to [EMAIL PROTECTED] it would always pass, and get delivered? Gavin Carr's whitelist_soft may be what you are looking for[1] (see http://www.openfusion.com.au/labs/qpsmtpd/). For more fine-grained control, you might want to look at my aliases* plugins[2], which allow you to attach arbitrary labels to recipients which can then be checked by other plugins (I use this to select greylisting and some body scans only for selected recipients). Since you write scan any mail: Be aware that you can only return a single success code after receiving the header and body of the mail. If a single mail is addressed to [EMAIL PROTECTED] and [EMAIL PROTECTED], you can only accept the mail for both or reject it for both if the rejection is based on the content of the mail. There are ways around this limitation[1][3], but they involve temporary rejections, and some (broken) MTAs don't handle them gracefully, so that may not be acceptable if you absolutely cannot afford to lose legitimate mails. Assuming that your client has a domain of its own its probably simplest to set up a second MX without any filters. hp [1] http://www.openfusion.com.au/labs/qpsmtpd/ [2] http://www.hjp.at/projekte/qpsmtpd/aliases/ [3] http://www.hjp.at/projekte/qpsmtpd/cf_wrapper/ -- _ | Peter J. Holzer| Ich sehe nun ein, dass Computer wenig |_|_) | Sysadmin WSR | geeignet sind, um sich was zu merken. | | | [EMAIL PROTECTED] | __/ | http://www.hjp.at/ |-- Holger Lembke in dan-am pgpH73KSTKhLD.pgp Description: PGP signature
Re: whitelisting an ip in china
On Thu, Jan 29, 2004 at 04:38:24PM +0200, Aric Fedida wrote: So now the question is, how do I whitelist a certain ip address, so that qpsmtpd plugins will be bypassed for that ip address? As a halfway measure, you could whitelist their HELO with the whitelist plugin I posted here a while back. Whitelisting a remote host is a valid case, I'll see what would be involved there. -- Devin \ aqua(at)devin.com, 1024D/E9ABFCD2; http://www.devin.com Carraway \ IRC: Requiem GCS/CC/L s-:--- !a !tv C$ ULB+++$ O+@ P L+++ signature.asc Description: Digital signature
Re: whitelisting an ip in china
[crass self reply] On Thu, Jan 29, 2004 at 11:02:49AM -0800, Devin Carraway wrote: As a halfway measure, you could whitelist their HELO with the whitelist plugin I posted here a while back. Whitelisting a remote host is a valid case, I'll see what would be involved there. Okay, I feel stupid. Code to do this is already in the whitelist plugin -- drop their IP in the whitelisthosts file and it'll work fine. -- Devin \ aqua(at)devin.com, 1024D/E9ABFCD2; http://www.devin.com Carraway \ IRC: Requiem GCS/CC/L s-:--- !a !tv C$ ULB+++$ O+@ P L+++
Re: Whitelisting and scoring (was: denysoft_greylist: concurrent access to dbm file? [patch])
Peter,
Your scoring suggestion wouldn't be hard to implement.. every
plugin can return DECLINED and set a score in the -{notes} data
structure somewhere. The last plugin to run can look at the score
and decide to (OK,DENY).
But I wouldn't want that to be the default. At the SMTP layer
there are too many absolutes, so it makes the most sense to just
(OK,DENY) immediately -- the following tests won't necessarily
have an impact. A lot of things are orthogonal.
The (or a) reason SpamAssassin uses scoring is because there are
multiple rules working on the same dataset... and a lot of the
rules are fuzzy, they only make sense when combined with others.
But (for example) if someone is listed in dsn.rfc-ignorant, I
don't care whether or not they're in MAPS.. I'm going to reject
them immediately.
As for individual users turning on and off plugins... that's a
nice thought.. but qmail's flexibility makes it very hard to map
an email address to a user just by looking at the MAIL TO: data.
In your use case, you may be able to do this... but it doesn't
really work in the general case.
It really sounds like you want a custom set of plugins for your
site.
-R
Re: Whitelisting and scoring
On 2003-09-20 09:13:48 -0700, Robert Spier wrote:
Your scoring suggestion wouldn't be hard to implement.. every
plugin can return DECLINED and set a score in the -{notes} data
structure somewhere. The last plugin to run can look at the score
and decide to (OK,DENY).
Yup, that's the easy part. Coming up with a suitable scoring system is
much tougher, IMHO.
But I wouldn't want that to be the default. At the SMTP layer
there are too many absolutes, so it makes the most sense to just
(OK,DENY) immediately -- the following tests won't necessarily
have an impact.
In that case just add a value larger than the threshold (and implement a
shortcut that will immediately issue a 4xx or 5xx in that case).
A lot of things are orthogonal.
Which doesn't mean that a metric which combines them is useless. In
geometry, x and y are orthogonal - yet the euclidian distance
sqrt(x^2+y^2) is often a more useful metric than the x and y coordinates
alone.
The (or a) reason SpamAssassin uses scoring is because there are
multiple rules working on the same dataset... and a lot of the
rules are fuzzy, they only make sense when combined with others.
But (for example) if someone is listed in dsn.rfc-ignorant, I
don't care whether or not they're in MAPS.. I'm going to reject
them immediately.
You may not care, others do. In my opinion, RBLs are not dependable
enough to reject a mail based on a single hit (Osirusoft demonstrated
that rather spectacularly a few weeks ago). They are also fuzzy:
Just because most of them use hard, technical criteria like is an
open relay, is a dial-up address, doesn's accept DSN, doesn't
mean that they can accurately determine whether the mail coming from
the server is legitimate. A mail coming from an open relay has a
much higher chance of being spam, but it is not 100%. Some of the
larger (and usually cheaper, and less competent) ISPs here are almost
permanently in postmaster.rfc-ignorant.org, abuse.rfc-ignorant.org or
unconfirmed.dsbl.org, which makes these BLs completely unsuitable as
absolute criteria (I can't shut out 50% of all people who would like to
send us mail), but they would still be useful as additional hints.
As for individual users turning on and off plugins... that's a
nice thought.. but qmail's flexibility makes it very hard to map
an email address to a user just by looking at the MAIL TO: data.
You might want to distinguish by mail address anyway, and not by user:
The same user might want to have different rules for different mail
addresses (e.g., you may want your postmaster address completely
unfiltered, the address you give your business partners with only very
conservative checks, and the address you use on usenet with very
aggressive filters).
It really sounds like you want a custom set of plugins for your
site.
That's what the prototype implementation will be, anyway. But to be
generally useful, the mechanism should be provided by qpsmtpd, to
provide a standard which plugins can use.
hp
--
_ | Peter J. Holzer| Wie sagt ihr zu der Mehrzahl von Mozilla?
|_|_) | Sysadmin WSR | Jurassic Park.
| | | [EMAIL PROTECTED] | -- Alexander Skwar und Ruediger Lahl
__/ | http://www.hjp.at/ | in dcsmm.
pgp0.pgp
Description: PGP signature
