On Tue, Apr 19, 2011 at 07:45:22AM -0400, Jerry wrote:
> 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 wonder what "default account" means in that context?)
My postmaster addresses are among the most most spammed ones I have.
snip
> > 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
Robert has more faith in humans than seems warranted IME. :) But I
have no problem with that approach, Darwinism and such; if they are
unable to find and follow simple directions, so be it.
> > 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.
It's A.D. 2011, and spam is extreme. I certainly do subject my
postmaster addresses to DNSBL scrutiny and other checks. Note that
with postscreen(8) it is not even possible to configure exemptions
per recipient address, only by client address.
The Way of the Future is with smtpd_reject_footer and
postscreen_reject_footer messages. Frustrated senders can read my
message (in the form of an HTTP link; it seems pretty safe nowadays
to assume that anyone has HTTP access) and find out not only how to
contact me, but also how to contact any of my users.
(It should be as simple as to sign up for any major freemail service
and send from there. I don't intentionally block any of them, and I
do use DNSWL and SWL whitelisting.)
> </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).
Postmaster@my.domains exists. I'll see anything sent there from a
legitimate client. Good enough for me.
> 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>
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
