On Tue, 19 Apr 2011 10:28:58 +0200 Robert Schetterer <rob...@schetterer.org> articulated:
> Am 18.04.2011 16:07, schrieb Carlos Mennens: > > My <postmaster> default account is getting hammered with spam. I've > > got SA / Amavisd-new working and tagging the messages as ***spam*** > > however I've just re-configured SA to be a little more aggressive on > > scoring the messages. My question to the Postfix group is if I can > > configure a restriction in /etc/postfix directory to prevent repeat > > offenders from sending email to me. Someone a few years ago on this > > mailing list assisted me on configuring Postfix to use a > > 'client_access' & 'client_access.db' file to block IP's as shown > > below: > > > > 95.98.160.248 REJECT > > 190.64.194.12 REJECT > > > > I've noticed that I am now getting spam emails from several > > different hosts on one single network rather than from a particular > > host. Can I block the entire network as follows: > > > > 95.98.* REJECT > > > > I'm sure many on the list wouldn't do this on their personal mail > > server but I'm looking for a simple method that will stop the junk > > mail. I know the 'client_access' flat file works fine but it's very > > tedious to continuously add several IP's from the same network in > > when I can simply blanket the entire network. If legit mail is > > blocked due to this, I can review the rule at that time and see if > > it's safe to lift the block or white-list that one particular > > client I.P. > > an easy idea might be reject the postmaster account with additional > message > > something like in a recipient access table > > postmas...@domain.my REJECT please use admin_at_domain_dot_my for > sending us postmaster mail > > this will help quick, any human will read the bounce and resend > > meanwhile you should analyse youre logs and find out what best to do > block the spam on smtp level, as there are many ways to it I am not an expert, but wouldn't that violate RFC-2821, section 4.5.1: <excerpt> Any system that includes an SMTP server supporting mail relaying or delivery MUST support the reserved mailbox "postmaster" as a case- insensitive local name. This postmaster address is not strictly necessary if the server always returns 554 on connection opening (as described in section 3.1). The requirement to accept mail for postmaster implies that RCPT commands which specify a mailbox for postmaster at any of the domains for which the SMTP server provides mail service, as well as the special case of "RCPT TO:<Postmaster>" (with no domain specification), MUST be supported. SMTP systems are expected to make every reasonable effort to accept mail directed to Postmaster from any other system on the Internet. In extreme cases --such as to contain a denial of service attack or other breach of security-- an SMTP server may block mail directed to Postmaster. However, such arrangements SHOULD be narrowly tailored so as to avoid blocking messages which are not part of such attacks. </excerpt> <quote> 3.1 Session Initiation An SMTP session is initiated when a client opens a connection to a server and the server responds with an opening message. SMTP server implementations MAY include identification of their software and version information in the connection greeting reply after the 220 code, a practice that permits more efficient isolation and repair of any problems. Implementations MAY make provision for SMTP servers to disable the software and version announcement where it causes security concerns. While some systems also identify their contact point for mail problems, this is not a substitute for maintaining the required "postmaster" address (see section 4.5.1). The SMTP protocol allows a server to formally reject a transaction while still allowing the initial connection as follows: a 554 response MAY be given in the initial connection opening message instead of the 220. A server taking this approach MUST still wait for the client to send a QUIT (see section 4.1.1.10) before closing the connection and SHOULD respond to any intervening commands with "503 bad sequence of commands". Since an attempt to make an SMTP connection to such a system is probably in error, a server returning a 554 response on connection opening SHOULD provide enough information in the reply text to facilitate debugging of the sending system. </quote> -- Jerry ✌ postfix-u...@seibercom.net _____________________________________________________________________ TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html
