Peer Heinlein wrote: > Am Donnerstag 09 Juli 2009 schrieb Thomas Gelf: > >> As far as I remember all docs I used long time ago to set up my first >> Amavis boxes clearly state that it is absolutely necessary to avoid >> REJECTs by the postfix instance Amavis is reinjecting the mail to. It >> should NOT do any checks that did not already happen at the first >> instance. > > If you're using smtpd_proxy_filter in Postfix (which you should do to > avoid backscatter-mails) it's not possible to use header-/body_checks > in the first smtpd-instance on port 25. The only way to use > header-/body_checks is the reinjection-instance at port 10025.
To avoid backscatter mails -> jain ;-) This is true under the assumption that providing quarantine and informing users regularly of it's content is violating current law - which may be true for Germany, but not for other countries. Please don't get me wrong, I mostly agree with your arguments related to this topic - but there are lots of countries where you're still fine with an old-style quarantine system. Even long-term archival is NOT an absolute NO-GO for a quarantine, if the latter is archived too. Usually related laws do not enforce concrete technical implementations - they just state what you are required to accomplish to comply (e.g. "...preserve ALL incoming mail for..."). At MK09 I had the possibility to discuss prequeue-filtering with other people running large-scale mail systems, and during my speech I asked for (and got) feedback on this hot topic. I really got encouraged to finally give it a try - even if still being very sceptic. While I'm now pretty confident that it wouldn't add much burden while under normal load I'm somewhat sceptic regarding DDOS attacks or just "normal" peaks (spam, legal newsletter etc). Someone running prequeue- filters successful on a system with 5k mboxes said that he is not (yet?) running them on their 100k system - as of the very same doubts. > So: If it would be absolutely not allowed to reject mails at port 10025, > body-/header_checks wouldn't be usable any more at all. So I'd opt for disabling them completely if setting up a pre-queue system. Amavis and Spamassassin are going far beyond what Postfix is offering you. Many people are using header_checks as a quick first-aid fix - and many times without succes as they are running into troube with encoded subjects and other things they were not aware of. > And: Sometimes it's necessary to have a second filter stage (spam, > virus) so it's necessary to feed the mails from amavis directly into > another filter to get a realtime spam-/virus-engine. If you don't do so > because it isn't allowd to reject mails to amavis, you would always > have a store+forward-system and you would always run into backscatter > problems. > > And: Rejecting mails against amavis works pretty good. I can't se a > problem in it. It's working great. Except that Amavis is always sending > a DSN which is okay with D_BOUNCE and which should be avoided with > D_REJECT. -That's the only problem. ACK - but still sceptic regarding the "rejecting mails against amavis"- part. I did never face any situation where I was forced to waste my ressources that way - and IMO also with prequeue filters there would be better options. >> The user that brought up this issue is using header checks with >> postfix. > > ...as I recommend and as it is the only way to use body-/header_checks. ...if not using the power provided by custom Spamassassin rules/modules. >> In my believes (I must confess I did not read all config >> details in that thread) adding "-o header_checks=" to his postfix on >> port 10025 would solve this issue - even if I have no idea how he is > > No, because it isn't possible to specify header_checks= for the smtpd. > Adding "-o receive_override_options=no_header_body_checks" would > help :-), but in this case you would NEVER do this checks so there's no > need do define header_checks at all... This seems rather strange to me as I learned that Postfix allows you to configure each instance to do whatever you want - but as I have no eperience with preque-environments I'll blindly trust your words ;-) Nonetheless on postqueue-Amavis it would of course work as expected. Couldn't this lead us to a feature-request for Postfix? I would prefer to see header_checks (of course also body_checks) as normal lookup tools being useable in your restriction classes (even if they're not real "lookups")? If they really behave as you described it (impossible to apply before pre-queue filter) I consider them missplaced - or is there a specific reason for doing so? >> able to generate mail passing this check on the first postfix >> instance and hitting it on the second one. A possible explanation > > Using smtpd_proxy_filter (=pre-queue filtering!) the e-mail is forwarded > directly to port 10024. The mail does not pass the cleanup process > which is doing the checks. It's not possible to do the check on the > first instance! As told above - Wietse will for sure have some reason for doing so, but IMO it would be far better to move this checks to smtpd_*_restrictions. You'd loose them on pickup, but hey: who cares ;-) Old *_checks could still remain there for backward compatibility... >> Nonetheless I cannot immagine any special case where this DSNs (in >> case of REJECT) from Amavis would make sense - so as you did I'd also >> opt for suppressing them. > > Perfect :-) It is ;-) Maaaaaaaaaaaaaaaaark!!! Cheers, Thomas ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ AMaViS-user mailing list AMaViS-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
