On 6/29/2015 10:47 PM, PGNd wrote: > On Mon, Jun 29, 2015, at 08:23 PM, Noel Jones wrote: >>> That DISCARD action is logged in the amavisd logs, but occurs silently from >>> Postfix's perspective -- it's not notified, and does not log the message >>> disposition in its log. >>> >> This is correct. From postfix's perspective, the message was >> successfully sent and accepted. > > ... sent and accepted by this particular service. In the case of a PASS by > amavisd+SA, rather than the fail+DISCARD, it'd be reinjected to another > postfix service, for subsequent processing/delivery. As such it'd be logged. > > Just seemed logically inconsistent that a content pass would be logged -- > actually its reinjection -- but a fail would be completely silent. > > I suppose I could argue either way. Fair enough.
The postfix smtp sender will log that the message was delivered to amavisd. Further logging by postfix is not possible. > >>> My question is -- what's typical, good practice here? ... > >> It's generally considered bad form to discard messages, even illegal >> in some countries. Typically one would also save discarded messages >> to the amavisd quarantine due to false positives. > > I'm aware of the existence of jurisdictional variations in accept/discard > policies, but am not well enough versed; I'll pass that reminder on to > others that are. Seems odd that a reject by postscreen would be 'ok', but a > subsequent discard by a content-filter could be problematic. IANAL. > When postscreen or smtpd or a pre-queue filter REJECTS mail, the sender is notified by *their* MTA that the mail was not delivered. This is how email should work. When mail is discarded, no one is notified. From the end-user's point of view -- both the sender and receiver -- the mail is silently lost, and mail is unreliable. >> These days it's probably more common to use amavisd-new as a >> pre-queue smtpd_proxy_filter so that unwanted mail can be rejected >> during the SMTP transaction. Note that pre-queue filtering may >> require more hardware resources compared to an after-queue >> content_filter. > > Understood. This question's been about one piece; my complete setup > currently has several inbound stages now in-place, in order, > > postscreen + weighted RBLs > smtpd_mumble_restrictions > a prequeue proxy-filter policybank instance of amavisd for extension bans & > DKIM verification > a prequeue milter-instance of opendmarc, for both SPF & DMARC verification > a postqueue content-filter instance of amavisd for clamav & SA scans > > I continue to waffle re: the advantages/disadvantages of moving clamav &/or > SA postqueue. I've found bits-and-pieces of both pro & con arguments, but > nothing yet that's tilted strongly one way or the other. > This looks overly complicated... but you are free to configure your box as you see fit. I would certainly move clamav to pre-queue, so you can reject unwanted mail. AV scanning is generally much faster than full-content spam scanning, and this is certainly true with clamd vs. spamassassin. And use the add-on antispam signatures from sanesecurity. I strongly recommend pre-queue filtering so you can reject unwanted mail. Anything you do post-queue, I strongly recommend tag and deliver. False positives *will* happen. -- Noel Jones
