KLaM Postmaster a écrit : > First of all let me apologize if you have seen this "request/query" > before. I originally posted this to Google Groups > "mailing.postfix.users", but felt that that it was probably the wrong > place to ask for advice. I then tried the Postfix oriented groups on my > news service, only to realize that the latest post other than mine was 3 > weeks ago (time to get a new news service or am I seeing the end of NNTP). > > I am very new to postfix and am looking for advice on my my postfix > configuration (see below), the configuration is aimed at a small group > of people (less than 25 users) who are all volunteers at a local not for > profit organization. The server is setup with no local users, and all > mail is delivered to virtual mailboxes. > > 1) I am using RBL + RBHL + amavis-new + spamassassin + clamv + > greylisting as anti-spam defenses. > Question: are the header and body checks still worthwhile as anti-spam > defenses? I can see the use of header checks for removing unwanted > stuff, like the various headers that get inserted during spam processing > are there any other worth while uses, if so what and where can I find > more information.
some uses of header and body checks: - reject "banned attachments" - detect forged Received headers - detect some backscatter (see the BACKSCATTER README) but they are not a "general" content filter. see the limitations in the docs. > > On the subject of RBL servers does anybody have any suggestions as the > RBL lists to use or avoid. I am currently using bl.spamcop.net, > zen.spamhaus.org, list.dsbl.org all of which seem to work well. > remove list.dsbl.org. it's no more active. use zen before spamcop. you will then probably realize that spamcop doesn't catch enough spam thatis not caught by zen. > 2) a lot of the configuration advice/tutorials/how-to's that I have > looked at put all the checks into the smtpd_recipient_restrictions. > Why defer killing spam, why not kill it ASAP and save spending anymore > resources processing it? > I know that smtpd_delay_reject parameter defaults to yes, therefore all > checks are deferred until recipient. But that just leads me to the same > question. > > 2a) have set the smtp_delay_reject = no, should I, am I giving myself a > problem by doing this? > yes. - some smtp implementations are "too strict" about error codes. they will generally retry if you reject them before RCPT stage. - when rejecting at RCPT stage, you have more infos. so you can assess your FPs... - how much do you gain in rejecting at connection time instead of RCPT time. exceptionally if the client retries. - most people use the default setup. so this is the setup that has been widely tested and validated. if you use a less common setup, you run the risks to find problems that were undetected. for example, there is a known problem with sender check in smtpd_recipient_restrictions if you set smtpd_delay_reject to no. (search the archives if interested). > 2b) based on some things I read here, it would seem that I should add > permit_sasl_authenticated to each of the smtp_*_restriction sections is > this correct? > if you want to whitelist (be that sasl authenticated users or mynetworks or other), you need to do that before any reject in any restriction. This is why putting your checks under smtpd_recipient_restrictions is good (you don't need to repeat the permit_*). > 2c) I was originally advised to have unknown_local_recipient_reject_code > = 554 but in a couple of places I have seen it set to 550, which is better? 550 "means": Requested action not taken: mailbox unavailable. so is better. > Supplementary, is there a list of codes, if so where? the codes are defined in the RFCs ;-p #postconf -d | grep unknown_ ... unknown_local_recipient_reject_code = 550 unknown_relay_recipient_reject_code = 550 unknown_virtual_alias_reject_code = 550 unknown_virtual_mailbox_reject_code = 550 ... > > 3) Is it possible to replace the virtual_mailbox_maps = > hash:/etc/postfix/vmailbox with something like proxy maps such as > virtual_mailbox_maps = proxy:unix:passwd.byname and if so how would > implement this using Dovecot as the LDA/ MDA? > virtual_mailbox_maps is for addresses in virtual_mailbox_domains. passwd.byname is for unix users. do not mix these. > 4) Are there any gotcha's in the config below. The "tradition" here is to show output of 'postconf -n' instead of main.cf. but I'm skipping it anyway...
