Am 19.04.2011 13:45, schrieb Jerry: > 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:
i would say yes, but many servers do it "somehow like that way" and it normally doesnt harm but for sure this should be a temp thing which should give time to deal with your logs and find better solutions > > <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> > -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
