info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Security: How to limit authentication attempts?
1,263 views
Skip to first unread message
Kiss Gábor
Feb 21, 2016, 2:48:09 AM2/21/16
to
Dear folks,
My logs are full of lines like this:
Feb 21 04:12:05 MYOLDMTA postfix/smtpd[12967]: warning: unknown[195.22.126.159]: SASL LOGIN authentication failed: authentication failure
This is a brute force attack in order to get a valid username/password pair.
The cracker usually does 20 attempts within a single SMTP session.
Thought fail2ban alerts the firewall after the third or fourth one but
network filtering applies to new connections only.
(I would not filter _all_ incoming packets until it is
absolutely necessary.)
So the attacker may try any number of password quite unobtrusively.
Is there any way to instruct smtpd to close session after 3 unsuccesful
attempts as is written in RFC 4954? I found no appropriate config parameter.
https://tools.ietf.org/html/rfc4954#section-9
Servers MAY implement a policy whereby the connection is dropped
after a number of failed authentication attempts. If they do so,
they SHOULD NOT drop the connection until at least 3 attempts to
authenticate have failed.
The affected Postfix version is 2.11.3, our old MTA.
The new one is not found yet by the bad guys.
Regards
Gabor
My logs are full of lines like this:
Feb 21 04:12:05 MYOLDMTA postfix/smtpd[12967]: warning: unknown[195.22.126.159]: SASL LOGIN authentication failed: authentication failure
This is a brute force attack in order to get a valid username/password pair.
The cracker usually does 20 attempts within a single SMTP session.
Thought fail2ban alerts the firewall after the third or fourth one but
network filtering applies to new connections only.
(I would not filter _all_ incoming packets until it is
absolutely necessary.)
So the attacker may try any number of password quite unobtrusively.
Is there any way to instruct smtpd to close session after 3 unsuccesful
attempts as is written in RFC 4954? I found no appropriate config parameter.
https://tools.ietf.org/html/rfc4954#section-9
Servers MAY implement a policy whereby the connection is dropped
after a number of failed authentication attempts. If they do so,
they SHOULD NOT drop the connection until at least 3 attempts to
authenticate have failed.
The affected Postfix version is 2.11.3, our old MTA.
The new one is not found yet by the bad guys.
Regards
Gabor
Patrick Ben Koetter
Feb 21, 2016, 3:26:21 AM2/21/16
to
* Kiss Gábor <ki...@niif.hu>:
check_sasl_access (newer Postfix only) and let it read a list of blocked logins.
p@rick
--
[*] sys4 AG
https://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
> Dear folks,
>
> My logs are full of lines like this:
>
> Feb 21 04:12:05 MYOLDMTA postfix/smtpd[12967]: warning: unknown[195.22.126.159]: SASL LOGIN authentication failed: authentication failure
>
> This is a brute force attack in order to get a valid username/password pair.
> The cracker usually does 20 attempts within a single SMTP session.
> Thought fail2ban alerts the firewall after the third or fourth one but
> network filtering applies to new connections only.
> (I would not filter _all_ incoming packets until it is
> absolutely necessary.)
>
> So the attacker may try any number of password quite unobtrusively.
>
> Is there any way to instruct smtpd to close session after 3 unsuccesful
> attempts as is written in RFC 4954? I found no appropriate config parameter.
Either use postfwd2 or write your own policy server. For permanent blocks use
>
> My logs are full of lines like this:
>
> Feb 21 04:12:05 MYOLDMTA postfix/smtpd[12967]: warning: unknown[195.22.126.159]: SASL LOGIN authentication failed: authentication failure
>
> This is a brute force attack in order to get a valid username/password pair.
> The cracker usually does 20 attempts within a single SMTP session.
> Thought fail2ban alerts the firewall after the third or fourth one but
> network filtering applies to new connections only.
> (I would not filter _all_ incoming packets until it is
> absolutely necessary.)
>
> So the attacker may try any number of password quite unobtrusively.
>
> Is there any way to instruct smtpd to close session after 3 unsuccesful
> attempts as is written in RFC 4954? I found no appropriate config parameter.
check_sasl_access (newer Postfix only) and let it read a list of blocked logins.
p@rick
--
[*] sys4 AG
https://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
Kiss Gábor
Feb 21, 2016, 4:05:53 AM2/21/16
to
> > Is there any way to instruct smtpd to close session after 3 unsuccesful
> > attempts as is written in RFC 4954? I found no appropriate config parameter.
>
> Either use postfwd2 or write your own policy server. For permanent blocks use
> check_sasl_access (newer Postfix only) and let it read a list of blocked logins.
Dear Patrick,
> > attempts as is written in RFC 4954? I found no appropriate config parameter.
>
> Either use postfwd2 or write your own policy server. For permanent blocks use
> check_sasl_access (newer Postfix only) and let it read a list of blocked logins.
Thanks for your reply.
FYI: I already put a permanent DROP statement into to firewall config
that blocks any connections from this specific address.
Essence of my question was not "how to block manually an already
known malicious client?" but "how to apply some restrictions
automatically on any suspicious clients?"
Having a look on postfwd2 I found that it not cares with authentication.
So it is an interesting utility but I'm afraid does not solve my problem.
Regards
Gabor
Petri Riihikallio
Feb 21, 2016, 4:19:39 AM2/21/16
to
> Essence of my question was not "how to block manually an already
> known malicious client?" but "how to apply some restrictions
> automatically on any suspicious clients?”
> known malicious client?" but "how to apply some restrictions
Take a look at Fail2Ban or SSHGuard. They keep an eye on your logs and add firewall rules dynamically. They also expire the rules eventually.
There is one more thing to consider: If your users mistype their username or password when setting up their mail application, they’ll end up on the blacklist, because mail clients usually try multiple times. When they can’t make the connection, they’ll check their config, notice the error and correct it. When they still can’t connect - because they are now blacklisted, they’ll want support. (Executive summary: Expect more support calls if you set this up.)
--
Cheers
Petri
GSM +358 400 505 939
Kiss Gábor
Feb 21, 2016, 4:25:49 AM2/21/16
to
> Take a look at Fail2Ban or SSHGuard. They keep an eye on your logs and add firewall rules dynamically. They also expire the rules eventually.
Dear Petri,
I _do_ use fail2ban.
However -- as I wrote -- it can be circumvented.
Maybe you missed my first post. See
http://article.gmane.org/gmane.mail.postfix.user/254364
Gabor
tim
Feb 21, 2016, 4:56:00 AM2/21/16
to
On 2/21/2016 8:19 PM, Petri Riihikallio wrote:
>> Essence of my question was not "how to block manually an already >> known malicious client?" but "how to apply some restrictions >> automatically on any suspicious clients?” > Take a look at Fail2Ban or SSHGuard. They keep an eye on your logs and add firewall rules dynamically. They also expire the rules eventually. > > There is one more thing to consider: If your users mistype their username or password when setting up their mail application, they’ll end up on the blacklist, because mail clients usually try multiple times. When they can’t make the connection, they’ll check their config, notice the error and correct it. When they still can’t connect - because they are now blacklisted, they’ll want support. (Executive summary: Expect more support calls if you set this up.) >
>> Essence of my question was not "how to block manually an already >> known malicious client?" but "how to apply some restrictions >> automatically on any suspicious clients?” > Take a look at Fail2Ban or SSHGuard. They keep an eye on your logs and add firewall rules dynamically. They also expire the rules eventually. > > There is one more thing to consider: If your users mistype their username or password when setting up their mail application, they’ll end up on the blacklist, because mail clients usually try multiple times. When they can’t make the connection, they’ll check their config, notice the error and correct it. When they still can’t connect - because they are now blacklisted, they’ll want support. (Executive summary: Expect more support calls if you set this up.) >
+ 1 for Fail2ban.
You can set it up to exactly how you want. After 3 attempts on the SASL connection, block the connection (to a specific port? 25/465/all?) for 10 minutes.
Then I usually setup a "recidiv" filter. Another filter that matches on the 3rd recurrence (or any number) of the above filter. So after 9 attempts (3x 10min ban) (in this instance) I ban again for Y hours.
In my production environment I usually have:
1st Filter: 10 min after 10 fail
2nd Filter: 1 hour after 10 recurrences of 1st.
3rd Filter: 30 day ban. 7 occurrences of 2nd (Optional)
Usually when a paying user makes it to the 2nd filter, we usually get a call, tell them to check their password, and we unban.
Depending on your user-base change timings to suit. (to give you an idea, we have around ~200 users) After 2 years of setting this up, I've never had a client make it to the 3rd filter. Half the time then end up calling on the 1st filter.
Hope that sheds some light.
Tim
You can set it up to exactly how you want. After 3 attempts on the SASL connection, block the connection (to a specific port? 25/465/all?) for 10 minutes.
Then I usually setup a "recidiv" filter. Another filter that matches on the 3rd recurrence (or any number) of the above filter. So after 9 attempts (3x 10min ban) (in this instance) I ban again for Y hours.
In my production environment I usually have:
1st Filter: 10 min after 10 fail
2nd Filter: 1 hour after 10 recurrences of 1st.
3rd Filter: 30 day ban. 7 occurrences of 2nd (Optional)
Usually when a paying user makes it to the 2nd filter, we usually get a call, tell them to check their password, and we unban.
Depending on your user-base change timings to suit. (to give you an idea, we have around ~200 users) After 2 years of setting this up, I've never had a client make it to the 3rd filter. Half the time then end up calling on the 1st filter.
Hope that sheds some light.
Tim
Benny Pedersen
Feb 21, 2016, 4:59:57 AM2/21/16
to
On 2016-02-21 08:47, Kiss Gábor wrote:
> Feb 21 04:12:05 MYOLDMTA postfix/smtpd[12967]: warning:
> unknown[195.22.126.159]: SASL LOGIN authentication failed:
> authentication failure
https://www.google.dk/search?q=freecode+autofwd
> Feb 21 04:12:05 MYOLDMTA postfix/smtpd[12967]: warning:
> unknown[195.22.126.159]: SASL LOGIN authentication failed:
> authentication failure
fail2ban does not support ipv6
and autofwd is more simple and does support dual stacking
Petri Riihikallio
Feb 21, 2016, 5:09:46 AM2/21/16
to
> I _do_ use fail2ban.
> However -- as I wrote -- it can be circumvented.
>
> Maybe you missed my first post. See
> http://article.gmane.org/gmane.mail.postfix.user/254364
You are right, I missed the first one. I’m sorry for the noise.
> However -- as I wrote -- it can be circumvented.
>
> Maybe you missed my first post. See
> http://article.gmane.org/gmane.mail.postfix.user/254364
In your case, the functionality would need to be inside Postfix’s smtpd. A simple counter in the connection record and a check to see if the set limit is exceeded, all memory based. However, as far as I know it is not implemented. That would be an easy patch, around ten lines of code. If you write a clean patch it might make it into Postfix itself.
However, brute forcing usernames and passwords with just dozens of attempts before Fail2Ban kicks in is not a big problem in my opinion. I tried looking up the docs, but I didn’t find any mention how long an unsuccessful session can last. Maybe we’ll see attempts that keep the connection open forever trying to crack accounts. Then someone will implement a fix, if you won’t ;-)
Allen Coates
Feb 21, 2016, 5:48:29 AM2/21/16
to
Do smtpd_hard_error_limit
<http://www.postfix.org/postconf.5.html#smtpd_hard_error_limit> and
smtpd_soft_error_limit
<http://www.postfix.org/postconf.5.html#smtpd_soft_error_limit> count
authentication failures as "errors"?
I don't receive enough emails (or attacks) to have a definitive answer.
Allen C
On 21/02/16 07:47, Kiss Gábor wrote:
> Dear folks,
>
> My logs are full of lines like this:
>
<http://www.postfix.org/postconf.5.html#smtpd_hard_error_limit> and
smtpd_soft_error_limit
<http://www.postfix.org/postconf.5.html#smtpd_soft_error_limit> count
authentication failures as "errors"?
I don't receive enough emails (or attacks) to have a definitive answer.
Allen C
On 21/02/16 07:47, Kiss Gábor wrote:
> Dear folks,
>
> My logs are full of lines like this:
>
> Feb 21 04:12:05 MYOLDMTA postfix/smtpd[12967]: warning: unknown[195.22.126.159]: SASL LOGIN authentication failed: authentication failure
>
>
> This is a brute force attack in order to get a valid username/password pair.
> The cracker usually does 20 attempts within a single SMTP session.
> Thought fail2ban alerts the firewall after the third or fourth one but
> network filtering applies to new connections only.
> (I would not filter _all_ incoming packets until it is
> absolutely necessary.)
>
> So the attacker may try any number of password quite unobtrusively.
>
> The cracker usually does 20 attempts within a single SMTP session.
> Thought fail2ban alerts the firewall after the third or fourth one but
> network filtering applies to new connections only.
> (I would not filter _all_ incoming packets until it is
> absolutely necessary.)
>
> So the attacker may try any number of password quite unobtrusively.
>
> Is there any way to instruct smtpd to close session after 3 unsuccesful
> attempts as is written in RFC 4954? I found no appropriate config parameter.
>
> attempts as is written in RFC 4954? I found no appropriate config parameter.
>
Kiss Gábor
Feb 21, 2016, 5:59:30 AM2/21/16
to
Dear Allen,
> > This is a brute force attack in order to get a valid username/password pair.
> > The cracker usually does 20 attempts within a single SMTP session.
Ooops! That is it. Default of smtpd_hard_error_limit is exactly 20.
This is why there are 20 sequential attempts per session.
And the second 10 are much slower according the logs due to
smtpd_soft_error_limit=10.
I do some test configs and I cease the IP level blocking to see what happens.
Many thanks! :-)
Gabor
> > This is a brute force attack in order to get a valid username/password pair.
> > The cracker usually does 20 attempts within a single SMTP session.
This is why there are 20 sequential attempts per session.
And the second 10 are much slower according the logs due to
smtpd_soft_error_limit=10.
I do some test configs and I cease the IP level blocking to see what happens.
Many thanks! :-)
Gabor
Kiss Gábor
Feb 21, 2016, 6:11:09 AM2/21/16
to
Dear Sebastian,
> To make sure fail2ban breaks the connection, you need to put the fail2ban
> rules BEFORE any "ESTABLISHED,RELATED" rule.
As I wrote this is what I wish to avoid if possible.
I don't want an unnecessary check against a list of banned
addresses on _every_ IP packet.
Regards
Gabor
> To make sure fail2ban breaks the connection, you need to put the fail2ban
> rules BEFORE any "ESTABLISHED,RELATED" rule.
As I wrote this is what I wish to avoid if possible.
I don't want an unnecessary check against a list of banned
addresses on _every_ IP packet.
Regards
Gabor
Benny Pedersen
Feb 21, 2016, 6:17:34 AM2/21/16
to
On 2016-02-21 12:10, Kiss Gábor wrote:
> As I wrote this is what I wish to avoid if possible.
> I don't want an unnecessary check against a list of banned
> addresses on _every_ IP packet.
disable sasl auth global in main.cf
> As I wrote this is what I wish to avoid if possible.
> I don't want an unnecessary check against a list of banned
> addresses on _every_ IP packet.
and only enable sasl auth in submission & smtps in master.cf with -o pr
service
but dont disable starttls on port 25
you will imho still see abuse in port 25 after this
so make fail2ban perm block ips that still try sasl auth on port 25
Kiss Gábor
Feb 21, 2016, 6:34:23 AM2/21/16
to
> disable sasl auth global in main.cf
>
> and only enable sasl auth in submission & smtps in master.cf with -o pr
> service
>
> but dont disable starttls on port 25
My colleagues need authenticated channel to submit mails when traveling.
>
> and only enable sasl auth in submission & smtps in master.cf with -o pr
> service
>
> but dont disable starttls on port 25
So disabling sasl is not an option. And I have to receive mails on
ports as much as possible due to restrictive hotel/airport/etc
firewalls.
(No, VPN is not used by all of them. So address based authentication
cannot be mandatory.)
In general it is unlikely my boss permits me to reform our policies. :-)
Thanks for everybody for responses.
The problem is already solved by Allen Coates. :-)
Gabor
Benny Pedersen
Feb 21, 2016, 6:51:06 AM2/21/16
to
On 2016-02-21 12:34, Kiss Gábor wrote:
> My colleagues need authenticated channel to submit mails when
> traveling.
> So disabling sasl is not an option.
read again i just say disalbe it on port 25
> My colleagues need authenticated channel to submit mails when
> traveling.
> So disabling sasl is not an option.
and convense users to use submission port 587, or 465 as users se fits
> And I have to receive mails on
> ports as much as possible due to restrictive hotel/airport/etc
> firewalls.
> (No, VPN is not used by all of them. So address based authentication
> cannot be mandatory.)
rfc 1918 vs permit mynetworks, possible open relay, it would be as safe
as pop before smtp
> In general it is unlikely my boss permits me to reform our policies.
> :-)
> Thanks for everybody for responses.
> The problem is already solved by Allen Coates. :-)
Robert Schetterer
Feb 21, 2016, 6:58:19 AM2/21/16
to
Am 21.02.2016 um 11:48 schrieb Allen Coates:
> Do smtpd_hard_error_limit
> <http://www.postfix.org/postconf.5.html#smtpd_hard_error_limit> and
> Do smtpd_hard_error_limit
> <http://www.postfix.org/postconf.5.html#smtpd_hard_error_limit> and
> smtpd_soft_error_limit
> <http://www.postfix.org/postconf.5.html#smtpd_soft_error_limit> count
> authentication failures as "errors"?
>
> I don't receive enough emails (or attacks) to have a definitive answer.
>
> Allen C
this help a little bit
> <http://www.postfix.org/postconf.5.html#smtpd_soft_error_limit> count
> authentication failures as "errors"?
>
> I don't receive enough emails (or attacks) to have a definitive answer.
>
> Allen C
it may free resources more quickly
but its not a good solution ( tested )
in hard cases fail2ban is a good option
also disable sasl auth on port 25 ,only use it with submission
you may also modify my iptables recent script to your needs
https://sys4.de/de/blog/2014/03/27/fighting-smtp-auth-brute-force-attacks/
https://sys4.de/de/blog/2015/11/07/abwehr-des-botnets-pushdo-cutwail-ehlo-ylmf-pc-mit-iptables-string-recent-smtp/
>
>
> On 21/02/16 07:47, Kiss Gábor wrote:
>> Dear folks,
>>
>> My logs are full of lines like this:
>>
>> Feb 21 04:12:05 MYOLDMTA postfix/smtpd[12967]: warning: unknown[195.22.126.159]: SASL LOGIN authentication failed: authentication failure
>>
>> This is a brute force attack in order to get a valid username/password pair.
>> The cracker usually does 20 attempts within a single SMTP session.
>> The cracker usually does 20 attempts within a single SMTP session.
>> Thought fail2ban alerts the firewall after the third or fourth one but
>> network filtering applies to new connections only.
>> (I would not filter _all_ incoming packets until it is
>> absolutely necessary.)
>>
>> So the attacker may try any number of password quite unobtrusively.
>>
>> Is there any way to instruct smtpd to close session after 3 unsuccesful
>> attempts as is written in RFC 4954? I found no appropriate config parameter.
>>
>> https://tools.ietf.org/html/rfc4954#section-9
>> Servers MAY implement a policy whereby the connection is dropped
>> after a number of failed authentication attempts. If they do so,
>> they SHOULD NOT drop the connection until at least 3 attempts to
>> authenticate have failed.
>>
>> The affected Postfix version is 2.11.3, our old MTA.
>> The new one is not found yet by the bad guys.
>>
>> Regards
>>
>> Gabor
>
>
Best Regards
>> network filtering applies to new connections only.
>> (I would not filter _all_ incoming packets until it is
>> absolutely necessary.)
>>
>> So the attacker may try any number of password quite unobtrusively.
>>
>> Is there any way to instruct smtpd to close session after 3 unsuccesful
>> attempts as is written in RFC 4954? I found no appropriate config parameter.
>>
>> https://tools.ietf.org/html/rfc4954#section-9
>> Servers MAY implement a policy whereby the connection is dropped
>> after a number of failed authentication attempts. If they do so,
>> they SHOULD NOT drop the connection until at least 3 attempts to
>> authenticate have failed.
>>
>> The affected Postfix version is 2.11.3, our old MTA.
>> The new one is not found yet by the bad guys.
>>
>> Regards
>>
>> Gabor
>
>
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Kiss Gábor
Feb 21, 2016, 7:00:42 AM2/21/16
to
> > My colleagues need authenticated channel to submit mails when traveling.
> > So disabling sasl is not an option.
>
> read again i just say disalbe it on port 25
>
> and convense users to use submission port 587, or 465 as users se fits
Can you guarantee that hotel firewalls allows to reach my port 587? :->
> > So disabling sasl is not an option.
>
> read again i just say disalbe it on port 25
>
> and convense users to use submission port 587, or 465 as users se fits
> > The problem is already solved by Allen Coates. :-)
>
> what problem ?
http://article.gmane.org/gmane.mail.postfix.user/254364
Gabor
Benny Pedersen
Feb 21, 2016, 7:13:27 AM2/21/16
to
On 2016-02-21 13:00, Kiss Gábor wrote:
>> > My colleagues need authenticated channel to submit mails when traveling.
>> > So disabling sasl is not an option.
>> read again i just say disalbe it on port 25
>> and convense users to use submission port 587, or 465 as users se fits
> Can you guarantee that hotel firewalls allows to reach my port 587? :->
if thay block port 25 then use port 26 :=)
>> > My colleagues need authenticated channel to submit mails when traveling.
>> > So disabling sasl is not an option.
>> read again i just say disalbe it on port 25
>> and convense users to use submission port 587, or 465 as users se fits
> Can you guarantee that hotel firewalls allows to reach my port 587? :->
but stop sasl auth on port 25, in case it breaks anything for users thay
can still send postmaster a email, but not relay
>>> The problem is already solved by Allen Coates. :-)
>> what problem ?
> "how to configure smtpd to close connection after 3 authentication
> error"?
> http://article.gmane.org/gmane.mail.postfix.user/254364
in main.cf
smtpd_soft_error = 2
smtpd_hard_error = 3
in master.cf submission and smtps
-o smtpd_soft_error=20
-o smtpd_hard_error=30
but the master.cf does not matter, just a how to learn more postfix
untested here with the master.cf, so if it works be happy
yahoo...@lazygranch.xyz
Feb 21, 2016, 10:04:46 AM2/21/16
to
Sorry about the top posting, but I'm on my phone.
Is this supposed to be 2 and 3 also rather than 20 and 30?
Original Message
From: Benny Pedersen
Sent: Sunday, February 21, 2016 4:13 AM
To: postfi...@postfix.org
Subject: Re: SV: Security: How to limit authentication attempts?
Is this supposed to be 2 and 3 also rather than 20 and 30?
Original Message
From: Benny Pedersen
Sent: Sunday, February 21, 2016 4:13 AM
To: postfi...@postfix.org
Subject: Re: SV: Security: How to limit authentication attempts?
Wietse Venema
Feb 21, 2016, 10:13:14 AM2/21/16
to
Use fail2ban for global blocking. With Postfix 3.x, you can also use
smtpd_client_auth_rate_limit to limit the number of AUTH commands
per client IP address.
Wietse
smtpd_client_auth_rate_limit to limit the number of AUTH commands
per client IP address.
Wietse
Kiss Gábor
Feb 21, 2016, 10:43:55 AM2/21/16
to
> Use fail2ban for global blocking. With Postfix 3.x, you can also use
> smtpd_client_auth_rate_limit to limit the number of AUTH commands
> per client IP address.
Oh, thanks! This will useful too on new MTA. :-)
> smtpd_client_auth_rate_limit to limit the number of AUTH commands
> per client IP address.
Gabor
Robert Schetterer
Feb 21, 2016, 10:50:38 AM2/21/16
to
Am 21.02.2016 um 13:00 schrieb Kiss Gábor:
>>> My colleagues need authenticated channel to submit mails when traveling.
>>> So disabling sasl is not an option.
>>
>> read again i just say disalbe it on port 25
>>
>> and convense users to use submission port 587, or 465 as users se fits
>
> Can you guarantee that hotel firewalls allows to reach my port 587? :->
there is no guarantee for port 25 open at all
>>> My colleagues need authenticated channel to submit mails when traveling.
>>> So disabling sasl is not an option.
>>
>> read again i just say disalbe it on port 25
>>
>> and convense users to use submission port 587, or 465 as users se fits
>
> Can you guarantee that hotel firewalls allows to reach my port 587? :->
its not exotic that 25 is blocked to kill infected win pcs.
The answer mostly is webmail ( "perhaps" active sync ) cause https open
is a must have at public networks in real world.
In modern public firewalls submission port should be open , cause in big
mail setups this port is default these days. Also
most used mail clients can be configured auto with IMAP SPECIAL-USE
and projects like
https://automx.org/en/ so no big work at migrate
>
>>> The problem is already solved by Allen Coates. :-)
>>
>> what problem ?
>
> "how to configure smtpd to close connection after 3 authentication error"?
> http://article.gmane.org/gmane.mail.postfix.user/254364
>
0 new messages