Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
How to block offering SASL auth to clients based on RBL
702 views
Skip to first unread message
Kai Krakow
Jun 7, 2014, 3:59:05 AM6/7/14
to
Hello list!
Is there a way to prevent postfix from offering SASL auth (and that
includes
denying open relaying) to clients based on DNS RBL lookups? I've discovered
the option smtpd_sasl_exceptions_networks which allows to do that by adding
static subnet entries or adding a hash map.
The idea goes like this:
* SASL auth is not offered -> no way to relay mail
* based on a DNS-RBL that lists ASs with known bad behavior
* based on a DNS-RBL that lists IPs which are known to run compromised
servers
I imagined a configuration like this:
smtpd_sasl_exceptions_networks =
reject_rbl_client z.mailspike.net=127.0.0.2
reject_rbl_client dnsbl-3.uceprotect.net
Apart from this maybe being a bad idea, it would open the possibility to
react to distributed brute force attacks and compromised passwords if an
appropriate DNS BL could be offered by someone.
Currently, I'd like to try out the idea but I'm not sure if the above
configuration accepts passing in DNS BLs. Any suggestions?
What could be the consequences of this? I'm interested in reading more
ideas. Maybe there's already another approach to successfully prevent bots
from using compromised mail user accounts?
I outlined the same question here:
http://serverfault.com/questions/602327/postfix-offer-sasl-authentication-based-on-rbl
--
Replies to list only preferred.
Is there a way to prevent postfix from offering SASL auth (and that
includes
denying open relaying) to clients based on DNS RBL lookups? I've discovered
the option smtpd_sasl_exceptions_networks which allows to do that by adding
static subnet entries or adding a hash map.
The idea goes like this:
* SASL auth is not offered -> no way to relay mail
* based on a DNS-RBL that lists ASs with known bad behavior
* based on a DNS-RBL that lists IPs which are known to run compromised
servers
I imagined a configuration like this:
smtpd_sasl_exceptions_networks =
reject_rbl_client z.mailspike.net=127.0.0.2
reject_rbl_client dnsbl-3.uceprotect.net
Apart from this maybe being a bad idea, it would open the possibility to
react to distributed brute force attacks and compromised passwords if an
appropriate DNS BL could be offered by someone.
Currently, I'd like to try out the idea but I'm not sure if the above
configuration accepts passing in DNS BLs. Any suggestions?
What could be the consequences of this? I'm interested in reading more
ideas. Maybe there's already another approach to successfully prevent bots
from using compromised mail user accounts?
I outlined the same question here:
http://serverfault.com/questions/602327/postfix-offer-sasl-authentication-based-on-rbl
--
Replies to list only preferred.
Wietse Venema
Jun 7, 2014, 8:21:40 AM6/7/14
to
Kai Krakow:
feature to query a daemon that replies "not found" when the client
IP address is blacklisted.
smtpd_sasl_exceptions_networks = tcp:host:port
smtpd_sasl_exceptions_networks = socketmap:inet:host:port:name
smtpd_sasl_exceptions_networks = memcache:/file/name
In practice, almost no-one will do that. But, this would do what
you asked for and more.
Alternatively, you could update the smtpd_sasl_exceptions_networks
lookup table with fail2ban after Postfix logs some number of login
failures from a client IP address.
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.
Wietse
> Hello list!
>
> Is there a way to prevent postfix from offering SASL auth (and
> that includes denying open relaying) to clients based on DNS RBL
> lookups? I've discovered the option smtpd_sasl_exceptions_networks
> which allows to do that by adding static subnet entries or adding
> a hash map.
In theory, one could configure the smtpd_sasl_exceptions_networks
>
> Is there a way to prevent postfix from offering SASL auth (and
> that includes denying open relaying) to clients based on DNS RBL
> lookups? I've discovered the option smtpd_sasl_exceptions_networks
> which allows to do that by adding static subnet entries or adding
> a hash map.
feature to query a daemon that replies "not found" when the client
IP address is blacklisted.
smtpd_sasl_exceptions_networks = tcp:host:port
smtpd_sasl_exceptions_networks = socketmap:inet:host:port:name
smtpd_sasl_exceptions_networks = memcache:/file/name
In practice, almost no-one will do that. But, this would do what
you asked for and more.
Alternatively, you could update the smtpd_sasl_exceptions_networks
lookup table with fail2ban after Postfix logs some number of login
failures from a client IP address.
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.
Wietse
Kai Krakow
Jun 7, 2014, 9:33:42 AM6/7/14
to
Wietse Venema <wie...@porcupine.org> schrieb:
> Kai Krakow:
>> Hello list!
>>
>> Is there a way to prevent postfix from offering SASL auth (and
>> that includes denying open relaying) to clients based on DNS RBL
>> lookups? I've discovered the option smtpd_sasl_exceptions_networks
>> which allows to do that by adding static subnet entries or adding
>> a hash map.
>
> In theory, one could configure the smtpd_sasl_exceptions_networks
> feature to query a daemon that replies "not found" when the client
> IP address is blacklisted.
>
> smtpd_sasl_exceptions_networks = tcp:host:port
> smtpd_sasl_exceptions_networks = socketmap:inet:host:port:name
> smtpd_sasl_exceptions_networks = memcache:/file/name
>
> In practice, almost no-one will do that. But, this would do what
> you asked for and more.
>
> Alternatively, you could update the smtpd_sasl_exceptions_networks
> lookup table with fail2ban after Postfix logs some number of login
> failures from a client IP address.
I think I'd go that route. But from watching my log we don't have a problem
with clients brute forcing on postfix SASL but with compromised servers
(those which everyone can rent for a few bucks per month and nobody applies
security patches to) using the right (hijacked) crediantials right from the
beginning.
If I could find a list with compromised servers or build such a list of IPs
by some heuristics, it would be easy to fill a lookup table for postfix.
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.
> 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.
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
information disclosed by German BSI, I deduce that those trojan infections
may be years ago so password data collection by trojans has already a long
history and went undetected for months or years. On the other hand we cannot
force our users to change their passwords every few months. During the last
weeks we started playing hare and hedgehog with those attackers. First, one
customer's mail domain has been abused as sending domain to send thousands
of mails out to real mail accounts, with almost no bounces, through a
compromised server out of our control. We placed SPF records to mitigate the
issue. That even had an effect because after a few hours, the mails stopped
being sent from that server and instead now the attackers started relaying
those mails directly through our server by using correct credentials and
changing client IPs. We locked the account by changing credentials and felt
confident, until after a few more hours, the customer directly sent those
mails from his dial-up IP. We found that his systems had been infected with
a bot net which is now used to spread the mails and the password has been
compromised again. We sent in our support team who cleaned the infection and
now it is fixed. But we are seeing similar behavior starting for other
customer domains. It's scary to see this. I'm feeling we are going to see
such issues more often in the future.
Our postfix system blocks almost all incoming spam with almost no false
positives (mostly customers who communicate with East Europe are affected by
false positives, and we whitelisted those few servers or contacted the
admins to fix their DNS/HELO). It's a several years old postfix
configuration tuned regularily with a combination of greylisting, policyd-
weight, a few very reliable DNS BLs for immediate blocking, and a
combination of downstream spamassassin and different virus scanners (at
least on of server level, customer firewall level, customer mail gateway
level, client PC level).
But in the last few weeks we become listed on blacklists more and more
often, one of the most annoying being UCEprotect - and almost always by
compromised mail accounts. I don't understand how mail administrators can
opt-in to base their blocking decision on only one blacklist (that being
UCEprotect) but that is another story - as is with UCEprotect as blacklist
provider itself (they have a well established system of spam traps which is
good but they are doing "questionable business practice").
> Kai Krakow:
>> Hello list!
>>
>> Is there a way to prevent postfix from offering SASL auth (and
>> that includes denying open relaying) to clients based on DNS RBL
>> lookups? I've discovered the option smtpd_sasl_exceptions_networks
>> which allows to do that by adding static subnet entries or adding
>> a hash map.
>
> In theory, one could configure the smtpd_sasl_exceptions_networks
> feature to query a daemon that replies "not found" when the client
> IP address is blacklisted.
>
> smtpd_sasl_exceptions_networks = tcp:host:port
> smtpd_sasl_exceptions_networks = socketmap:inet:host:port:name
> smtpd_sasl_exceptions_networks = memcache:/file/name
>
> In practice, almost no-one will do that. But, this would do what
> you asked for and more.
>
> Alternatively, you could update the smtpd_sasl_exceptions_networks
> lookup table with fail2ban after Postfix logs some number of login
> failures from a client IP address.
with clients brute forcing on postfix SASL but with compromised servers
(those which everyone can rent for a few bucks per month and nobody applies
security patches to) using the right (hijacked) crediantials right from the
beginning.
If I could find a list with compromised servers or build such a list of IPs
by some heuristics, it would be easy to fill a lookup table for postfix.
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.
> 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.
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.
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
information disclosed by German BSI, I deduce that those trojan infections
may be years ago so password data collection by trojans has already a long
history and went undetected for months or years. On the other hand we cannot
force our users to change their passwords every few months. During the last
weeks we started playing hare and hedgehog with those attackers. First, one
customer's mail domain has been abused as sending domain to send thousands
of mails out to real mail accounts, with almost no bounces, through a
compromised server out of our control. We placed SPF records to mitigate the
issue. That even had an effect because after a few hours, the mails stopped
being sent from that server and instead now the attackers started relaying
those mails directly through our server by using correct credentials and
changing client IPs. We locked the account by changing credentials and felt
confident, until after a few more hours, the customer directly sent those
mails from his dial-up IP. We found that his systems had been infected with
a bot net which is now used to spread the mails and the password has been
compromised again. We sent in our support team who cleaned the infection and
now it is fixed. But we are seeing similar behavior starting for other
customer domains. It's scary to see this. I'm feeling we are going to see
such issues more often in the future.
Our postfix system blocks almost all incoming spam with almost no false
positives (mostly customers who communicate with East Europe are affected by
false positives, and we whitelisted those few servers or contacted the
admins to fix their DNS/HELO). It's a several years old postfix
configuration tuned regularily with a combination of greylisting, policyd-
weight, a few very reliable DNS BLs for immediate blocking, and a
combination of downstream spamassassin and different virus scanners (at
least on of server level, customer firewall level, customer mail gateway
level, client PC level).
But in the last few weeks we become listed on blacklists more and more
often, one of the most annoying being UCEprotect - and almost always by
compromised mail accounts. I don't understand how mail administrators can
opt-in to base their blocking decision on only one blacklist (that being
UCEprotect) but that is another story - as is with UCEprotect as blacklist
provider itself (they have a well established system of spam traps which is
good but they are doing "questionable business practice").
Wietse Venema
Jun 7, 2014, 10:41:24 AM6/7/14
to
Kai Krakow:
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
> 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
> postfix? A simple heuristic could be detecting unusual high mail volume for
> that account, probably by detecting the always repeating or similar
> subjects.
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.
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
Good luck.
Wietse
Noel Jones
Jun 7, 2014, 11:25:18 AM6/7/14
to
Why not just use reject_rbl_client (and maybe other restrictions)
before permit_sasl_authenticated to reject all mail from them? If
you're unwilling to accept SASL credentials, why would you accept
anything?
-- Noel Jones
li...@rhsoft.net
Jun 7, 2014, 11:53:04 AM6/7/14
to
Am 07.06.2014 17:25, schrieb Noel Jones:
> I wonder why you're just trying to stop SASL from those client...
> Why not just use reject_rbl_client (and maybe other restrictions)
> before permit_sasl_authenticated to reject all mail from them? If
> you're unwilling to accept SASL credentials, why would you accept
> anything?
and SASL is pretty clear that you have a problem if you are
using dialup-lists for your un-authenticated incoming mail
flow you can't use the same for submission or better said:
typically you have permit_sasl_authenticated in any case before
the RBL's and for using RBL's in front of submission they must
be much more careful selected and should only contain known
abusive IP's but not kill all enduser-dialup-ranges or you
end in no longer have any mail-customer in a short
* MX: you don't want clients-adsl-xx-xx-xx-some-isp.domain.tld deliver mail
* SUBMISSION: you don't want to block that customer ranges completly
well, one could say: block them from submission port and don't allow
SASL on 25, but that works only if you are a startup beginning from
scratch, i condsidered that but it would take weeks and months to
explain all customers that they have to fix their client configs
and i see even new configured clients using 25 because the idiotic
MUA's still default to 25 and burrie the port setting somewhere
under "expert" or "extended" settings, so you can't do that if
you have hundrets of customers with all sort of devices
iPhones and Apple Mail permanently disable SASL auth for unknown
reasons or in case of password changes need to re-configure the
outgoing mailserver seperated from the incoming creating enough
work for a sysadmins lifetime
LuKreme
Jun 7, 2014, 12:29:12 PM6/7/14
to
On 07 Jun 2014, at 09:53 , li...@rhsoft.net wrote:
> i condsidered that but it would take weeks and months to
> explain all customers that they have to fix their client configs
> and i see even new configured clients using 25 because the idiotic
> MUA's still default to 25 and burrie the port setting somewhere
> under "expert" or "extended" settings, so you can't do that if
> you have hundrets of customers with all sort of devices
When I eliminated connecting on port 25 for clients it was pretty seamless, albeit most of them are Mac users, so they never even noticed the change.
> iPhones and Apple Mail permanently disable SASL auth for unknown
> reasons or in case of password changes need to re-configure the
> outgoing mailserver seperated from the incoming creating enough
> work for a sysadmins lifetime
--
I want a refund, I want a light, I want a reason for all this night
after night after night after night
li...@rhsoft.net
Jun 7, 2014, 12:39:53 PM6/7/14
to
Am 07.06.2014 18:29, schrieb LuKreme:
>
> On 07 Jun 2014, at 09:53 , li...@rhsoft.net wrote:
>
>> i condsidered that but it would take weeks and months to
>> explain all customers that they have to fix their client configs
>> and i see even new configured clients using 25 because the idiotic
>> MUA's still default to 25 and burrie the port setting somewhere
>> under "expert" or "extended" settings, so you can't do that if
>> you have hundrets of customers with all sort of devices
>
> Don't most modern clients try 25 first, then fall back to other ports (587 and the stupid one I forget and don't support)?
> When I eliminated connecting on port 25 for clients it was pretty seamless,
> albeit most of them are Mac users, so they never even noticed the change.
i had *recently* one which client did not work after we
switched to a 4096/SHA-256 cert, guess what, Eudora on
a Apple machine, yes i answered with "i don't care"
*but* i can't answer that all day long for all sort of cases
>> iPhones and Apple Mail permanently disable SASL auth for unknown
>> reasons or in case of password changes need to re-configure the
>> outgoing mailserver seperated from the incoming creating enough
>> work for a sysadmins lifetime
>
> I have no idea what you are talking about; I've never had any issue with
> secure connections from iOS or OS X to my mail server
* the setting for using authentication get lost repeatly
if you haven't seen that you have to few Apple users
the iPhones try again and again after that send unautheticated
* after heartblead we forced all users to change their passwords
on the stupid Apple clients you need to change the password seperatly
for incoming and outgoing mail while even Outlook for a decase has
a checkbox "use same credentials as for incoming mail"
* and not the f**ing Apple clients don't ask for the new password
after the first error
* frankly a trained monkey could develop the code to enter only
username and password and try the same credentials on 587
by default instead try first 25 or send unauthenticated
the Apple user *never takes notice* if sending fails *never*
if you want i can give you a log where the same iPhone for
weeks tried every 5 minutes send to "somebody[at]gmail.com"
resulting in 150000 error messages on the server side and
the user even needed 5 mails and finally a phone call asking
what exectly he don't understand in my mails and why t**uck
he don't ask or just stop copy blindly protected mail adresses
in a client developed by monkeys unable to verify if a address
can be valid at all by not containing a @
Robert Schetterer
Jun 7, 2014, 1:05:14 PM6/7/14
to
Am 07.06.2014 09:59, schrieb Kai Krakow:
> Hello list!
>
> Is there a way to prevent postfix from offering SASL auth (and that
> includes
> denying open relaying) to clients based on DNS RBL lookups? I've discovered
> the option smtpd_sasl_exceptions_networks which allows to do that by adding
> static subnet entries or adding a hash map.
>
> Hello list!
>
> Is there a way to prevent postfix from offering SASL auth (and that
> includes
> denying open relaying) to clients based on DNS RBL lookups? I've discovered
> the option smtpd_sasl_exceptions_networks which allows to do that by adding
> static subnet entries or adding a hash map.
>
> The idea goes like this:
>
> * SASL auth is not offered -> no way to relay mail
> * based on a DNS-RBL that lists ASs with known bad behavior
> * based on a DNS-RBL that lists IPs which are known to run compromised
> servers
>
> I imagined a configuration like this:
>
> smtpd_sasl_exceptions_networks =
> reject_rbl_client z.mailspike.net=127.0.0.2
> reject_rbl_client dnsbl-3.uceprotect.net
>
> Apart from this maybe being a bad idea, it would open the possibility to
> react to distributed brute force attacks and compromised passwords if an
> appropriate DNS BL could be offered by someone.
>
> Currently, I'd like to try out the idea but I'm not sure if the above
> configuration accepts passing in DNS BLs. Any suggestions?
>
> What could be the consequences of this? I'm interested in reading more
> ideas. Maybe there's already another approach to successfully prevent bots
> from using compromised mail user accounts?
>
>
> I outlined the same question here:
> http://serverfault.com/questions/602327/postfix-offer-sasl-authentication-based-on-rbl
>
bad idea, perhaps good idea if you have your own rbl to sync brute
>
> * SASL auth is not offered -> no way to relay mail
> * based on a DNS-RBL that lists ASs with known bad behavior
> * based on a DNS-RBL that lists IPs which are known to run compromised
> servers
>
> I imagined a configuration like this:
>
> smtpd_sasl_exceptions_networks =
> reject_rbl_client z.mailspike.net=127.0.0.2
> reject_rbl_client dnsbl-3.uceprotect.net
>
> Apart from this maybe being a bad idea, it would open the possibility to
> react to distributed brute force attacks and compromised passwords if an
> appropriate DNS BL could be offered by someone.
>
> Currently, I'd like to try out the idea but I'm not sure if the above
> configuration accepts passing in DNS BLs. Any suggestions?
>
> What could be the consequences of this? I'm interested in reading more
> ideas. Maybe there's already another approach to successfully prevent bots
> from using compromised mail user accounts?
>
>
> I outlined the same question here:
> http://serverfault.com/questions/602327/postfix-offer-sasl-authentication-based-on-rbl
>
forcers ips to other servers
perhaps you like or get inspired by this
https://sys4.de/de/blog/2014/03/27/fighting-smtp-auth-brute-force-attacks/
Best Regards
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstra�e 15, 81669 M�nchen
Sitz der Gesellschaft: M�nchen, Amtsgericht M�nchen: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Noel Jones
Jun 7, 2014, 1:26:53 PM6/7/14
to
On 6/7/2014 10:53 AM, li...@rhsoft.net wrote:
>
>
> Am 07.06.2014 17:25, schrieb Noel Jones:
>> I wonder why you're just trying to stop SASL from those client...
>> Why not just use reject_rbl_client (and maybe other restrictions)
>> before permit_sasl_authenticated to reject all mail from them? If
>> you're unwilling to accept SASL credentials, why would you accept
>> anything?
>
> i think the point for different RBL lists for incoming mail
> and SASL is pretty clear that you have a problem if you are
> using dialup-lists for your un-authenticated incoming mail
> flow you can't use the same for submission or better said:
There are two general types of RBL -- bad neighborhoods and bad
>
>
> Am 07.06.2014 17:25, schrieb Noel Jones:
>> I wonder why you're just trying to stop SASL from those client...
>> Why not just use reject_rbl_client (and maybe other restrictions)
>> before permit_sasl_authenticated to reject all mail from them? If
>> you're unwilling to accept SASL credentials, why would you accept
>> anything?
>
> i think the point for different RBL lists for incoming mail
> and SASL is pretty clear that you have a problem if you are
> using dialup-lists for your un-authenticated incoming mail
> flow you can't use the same for submission or better said:
behavior. One would generally not block SASL to a bad neighborhood,
but maybe useful to block SASL to a host with bad behavior.
The original question was about using an RBL to block SASL based on
bad behavior.
Obviously the OP has such an RBL in mind already. Why would you
want any mail from a known bad host?
-- Noel Jones
LuKreme
Jun 7, 2014, 4:53:12 PM6/7/14
to
> On 07 Jun 2014, at 10:39 , li...@rhsoft.net wrote:
>
>
>
> Am 07.06.2014 18:29, schrieb LuKreme:
>>
>> On 07 Jun 2014, at 09:53 , li...@rhsoft.net wrote:
>>
>>> i condsidered that but it would take weeks and months to
>>> explain all customers that they have to fix their client configs
>>> and i see even new configured clients using 25 because the idiotic
>>> MUA's still default to 25 and burrie the port setting somewhere
>>> under "expert" or "extended" settings, so you can't do that if
>>> you have hundrets of customers with all sort of devices
>>
>> Don't most modern clients try 25 first, then fall back to other ports (587 and the stupid one I forget and don't support)?
>
> the stupidity is trying 25 first
>> When I eliminated connecting on port 25 for clients it was pretty seamless,
>> albeit most of them are Mac users, so they never even noticed the change.
>
> define "modern client"
>
> i had *recently* one which client did not work after we
> switched to a 4096/SHA-256 cert, guess what, Eudora on
> a Apple machine, yes i answered with "i don't care"
>
>>> iPhones and Apple Mail permanently disable SASL auth for unknown
>>> reasons or in case of password changes need to re-configure the
>>> outgoing mailserver seperated from the incoming creating enough
>>> work for a sysadmins lifetime
>>
>> I have no idea what you are talking about; I've never had any issue with
>> secure connections from iOS or OS X to my mail server
>
> did i say anything about secure connections?
> * the setting for using authentication get lost repeatly
> if you haven't seen that you have to few Apple users
> the iPhones try again and again after that send unautheticated
> * after heartblead we forced all users to change their passwords
> on the stupid Apple clients you need to change the password seperatly
> for incoming and outgoing mail while even Outlook for a decase has
Since incoming and outgoing can be different, that’s really not that big a deal.
> * and not the f**ing Apple clients don't ask for the new password
> after the first error
> * frankly a trained monkey could develop the code to enter only username and password and try the same credentials on 587 by default instead try first 25 or send unauthenticated
Mail.app and iOS first try port 25, then try 587, then try… I think it’s 465?
> the Apple user *never takes notice* if sending fails *never*
> if you want i can give you a log where the same iPhone for
> weeks tried every 5 minutes send to "somebody[at]gmail.com"
> resulting in 150000 error messages
https://www.dropbox.com/s/tm6bvy7v8t1kuu9/Screenshot%202014-06-07%2014.48.53.PNG
If you try to send it anyway, you get:
https://www.dropbox.com/s/wwpvycgcopn8q7u/Screenshot%202014-06-07%2014.50.38.PNG
The behavior of iOS is similar, though i does not ask you for another server, it just says the address was rejected by the server and the message was not sent.
> on the server side and the user even needed 5 mails and finally a phone call asking what exectly he don't understand in my mails and why t**uck he don't ask or just stop copy blindly protected mail adresses
> in a client developed by monkeys
> unable to verify if a addresscan be valid at all by not containing a @
Again, I don’t know what happened, but what you describe is simply not at all how anything works.
--
'Are you Death?' IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE
SCYTHE.
li...@rhsoft.net
Jun 7, 2014, 7:32:21 PM6/7/14
to
Am 07.06.2014 22:53, schrieb LuKreme:
>> On 07 Jun 2014, at 10:39 , li...@rhsoft.net wrote:
>>
>> Am 07.06.2014 18:29, schrieb LuKreme:
>>>
>>> On 07 Jun 2014, at 09:53 , li...@rhsoft.net wrote:
>>>
>>>> i condsidered that but it would take weeks and months to
>>>> explain all customers that they have to fix their client configs
>>>> and i see even new configured clients using 25 because the idiotic
>>>> MUA's still default to 25 and burrie the port setting somewhere
>>>> under "expert" or "extended" settings, so you can't do that if
>>>> you have hundrets of customers with all sort of devices
>>>
>>> Don't most modern clients try 25 first, then fall back to other ports (587 and the stupid one I forget and don't support)?
>>
>> the stupidity is trying 25 first
>
> That is still what most servers support or even require.
a new account could not do a simple check if 587 is available and
only in case it's not available fall back to 25
>>> When I eliminated connecting on port 25 for clients it was pretty seamless,
>>> albeit most of them are Mac users, so they never even noticed the change.
>>
>> define "modern client"
>>
>> i had *recently* one which client did not work after we
>> switched to a 4096/SHA-256 cert, guess what, Eudora on
>> a Apple machine, yes i answered with "i don't care"
>
> much if any envelopment on it for a decade. Certainly not modern in any
> sense of the word.
i know that
> sense of the word.
you know that
now the customer knows
fine if something affects only a few customers
but that don't change the fact taht if you have
to support hundrets of them you can chose between
be careful or face a support nightmare after changes
>>>> iPhones and Apple Mail permanently disable SASL auth for unknown
>>>> reasons or in case of password changes need to re-configure the
>>>> outgoing mailserver seperated from the incoming creating enough
>>>> work for a sysadmins lifetime
>>>
>>> I have no idea what you are talking about; I've never had any issue with
>>> secure connections from iOS or OS X to my mail server
>>
>> did i say anything about secure connections?
>
> You said SASL auth
a secure connection by defintion is encrypted with TLS
>> * the setting for using authentication get lost repeatly
>> if you haven't seen that you have to few Apple users
>> the iPhones try again and again after that send unautheticated
>
> Never seen that. Run OS X and iOS all day every day, as do many users.
for multiple customers as well as sometimes even for people
in the own company which for sure have no new iPhone
>> * after heartblead we forced all users to change their passwords
>> on the stupid Apple clients you need to change the password seperatly
>> for incoming and outgoing mail while even Outlook for a decase has
>
> Since incoming and outgoing can be different, that�s really not that big a deal.
it *can* be different, most time it is not and even if POP3/IMAP
is not the same server the user database is shared
i know nobody on this planet maintaining different user databases
for SMTP and IMAP/POP3
>> * and not the f**ing Apple clients don't ask for the new password
>> after the first error
>
> damn time (because Google app specific password for 2-factor users don;t work well).
it is true
otherwise you can't explain why people in the same room had that problem
>> * frankly a trained monkey could develop the code to enter only username and
>> password and try the same credentials on 587 by default instead try first 25
>> or send unauthenticated
>
> Sorry, this is not what happens unless, maybe, you allow unauthenticated
> submission on port 25? Dunno, I never did that.
otherwise any switch, heat sensor and what not would need SASL accounts
> Mail.app and iOS first try port 25, then try 587, then try� I think it�s 465?
and *that* is plain stupid
first 587 and *then* 25 is the way to go
>> the Apple user *never takes notice* if sending fails *never*
>
> That is not true. If sending fails it tells you and asks if you want to use a different
> server (if more than one is configured) or asks you ant you want to do, including
> try-again or edit the message.
using invalid RCPT's, no authentication at all and trying over weeks every
5 minutes did not happen - than the postfix log lies or you have only very
few users
>> if you want i can give you a log where the same iPhone for
>> weeks tried every 5 minutes send to "somebody[at]gmail.com"
>> resulting in 150000 error messages
>
> If you server reject the email, both iOS and OS X do not retry. I have no idea
> what you (or your user) did to generate 150,000 error messages, but that is not
> what has ever happened here. You cannot send a mail from Apple mail or
it will *not* reject it before sending
the **** with his iPhone needed even handholding to remove hat
message from the outgoing folder and tried to explain me he
can't delete it
the other one tried over *6 months* again and again send unauthenticated
after this crap device got stolen and i was even able to tell him day and
time when it was stolen from the maillog
> https://www.dropbox.com/s/tm6bvy7v8t1kuu9/Screenshot%202014-06-07%2014.48.53.PNG
>
> If you try to send it anyway, you get:
>
> https://www.dropbox.com/s/wwpvycgcopn8q7u/Screenshot%202014-06-07%2014.50.38.PNG
> The behavior of iOS is similar, though i does not ask you for another server,
> it just says the address was rejected by the server and the message was not sent.
but what happens is that it is retried again and again
proven by psotfix logs and after call the user bad names
it stopped *weeks* before the first attempt
>> on the server side and the user even needed 5 mails and finally a phone call asking what
>> exectly he don't understand in my mails and why t**uck he don't ask or just stop copy
>> blindly protected mail adresses
>
> So your user is dumb?
5 up to 10 users each month - now guess if all the users are
dumb or Apple is to dumb for create a sane mail client
>> in a client developed by monkeys
>
> You sound a lot like an anti-Apple bigot with an axe to grind.
>> unable to verify if a addresscan be valid at all by not containing a @
>
i know my server logs, they are real
Kai Krakow
Jun 8, 2014, 3:55:13 AM6/8/14
to
Noel Jones <njo...@megan.vbhcs.org> schrieb:
Actually I don't care if I disable relaying (which can only be done using
SASL anyway) for subnets or bad bahaving AS. But I still want legitimate
mail come in for my customers - even if it originates from such networks.
But I want to (automatically) block the suspicious networks and not first
block all then whitelist the known-good.
SASL anyway) for subnets or bad bahaving AS. But I still want legitimate
mail come in for my customers - even if it originates from such networks.
But I want to (automatically) block the suspicious networks and not first
block all then whitelist the known-good.
Kai Krakow
Jun 8, 2014, 4:05:07 AM6/8/14
to
>> 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.
Defer that idea... I think it is not nedded yet because I currently like
>> 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.
this idea:
>> 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.
that, sounds like the way to go. It will not completely block those mails
but at list mitigate such problems a lot.
Still, I think it could be clever not offering SASL auth to bad behaving
networks if those have been suspicious in the past. It could stop the
"hackers" from even knowing if the credentials are correct, read: stop them
from trying the account for spam sending right at the beginning so they
(hopefully) just discard that account as "not working".
Kai Krakow
Jun 8, 2014, 4:17:41 AM6/8/14
to
Noel Jones <njo...@megan.vbhcs.org> schrieb:
> On 6/7/2014 8:33 AM, Kai Krakow wrote:
worker process on port 25), it won't work. I'm planning to maybe change this
in the future. But as with migrating all people to not submit on port 25 it
is a long way to go. We are currently in the process of migrating customers
to port 587. But there are still a lot who use old or silly mail clients
which don't support TLS or even don't support port 587.
I'm not able to do a hard cut because we are going the customer-confidence-
first route.
And then there is the fact that legitimate mails come in from networks we
would never need to offer SASL auth to because those networks do not relay,
they are directly submitting into the MX as MTA clients.
So why offer a password authentication service to networks that don't need
this features? It could close an attacking surface. The problem here is that
we could never know beforehand when it is needed and when not. But we could
disable this feature for networks we detect unexpected/unwanted behavior
from. I'm looking for a way to implement that.
We cannot even say that everything that does not look like dial-up by DNS
lookup is not needing SASL. There are services out there running on servers
with non-dial-up reverse lookups that do legitimate SASL lookups on our
side.
Wietse had a nice idea about rate limiting SASL login accounts during
submission. Maybe I can exploit the resulting database to extract IPs and
subnets with permanent spammy behavior and sync those into the SASL
exception list.
> On 6/7/2014 8:33 AM, Kai Krakow wrote:
>>>> Hello list!
>>>>
>>>> Is there a way to prevent postfix from offering SASL auth (and
>>>> that includes denying open relaying) to clients based on DNS RBL
>>>> lookups? I've discovered the option smtpd_sasl_exceptions_networks
>>>> which allows to do that by adding static subnet entries or adding
>>>> a hash map.
>>>
>>>>
>>>> Is there a way to prevent postfix from offering SASL auth (and
>>>> that includes denying open relaying) to clients based on DNS RBL
>>>> lookups? I've discovered the option smtpd_sasl_exceptions_networks
>>>> which allows to do that by adding static subnet entries or adding
>>>> a hash map.
>>>
>>> In theory, one could configure the smtpd_sasl_exceptions_networks
>>> feature to query a daemon that replies "not found" when the client
>>> IP address is blacklisted.
>>>
>>> smtpd_sasl_exceptions_networks = tcp:host:port
>>> smtpd_sasl_exceptions_networks = socketmap:inet:host:port:name
>>> smtpd_sasl_exceptions_networks = memcache:/file/name
>>>
>>> In practice, almost no-one will do that. But, this would do what
>>> you asked for and more.
>>>
>>> Alternatively, you could update the smtpd_sasl_exceptions_networks
>>> lookup table with fail2ban after Postfix logs some number of login
>>> failures from a client IP address.
>>
>> I think I'd go that route. But from watching my log we don't have a
>> problem with clients brute forcing on postfix SASL but with compromised
>> servers (those which everyone can rent for a few bucks per month and
>> nobody applies security patches to) using the right (hijacked)
>> crediantials right from the beginning.
>
>>> feature to query a daemon that replies "not found" when the client
>>> IP address is blacklisted.
>>>
>>> smtpd_sasl_exceptions_networks = tcp:host:port
>>> smtpd_sasl_exceptions_networks = socketmap:inet:host:port:name
>>> smtpd_sasl_exceptions_networks = memcache:/file/name
>>>
>>> In practice, almost no-one will do that. But, this would do what
>>> you asked for and more.
>>>
>>> Alternatively, you could update the smtpd_sasl_exceptions_networks
>>> lookup table with fail2ban after Postfix logs some number of login
>>> failures from a client IP address.
>>
>> I think I'd go that route. But from watching my log we don't have a
>> problem with clients brute forcing on postfix SASL but with compromised
>> servers (those which everyone can rent for a few bucks per month and
>> nobody applies security patches to) using the right (hijacked)
>> crediantials right from the beginning.
>
> I wonder why you're just trying to stop SASL from those client...
> Why not just use reject_rbl_client (and maybe other restrictions)
> before permit_sasl_authenticated to reject all mail from them? If
> you're unwilling to accept SASL credentials, why would you accept
> anything?
MX and Submission machine are the same postfix instance (and even the same
> Why not just use reject_rbl_client (and maybe other restrictions)
> before permit_sasl_authenticated to reject all mail from them? If
> you're unwilling to accept SASL credentials, why would you accept
> anything?
worker process on port 25), it won't work. I'm planning to maybe change this
in the future. But as with migrating all people to not submit on port 25 it
is a long way to go. We are currently in the process of migrating customers
to port 587. But there are still a lot who use old or silly mail clients
which don't support TLS or even don't support port 587.
I'm not able to do a hard cut because we are going the customer-confidence-
first route.
And then there is the fact that legitimate mails come in from networks we
would never need to offer SASL auth to because those networks do not relay,
they are directly submitting into the MX as MTA clients.
So why offer a password authentication service to networks that don't need
this features? It could close an attacking surface. The problem here is that
we could never know beforehand when it is needed and when not. But we could
disable this feature for networks we detect unexpected/unwanted behavior
from. I'm looking for a way to implement that.
We cannot even say that everything that does not look like dial-up by DNS
lookup is not needing SASL. There are services out there running on servers
with non-dial-up reverse lookups that do legitimate SASL lookups on our
side.
Wietse had a nice idea about rate limiting SASL login accounts during
submission. Maybe I can exploit the resulting database to extract IPs and
subnets with permanent spammy behavior and sync those into the SASL
exception list.
Joe Laffey
Jun 8, 2014, 11:18:19 AM6/8/14
to
On Sun, 8 Jun 2014, Kai Krakow wrote:
> Noel Jones <njo...@megan.vbhcs.org> schrieb:
you could use fail2ban to monitor your logs in real time and autoban via
iptables any ip that had failed logins? You could whitelist your own ip
range so they never get bannned regardless.
--
Joe Laffey
The Stable
Visual Effects
http://TheStable.tv/?e34523M/
> Noel Jones <njo...@megan.vbhcs.org> schrieb:
>
>
> But I want to (automatically) block the suspicious networks and not first
> block all then whitelist the known-good.
>
Not sure I completely understand the issue, but is this something where
>
> But I want to (automatically) block the suspicious networks and not first
> block all then whitelist the known-good.
>
you could use fail2ban to monitor your logs in real time and autoban via
iptables any ip that had failed logins? You could whitelist your own ip
range so they never get bannned regardless.
--
Joe Laffey
The Stable
Visual Effects
http://TheStable.tv/?e34523M/
li...@rhsoft.net
Jun 8, 2014, 12:11:43 PM6/8/14
to
Am 08.06.2014 17:18, schrieb Joe Laffey:
> On Sun, 8 Jun 2014, Kai Krakow wrote:
>
>> Noel Jones <njo...@megan.vbhcs.org> schrieb:
>>
>> But I want to (automatically) block the suspicious networks and not first
>> block all then whitelist the known-good.
>
> Not sure I completely understand the issue, but is this something where you could use fail2ban to monitor your logs
> in real time and autoban via iptables any ip that had failed logins? You could whitelist your own ip range so they
> never get bannned regardless.
like i did last weekend, feed your own RBL and most likely get
only real bad bots and *before* they ever touch your machine
our honeypot ist using free public IP's and listens on every
common port writing every connecting IP into a RBL
within a week 40000 client IP's and 15%-20% don't expire
after the configured 7 days because they come alaways back
you can assume no customer ever will touch the honeypot
Joe Laffey
Jun 8, 2014, 12:27:45 PM6/8/14
to
your main server... then use fail2ban to ban ips from that log as well?
You could even used separate regexes that matched only logs from the
honeypot and have a much greater ban time on those.
I do see the speed advantage to an RBL, and we used to run one that was
mainly manually set up (using djbdns's rbl). I have just fallen in love
with the auto operation of tools like fail2ban.
Either way, the honeypot is a good idea to catch some known spammers.
Though are we talking about spammers trying to guess SASL passwords, or
ones that already have account credentials, or open relays?
Note that I believe fail2ban could be setup with custom regexps to be used
as a rate limiting tool for sending mail with valid credentials. Perhaps
not the best solution for that, as it completely blocks the ip, but it
would be automatic.
--
Joe Laffey
The Stable
Visual Effects
li...@rhsoft.net
Jun 8, 2014, 1:29:25 PM6/8/14
to
but why setup fail2ban at all if you have no sshd on standard ports
and already a hyperfast "rbldnsd" running which scales over more than
one server without touch any configuration
frankly you can even use your RBL with web application firewalls
http://blog.modsecurity.org/2010/09/advanced-topic-of-the-week-real-time-blacklist-lookups.html
Joe Laffey
Jun 8, 2014, 1:46:14 PM6/8/14
to
Certainly much more scalable if you need that level of flexibility.
I would still use fail2ban or similar on sshd on non-standrd ports.
However, I hardly ever get hits on the non-standard sshd ports I have been
using for well over 15 years. But this is a topic for another mailing
list.
--
Joe Laffey
The Stable
Visual Effects
Peter
Jun 8, 2014, 9:45:17 PM6/8/14
to
On 06/08/2014 03:53 AM, li...@rhsoft.net wrote:
> well, one could say: block them from submission port and don't allow
> SASL on 25, but that works only if you are a startup beginning from
> scratch, i condsidered that but it would take weeks and months to
> well, one could say: block them from submission port and don't allow
> SASL on 25, but that works only if you are a startup beginning from
> explain all customers that they have to fix their client configs
> and i see even new configured clients using 25 because the idiotic
> MUA's still default to 25 and burrie the port setting somewhere
> under "expert" or "extended" settings, so you can't do that if
> you have hundrets of customers with all sort of devices
If that's the case then you can put submission on a separate IP address,
> and i see even new configured clients using 25 because the idiotic
> MUA's still default to 25 and burrie the port setting somewhere
> under "expert" or "extended" settings, so you can't do that if
> you have hundrets of customers with all sort of devices
so that your users can continue to submit to port 25 (and indeed even to
the same hostname on port 25) without problem, and it that service will
not have to handle MX traffic. In addition to the postfix configuration
changes this only requires (1) a free IP address and (2) DNS change.
Peter
Peter
Jun 8, 2014, 10:10:41 PM6/8/14
to
On 06/08/2014 08:53 AM, LuKreme wrote:
>
>> the stupidity is trying 25 first
>
> That is still what most servers support or even require.
I think the vast number of ESPs will accept submission on port 587.
>
>> the stupidity is trying 25 first
>
> That is still what most servers support or even require.
Only supporting port 25 for submission nowadays is a disaster
considering the number of ISPs that block outbound port 25. Many will
still offer 25 for backwards compatibility, but even those will use a
separate IP address in the vast majority of cases so as not to mix
submission with MX traffic.
Peter
LuKreme
Jun 8, 2014, 11:59:43 PM6/8/14
to
On 07 Jun 2014, at 17:32 , li...@rhsoft.net wrote:
> ah so you explain me all the thousands of lines in my maillog from iPhones
> using invalid RCPT's, no authentication at all and trying over weeks every
> 5 minutes did not happen - than the postfix log lies or you have only very
> few users
Or, more likely, you did something in YOUR configuration. iOS and OS X do not keep retrying to send messages that the server *properly* rejects. Never have.
> ah so you explain me all the thousands of lines in my maillog from iPhones
> using invalid RCPT's, no authentication at all and trying over weeks every
> 5 minutes did not happen - than the postfix log lies or you have only very
> few users
--
'It's time to-' 'Prod buttock, sir?' said Carrot, hurriedly. 'Close,'
said Vimes, taking a deep drag and blowing out a smoke ring, 'but no
cigar.' --Feet of Clay
li...@rhsoft.net
Jun 9, 2014, 12:56:47 AM6/9/14
to
my server has not to handle *any* MX traffic from outside,
thats a different machine and without SASL nobody but a
few internal servers submits any mail
besides that you gain nothing why in the world should admins
deal with all sort of workarounds because MUA developers are
too stupid for sane defaults and insist in use 25?
frankly *all* ISP's should start to block outgoing port 25
and the problem would go away at the same time as 90% of
attempted spam delivery would disappear because all the
infected zombies have no longer a way to send their crap
without hacking the acount data and use real submission
the difference ISP is blocking 25 or i do the same is simply
that nobody calls the ISP but anybody blames his mail admin
which can help in both cases but in one point to the ISP :-)
Peter
Jun 9, 2014, 5:37:47 PM6/9/14
to
On 06/09/2014 04:56 PM, li...@rhsoft.net wrote:
>>> well, one could say: block them from submission port and don't allow
>>> SASL on 25, but that works only if you are a startup beginning from
>>> scratch,
>>
>>> well, one could say: block them from submission port and don't allow
>>> SASL on 25, but that works only if you are a startup beginning from
>>> scratch,
>>
>> If that's the case then you can put submission on a separate IP address,
>> so that your users can continue to submit to port 25
>
>> so that your users can continue to submit to port 25
>
> "so that your users can continue to submit to port 25"
>
> and how will that lead to "close port 25 completly"?
So on the one hand you complain about how difficult it is to switch
>
> and how will that lead to "close port 25 completly"?
users off of port 25, but then when I give you a solution that means you
don't have to you complain because you don't want them on port 25? Make
up your mind, please.
> my server has not to handle *any* MX traffic from outside,
> besides that you gain nothing why in the world should admins
> deal with all sort of workarounds because MUA developers are
> too stupid for sane defaults and insist in use 25?
write their software the way you want. Unfortunately we live in the
real world and this is what we have to deal with. Depending on your
specific situation you may or may not have to cater to those MUAs.
> frankly *all* ISP's should start to block outgoing port 25
> and the problem would go away at the same time as 90% of
> attempted spam delivery would disappear because all the
> infected zombies have no longer a way to send their crap
> without hacking the acount data and use real submission
properly configured, is great at filtering zombie SPAM. The harder SPAM
to filter tends to be SPAM that originates from legitimate servers, as
you have said.
> the difference ISP is blocking 25 or i do the same is simply
> that nobody calls the ISP but anybody blames his mail admin
> which can help in both cases but in one point to the ISP :-)
I said earlier you may be in a position where you can just block 25
outright and be able to push all your users to submission, or this may
be too overwhelming of a task. The difference is that if the ISP blocks
it then the user is *already* on 587.
Peter
Peter
Jun 9, 2014, 5:45:08 PM6/9/14
to
On 06/08/2014 08:17 PM, Kai Krakow wrote:
> MX and Submission machine are the same postfix instance (and even the same
> worker process on port 25), it won't work. I'm planning to maybe change this
> in the future. But as with migrating all people to not submit on port 25 it
> is a long way to go.
If you can't force your users off of port 25, then the next best thing
> MX and Submission machine are the same postfix instance (and even the same
> worker process on port 25), it won't work. I'm planning to maybe change this
> in the future. But as with migrating all people to not submit on port 25 it
> is a long way to go.
is to separate our your submission by IP address, if done correctly your
users will be able to stay on port 25, not have to change the hostname
(or any other settings in their MUA) and you will have separated out
submission from MX traffic and can treat the two with different configs.
Peter
Kai Krakow
Jun 10, 2014, 1:24:09 PM6/10/14
to
Peter <pe...@pajamian.dhs.org> schrieb:
Yes, that is the plan. Separate submission, MX, and mailboxes from each
other, while during the same process migrate people to use port 587 on the
new submission machine which has its port 25 hopefully closed...
We already started to migrate new customers to port 587. But it is still on
the same machine (though with a little different config), thus there's also
port 25 available used by other customers. And those silly autodetection of
older MUAs sticks to port 25 unencrypted. :-( So even new customers who redo
their installations on their own silently go back to port 25. Maybe I'll add
some flag into our user tables to block port 25 auth for new users.
At least modern software does it right and tries 587 first, even Google Mail
does it right if you configure an outgoing SMTP account. Apparently people
tend to love old software and only use what they know.
BTW: In this context, what's the best approach to put mailboxes on a
separate machine? Let the LDA drop mails into NFS mounts, or let postfix
transport the mails via transport_map into a machine which hosts the LDA
(dovecot in our case)?
other, while during the same process migrate people to use port 587 on the
new submission machine which has its port 25 hopefully closed...
We already started to migrate new customers to port 587. But it is still on
the same machine (though with a little different config), thus there's also
port 25 available used by other customers. And those silly autodetection of
older MUAs sticks to port 25 unencrypted. :-( So even new customers who redo
their installations on their own silently go back to port 25. Maybe I'll add
some flag into our user tables to block port 25 auth for new users.
At least modern software does it right and tries 587 first, even Google Mail
does it right if you configure an outgoing SMTP account. Apparently people
tend to love old software and only use what they know.
BTW: In this context, what's the best approach to put mailboxes on a
separate machine? Let the LDA drop mails into NFS mounts, or let postfix
transport the mails via transport_map into a machine which hosts the LDA
(dovecot in our case)?
Charles Marcus
Jun 10, 2014, 1:49:46 PM6/10/14
to
On 6/10/2014 1:24 PM, Kai Krakow <hurik...@gmail.com> wrote:
> And those silly autodetection of older MUAs sticks to port 25
unencrypted. So even new customers who redo
> And those silly autodetection of older MUAs sticks to port 25
> their installations on their own silently go back to port 25.
So... why on earth are you allowing UNENCRYPTED AUTH at ALL, let alone
on port 25?
Wietse Venema
Jun 10, 2014, 4:39:23 PM6/10/14
to
Kai Krakow:
file per message. I can't say which approach would handle the most
load.
When I started work on Postfix, my dream configuration for
inbound mail handling was:
Internet -> N x Postfix server -> M x Mailbox server
With N and M scaling up as needed.
Wietse
> BTW: In this context, what's the best approach to put mailboxes on a
> separate machine? Let the LDA drop mails into NFS mounts, or let postfix
> transport the mails via transport_map into a machine which hosts the LDA
> (dovecot in our case)?
I recommend Dovecot via LMTP, but NFS would work, too, assuming one
> separate machine? Let the LDA drop mails into NFS mounts, or let postfix
> transport the mails via transport_map into a machine which hosts the LDA
> (dovecot in our case)?
file per message. I can't say which approach would handle the most
load.
When I started work on Postfix, my dream configuration for
inbound mail handling was:
Internet -> N x Postfix server -> M x Mailbox server
With N and M scaling up as needed.
Wietse
Thijssen
Jun 11, 2014, 6:36:31 PM6/11/14
to
On Sat, Jun 7, 2014 at 3:33 PM, Kai Krakow <hurik...@gmail.com> wrote:
> 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.
What I do against this is; install CSF/LFD, the open/free suite of
> 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.
ConfigServer scripts.
It has a wonderful option where you can prevent the blacklisted IP to
even access postfix at all.
Blocklists are controlled by modifying /etc/csf/csf.blocklists (I
would recommend against using spamhaus or UCEprotect though, too many
weird decisions there, and prone to false positives).
So why not do that? In addition you get an awful lot of good security
for your server.
Regards,
Julius Thijssen
0 new messages