G?bor L?n?rt:
> On Thu, Dec 15, 2011 at 08:19:18AM -0600, /dev/rob0 wrote:
> > On Thursday 15 December 2011 07:53:35 Tomas Macek wrote:
> > > I'd like to use postcreen as some kind of spam protection.
> > > According to documentation
> > >
> > > * postscreen(8) should not be used on SMTP ports that receive mail
> > > from end-user clients (MUAs). In a typical deployment,
> > > postscreen(8) is used on the "port 25" service, while MUA clients
> > > submit mail via the submission service (port 587) which normally
> > > requires client authentication.
> > >
> > >
> > > But we have clients, that send mails on both port 25 and 587. I
> > > really cannot use postscreen? I don't understand why exactly.
> > > What will happen if I use it?
> >
> > You might reject some MUA clients, and if using after-220 tests, you
> > will be getting phone calls from confused users.
>
> Btw:
>
> I am thinking to use postscreen with mail submission server as well since
> its rbl check seems to be better in performance than using smtpd's one.
> Since I want also block some of the IPs even in case of mail submission (eg:
> user's account is stolen etc) with an own hosted BL for this purpose, I
> guess it's not a problem to use postscreen in case of mail submission, if I
> don't use other features of postscreen too much - at least not for mail
> submission. Is it a good idea at all?
I'll be happy to discuss how to make postscreen better to distinguish
MTA-to-MTA traffic from other traffic. I will decline the opportunity
to give a blow-by-blow presentation of how postscreen feature X
will suck when it is used with MUA traffic, and how it could be
made to suck less.
To stop spam caused by a botted client or phished password, a postfwd
or policyd rate limit seems more appropriate to me. This will catch
the bot or spammer before the IP address is blacklisted.
Wietse
