Kai Krakow:
> How is one supposed to automatically block such hijacked accounts within
> postfix? A simple heuristic could be detecting unusual high mail volume for
> that account, probably by detecting the always repeating or similar
> subjects.
Typically, this is done with postfwd (a third-party program) rate
limits. Either rate limit the envelope sender address (assuming
that you use smtpd_sender_login_maps to prevent sender spoofing)
or rate limit the sasl_username attribute.
> > To add DNSBL lookups to smtpd_sasl_exceptions_networks, one would
> > have to use maptype:mapname syntax (e.g., dnsbl:site.example.com,
> > dnsbl:site.example.com=filter, where the dnsbl: lookup table exists
> > only in the Postfix SMTP daemon). This is because the underlying
> > mechanism is used by all Postfix programs, and most programs must
> > not have dependencies on DNSBL support. However, lookup tables that
> > work in only one program would make Postfix more difficult to use.
>
> Using DNSBL and some sort of distributed heuristic detectors could easily
> identify compromised servers and automatically make postfix stop offering
> SASL auth to those clients.
>
> Although probably currently no one would do that, I still think this is an
> interesting idea although the proposed implementation may not be optimal in
> postfix yet.
I could rip out the DNSBL client code from the Postfix SMTP daemon
source code and make it available as 1) a lookup table to all programs
2) a library module that implements the underlying DNS client code.
> Background (tl;dr): We are hosting over 600 customer domains. There's always
> one or another who has his mail accounts compromised by a trojan. From
In that case, rate limiting by sasl login account is the way to go.
Good luck.
Wietse
