On 2/23/2012 8:53 AM, /dev/rob0 wrote: > On Thu, Feb 23, 2012 at 08:06:34AM -0600, Stan Hoeppner wrote: >> On 2/23/2012 2:34 AM, rg86...@airpost.net wrote: >>> I'm building a Postfix server with postscreen & a before-queue >>> filter. >>> >>> I'm trying to get spamtraps working so that if a spamtrap address >>> is in ANY of the recipients, then delivery of the message to ALL >>> recipients is quietly DISCARDED. >> >> This isn't how spamtraps are typically implemented, and may be why >> you're having trouble. The proper way to implement a spamtrap for >> rejecting inbound spam is: >> >> 1. Check recipients of inbound connection for spamtrap address >> 2. Append new sender address to an access table >> 3. Use the table in a check_sender_access rule to reject inbound >> spam--no need for discard > > Why not the client address and check_client_access? I don't see > how/why a sender listing would be useful. Was this a typo or a > "thinko" on your part, Stan? :)
Maybe a "thinko" ;) I was trying diligently to avoid mentioning anything that would block based on the remote host, either IP or domain, lest spam hitting the trap address from a compromised gorilla/freemail account might end up blacklisting everything from said domains or hosts within. That would usually be a bad thing. Using the sender address seems much safer, reasonably targeted. > I see the goal as being, in part, to detect a spammer in THIS > transaction. That sounds reasonable to me. But the proper thing here > would be to use a policy service in smtpd_data_restrictions. I always thought one purpose of a trap is to remain 'invisible'. If one is rejecting based on the trap address being a recipient, this can tend to unmask the trap address, eventually making it useless for stopping spam, which is the goal after all. > I fully agree with the reject vs. discard idea. You don't need to > wait for end-of-DATA and waste that bandwidth (offer void where taxed > or prohibited, or where the spammer properly implemented pipelining.) > Also I consider it reckless and irresponsible to accept and discard > mail unless you are absolutely certain it is spam. I would not have > such confidence in this case. I was unaware of the fact that you can't REJECT connections containing multiple recipients. Does this depend on the type of check*access, or is this global? If global, wouldn't this pretty much make the REJECT action useless, as spammers could simply always send to $u...@domain.com and postmas...@domain.com? I agree with your discard philosophy Rob. I use DICARDs very sparingly, in header_checks only: to ditch some spam arriving via listservs that tend to be boot happy if you 5xx anything (LKML), and as a plonk filter for trolls and miscreants on certain lists (Shmuel on SDLU for example). Basically where a 5xx causes unwanted problems. -- Stan
