On 2007-02-02 23:53:41 +0100, Hans Salvisberg wrote: > Thank you for your detailed reply, Peter! > > Peter J. Holzer wrote: > >"/denysoft_greylist.dbm" within the config directory is used. > > According to the various installation HOWTOs, the config directory > (/etc/qpsmtpd in my case) should be set like > > drwxr-x--- 2 root smtpd 1024 Feb 2 12:15 qpsmtpd > > so it's not writable for smtpd.
I thought about adding that I wouldn't recommend that, but then didn't. I really think the db_dir and the config dir should be separate, and that the config dir should not be writable for smtpd. However, there is no default place for a database directory (hmm, we could use spool_dir), so I never changed that as the last fallback. Historically, the config dir was writable as the installation instructions recommended to simply extract the tarball in the qpsmptd user's home directory as that user. Even if it isn't you could still have files writable to that user in the config dir, qpsmptd just can't create them itself. > >> -- what's the name and format of your whitelist? [...] > >The client_options connection note is set by the client_options plugin. > >The config file (also named client_options) looks like this: > > > >62.225.35.170: check_rfc2821_strict_colon_param/skip=1 > >62.72.108.248: denysoft_greylist/skip=1 > >62.72.116.58: denysoft_greylist/skip=1 > >62.99.159.78: denysoft_greylist/skip=1 > >64.125.133.202: denysoft_greylist/skip=1 > >64.233.170.192/28: denysoft_greylist/skip=1 > >66.218.66.64/26: denysoft_greylist/skip=1 > >66.28.250.19: denysoft_greylist/skip=1 > >80.110.228.110: denysoft_greylist/skip=1 > >81.223.132.220: require_resolvable_client/skip=1 > >143.130.16.50: denysoft_greylist/skip=1 > >143.130.16.51: denysoft_greylist/skip=1, relay_client=1 > >143.130.16.52: denysoft_greylist/skip=1, relay_client=1 > >[...] > > Wow, that looks very versatile. I'll install your version, but I'll need > more time than I have right now. When looking at your listing and at > http://cvs.puremagic.com/viewcvs/greylisting/schema/whitelist_ip.txt > the obvious question is: does your format allow appending a #comment at > the end of each line? Unfortunately, no. It uses the normal config file mechanism, which allows for full line comments and inclusions, so you can do something like # Google: 64.233.170.192/28: denysoft_greylist/skip=1 # Yahoo: 66.218.66.64/26: denysoft_greylist/skip=1 66.28.250.19: denysoft_greylist/skip=1 80.110.228.110: denysoft_greylist/skip=1 $include relay_clients but no inline comments. I can add that, though - thank's for the suggestion. > >As you can see, CIDR notation (e.g., 66.218.66.64/26) is permitted so > >you can whitelist large server farms (66.218.66.64/26 is Yahoo groups, > >IIRC) in a single line. The options are comma-separated and the / > >separates the levels in a hash of hashes. so the client_options note for > >143.130.16.52 gets set to > > { > > denysoft_greylist => { skip => 1 }, > > relay_client => 1 > > }. > > Yes, CIDR notation is great! > > But client_options is not a standard, or is it? I mean it can only > control those plugins that specifically check for it, right? Yes, but that's the price you pay for the flexibility. Neither the core nor the client_options plugin knows what the note means and which plugin (if any) is oing to use it. Some meanings like "skip this plugin" are probably frequent enough that they can be solved in a more generic way (e.g., with wrapper plugins). > >>Your description on the web page seems to indicate that your whitelist > >>mechanism does not use "whitelist_soft", yet the description inside the > >>file mentions only "whitelist_soft". > > > >I'll remove the reference to "whitelist_soft", that's at least outdated > >(I don't remember if my version ever supported it). The client_options > >transaction note is documented, but may be easy to overlook (especially > >if one looks for "whitelist"). > > I've been playing a bit with whitelist_soft, and it's useful for > hand-tuning a low-volume MTA such as mine. IIRC (its been a long time since I looked at it) whitelist_soft has an "all or nothing" approach. Either a client is on the whitelist or it isn't. If it is, all plugins which check the whitelist will be disabled. I can't do things like disable greylisting but keep spamassassin for client A, but disable spamassassin for client B. > In another thread you recently opposed rejecting all bounces because > they provided important information. Here's an interesting observation: > I've had a steady stream of mis-directed bounces, and installing > greylisting has cut that down by 95%. This could mean two things: either > those were all faked bounces (spam delivered under the guise of a > bounce), or the bouncers rarely try again and you're likely to lose a > significant portion of legitimate bounces by greylisting. I know some MTAs are treating bounces differently than "normal" messages: They expire faster and the queue run intervals may be longer. So you might lose more legitimate bounces than legitimate normal messages through greylisting. You probably should try to find out the reason. hp -- _ | Peter J. Holzer | I know I'd be respectful of a pirate |_|_) | Sysadmin WSR | with an emu on his shoulder. | | | [EMAIL PROTECTED] | __/ | http://www.hjp.at/ | -- Sam in "Freefall"
signature.asc
Description: Digital signature
