Mailing List Archive

Ted Mittelstaedt skrev den 2020-03-03 08:26:

> What do other people do for this problem?

https://www.abusix.com/abusix-mail-intelligence

what more do you want to do ?

my own servers reject all clients not in danish ip space unless its sasl
authed

strong leaked passwords does not help much

hope to see 2fa auth login to dovecot not only dovecot pro ox

as it is now we all have already loosed

>I know this is probably off topic but I'm getting desperate enough to
ask.

No problem I would say, it is good exchange thoughts and idea's

>I run a commercial mailserver that regularly seems to have spammers
>relay mail through it that have obtained stolen credentials for a
user.
> Many years ago I stopped allowing users to change passwords on it
and
>I setup passwords for all users added to it, and the passwords are
>random strings of 8 characters or more.
>
>The problem is of course that since the passwords are difficult to
>remember, once the users do remember them they merrily proceed to use
>this "highly secure password that I can now remember" on every stupid
>website out on the Internet that they care to login to. The problem
>isn't really the people using Thunderbird or Outlook or their cell
>phones or whatever, because they save the password in the email client

>and then immediately forget it, which is what I want. It is the
people
>who use the webmail interface on multiple different systems, kiosk
>computers and the like, who are the problem. When hosts out on the
>Internet get busted into, the spammers get their passwords and
>email addresses and start relaying. I've confirmed this with several
>users I've called and it's always the same story.

Strange your webmail should be on https then it is difficult to catch
passwords. I do not have this at al, that peoples passwords get stolen.
Hardly ever. So maybe somewhere something is wrong in your setup. Maybe
spammers get access via a remote exploit?
I do not think this is a common problem.

>By the time I see what's going on the server is blacklisted everywhere
>and I have to waste time delisting it, and asskissing all of the
>little tiny blacklists run by little pricks who want me to pay money
>or wait a month to be delisted, etc. (no I'm NOT talking about
>spamcop, or barracuda or anyone professional - THEY know what they are
>doing and don't look at this as a chance for a shakedown)

Please remember, that you are causing work for these companies. Someone
is complaining. And someone is adding your ip to the blacklist.
They get harassed why the shit is getting through their spam filters.
I would also ask amazon to pay me a few thousands for wasting my time
constantly.


>I estimate that last year this happened around 5 times and I just
>lost an afternoon today answering the passle of help requests from
>users because it happened again.
>
>What I am wondering is how to tighten up my monitoring on my servers
to
>more rapidly identify when this starts happening. What I'm doing now
is
>a kludge but I run mailq (this is a sendmail system) and when I see
the
>number of pending mail mesages in there exceed a threshold I send an
>alert to my cell. It is a kludge and the problem is that
>the mailq doesn't start filling up until my server gets blacklisted.

Sendmail has a nice filter that rate limits a user. I was always
thinking
of implementing this, when I run into a situation as yours.

>I've considered several ideas like running a script out of cron that
>checks the number of authid's per hour but all of these seem like even
>worse kludges. The only idea that I have come up with that I really
>like is taking an AK-47 to the spammers but unfortunately spammers
>know that they are unloved and cowardly hide away in Russia and
scummier
>places and I can't reach 'em. (maybe I could offer a bounty? A
nickle
>a head? That would pay for the bullet at least. I don't think those
>people are worth even that, though)
>
>I do run a daily sendmail statistics report but by the time I read
that
>and see the bump in traffic it's too late.
>
>What do other people do for this problem?
>

Things you should consider:
- investigate what clients mostly have these problems. Give them a
sperate
outgoing server. This way when it happens again not everyone's email is
blocked.
ps. When I get spam I put the whole /24 range on the blacklist. So maybe
get ip's in different ranges.

- filter your logs of the last year that have outgoing spam. You wil see
same ip ranges. Put all of them on your outgoing mailservers dns
blacklist
so they cannot connect.

- google for outgoing milters. You get blacklisted on the bigger rbl's
after sending a lot of spam. A user is not sending 100 emails a day.


Good luck, fighting these spammers!!!

On 03/03/20 08:54, Benny Pedersen wrote:

> Ted Mittelstaedt skrev den 2020-03-03 08:26:
>
>> What do other people do for this problem?
Hi Ted,

<vendor>

What I can suggest you is to look at our DQS product
(https://www.spamhaustech.com/dqs/), that even in it's free subscription
model includes AuthBL, a list made of botnet's known to be used to spam
with abused credentials. A simple 5xx if a client connect to your
submission port using a listed IP would take care of *most* of your
problems.

</vendor>

After that, just running a daily report with a table like:

sasl_username - number of different ips observed in the latest 24h.

Can help you find out abused credentials that were being used by bots
(still) not in AuthBL.

I've observed in the field that this is an approach that works when you
have up to 20-30k users; after this threshold you may want to write
something to automate warnings and/or automatically block accounts if
they exceed a defined threshold of (different_ips per sasl_username) per
hour.

--
Best regards,
Riccardo Alfieri

Spamhaus Technology
https://www.spamhaustech.com/

Riccardo Alfieri skrev den 2020-03-03 14:53:

> sasl_username - number of different ips observed in the latest 24h.

i have limited so that i only allow sasl auth from trusted custommers
ips, all else is firewalled witd default policy of drop, and clients ips
is so just still logged if ports is something could be untrusted ips
range i still need to open as trusted range, this have limited my own
problem with strong passwords that got leaked

Riccardo Alfieri skrev den 2020-03-03 14:53:


# abuse port 21 begin
51.178.0.0/16 as16276 #OVH, FR
80.82.77.0/24 as202425 #INT-NETWORK, SC
104.206.128.0/22 as62904 #EONIX-COMMUNICATIONS-ASBLOCK-62904, US
# abuse port 21 end
# all ips begin
51.178.78.154
80.82.77.240
104.206.128.54
# all ips end
# abuse port 465 begin
51.178.0.0/16 as16276 #OVH, FR
111.118.212.0/22 as394695 #PUBLIC-DOMAIN-REGISTRY, US
164.132.0.0/16 as16276 #OVH, FR
180.96.0.0/11 as4134 #CHINANET-BACKBONE No.31,Jin-rong Street, CN
192.241.224.0/20 as14061 #DIGITALOCEAN-ASN, US
# abuse port 465 end
# all ips begin
51.178.78.152
111.118.215.98
164.132.183.196
180.114.159.48
192.241.226.237
# all ips end
# abuse port 587 begin
45.133.99.0/24 as202984 #TEAM-HOST AS, RU
51.91.0.0/16 as16276 #OVH, FR
78.128.113.0/24 as209160 #MITI2000, BG
82.102.160.0/19 as12400 #PARTNER-AS, IL
192.241.192.0/19 as14061 #DIGITALOCEAN-ASN, US
# abuse port 587 end
# all ips begin
45.133.99.2
51.91.212.80
78.128.113.92
82.102.173.78
192.241.213.144
# all ips end
# abuse port 993 begin
45.136.109.0/24 as49505 #SELECTEL, RU
109.252.0.0/16 as25513 #ASN-MGTS-USPD, RU
109.86.81.0/24 as13188 #TRIOLAN, UA
185.30.176.0/22 as60476 #MYCOM-AS, NL
# abuse port 993 end
# all ips begin
45.136.109.251
109.252.91.113
109.86.81.177
185.30.177.80
# all ips end

i have no custommers there, but its need to try anyway

logs is from yesterday only

Use ipset, hardly causing any latency using 50k entries.


-----Original Message-----
From: Benny Pedersen [mailto:me@junc.eu]
Sent: 03 March 2020 15:39
To: users@spamassassin.apache.org
Subject: Re: Question on early detection for relay spam

Riccardo Alfieri skrev den 2020-03-03 14:53:


# abuse port 21 begin
51.178.0.0/16 as16276 #OVH, FR
80.82.77.0/24 as202425 #INT-NETWORK, SC
104.206.128.0/22 as62904 #EONIX-COMMUNICATIONS-ASBLOCK-62904, US # abuse
port 21 end # all ips begin
51.178.78.154
80.82.77.240
104.206.128.54
# all ips end
# abuse port 465 begin
51.178.0.0/16 as16276 #OVH, FR
111.118.212.0/22 as394695 #PUBLIC-DOMAIN-REGISTRY, US
164.132.0.0/16 as16276 #OVH, FR
180.96.0.0/11 as4134 #CHINANET-BACKBONE No.31,Jin-rong Street, CN
192.241.224.0/20 as14061 #DIGITALOCEAN-ASN, US # abuse port 465 end #
all ips begin
51.178.78.152
111.118.215.98
164.132.183.196
180.114.159.48
192.241.226.237
# all ips end
# abuse port 587 begin
45.133.99.0/24 as202984 #TEAM-HOST AS, RU
51.91.0.0/16 as16276 #OVH, FR
78.128.113.0/24 as209160 #MITI2000, BG
82.102.160.0/19 as12400 #PARTNER-AS, IL
192.241.192.0/19 as14061 #DIGITALOCEAN-ASN, US # abuse port 587 end #
all ips begin
45.133.99.2
51.91.212.80
78.128.113.92
82.102.173.78
192.241.213.144
# all ips end
# abuse port 993 begin
45.136.109.0/24 as49505 #SELECTEL, RU
109.252.0.0/16 as25513 #ASN-MGTS-USPD, RU
109.86.81.0/24 as13188 #TRIOLAN, UA
185.30.176.0/22 as60476 #MYCOM-AS, NL
# abuse port 993 end
# all ips begin
45.136.109.251
109.252.91.113
109.86.81.177
185.30.177.80
# all ips end

i have no custommers there, but its need to try anyway

logs is from yesterday only

Marc Roos skrev den 2020-03-03 16:15:
> Use ipset, hardly causing any latency using 50k entries.

i dont need to block 50k entries, but only whitelist few accepted client
ips, where i resolve asn and open this specifik asn to have access, if
there is abuse it will be removed so its again is blocked, i have tryed
blockin 50k entries it failed maserable, for me it does not matter of
ipsets or not was used

keeping it tieght helps alot

the log i showed was not from clients that already had access, so no
need to block it

if you know iptabels you dont need ipsets :=)

On 3 Mar 2020, at 2:26, Ted Mittelstaedt wrote:

> I know this is probably off topic but I'm getting desperate enough to
> ask.
>
> I run a commercial mailserver that regularly seems to have spammers
> relay mail through it that have obtained stolen credentials for a
> user. Many years ago I stopped allowing users to change passwords on
> it and I setup passwords for all users added to it, and the passwords
> are random strings of 8 characters or more.
>
> The problem is of course that since the passwords are difficult to
> remember, once the users do remember them they merrily proceed to use
> this "highly secure password that I can now remember" on every stupid
> website out on the Internet that they care to login to. The problem
> isn't really the people using Thunderbird or Outlook or their cell
> phones or whatever, because they save the password in the email client
> and then immediately forget it, which is what I want. It is the
> people who use the webmail interface on multiple different systems,
> kiosk
> computers and the like, who are the problem.

The standard answer for this is to require some form of 2-step/2-factor
authentication. If you have users actually entering their usernames and
passwords in to random computers they will never see again, the only
sound practice is some form of 2FA where the 2nd step is ephemeral: OTP
of some variety, one-time codes via SMS, etc.

However, there's another useful tactic that doesn't require you to
deploy all-new services, although it will require some user training.
Decouple authentication identities from email address deliverability.
There is no intrinsic reason that a username must be a deliverable email
address, even if it looks like one. I originally did this almost
accidentally on my oldest surviving mail system, which has now hit 25
years (across multiple platforms, of course) without a single account
hijack. It's absurdly simple. My users all have real user accounts on
the mail server. They authenticate using
username@mailhostname.scconsult.com. Their primary email addresses are
somthingelse@scconsult.com. somethingelse@mailhostname.scconsult.com is
non-existent in any sense, as is username@scconsult.com. The
authentication name (username@mailhostname.scconsult.com) is only
deliverable locally: Postfix only accepts mail via SMTP for virtual
domains (e.g. scconsult.com, billmail.scconsult.com, grumpybozo.us,
etc.) Usable email addresses are not authentication identities and
authentication identities are not usable email addresses. Before I
started firewalling them as noisy nuisances, I had a constant flow of
auth attempts for various names that could never succeed against IMAP,
POP, both submission ports, SMTP (where I don't even allow AUTH!) and a
private website with an entirely distinct user namespace. HIBP tells me
that some miscreants probably have once-valid email+password combos for
some of my users at random breached websites, and I've seen auth
attempts for those email addresses from credential-stuffer bots, but
even if the owners of those addresses used the same passwords for the
breached sites as for their email, those attempts cannot succeed because
their email accounts do not use their email addresses as usernames.

That DOES NOT solve the Evil Kiosk Operator problem, of course. For
that, you need the aforementioned 2FA with one-use second factors.


[...]
> What I am wondering is how to tighten up my monitoring on my servers
> to
> more rapidly identify when this starts happening. What I'm doing now
> is
> a kludge but I run mailq (this is a sendmail system) and when I see
> the
> number of pending mail mesages in there exceed a threshold I send an
> alert to my cell. It is a kludge and the problem is that
> the mailq doesn't start filling up until my server gets blacklisted.

That's particularly bad with low-flow/snowshoe spammers who route one
message every 10 minutes through each of 300 compromised accounts spread
across 20 different servers, most of them on megaproviders. You won't
notice anything until the particular spam content has been fingerprinted
in shared systems like DCC, Pyzor, Razor, and Cloudmark.

> I've considered several ideas like running a script out of cron that
> checks the number of authid's per hour but all of these seem like even
> worse kludges. The only idea that I have come up with that I really
> like is taking an AK-47 to the spammers but unfortunately spammers
> know that they are unloved and cowardly hide away in Russia and
> scummier
> places and I can't reach 'em. (maybe I could offer a bounty? A
> nickle a head? That would pay for the bullet at least. I don't think
> those people are worth even that, though)

There's a seed of a useful idea in that paragraph...

Why do you allow access to IMAP, POP, or either mail submission port
(465 or 587) from random Russian IPs? Do you allow AUTH at all on port
25 and if so, why?

What I've done is that I have a log watcher (akin to fail2ban, but
built-to-purpose) on my Postfix and Dovecot logs, looking for failed
auth attempts. With some guardrails around it, this triggers an
automatic packet filter block on the surrounding registered route
against accessing mail client ports. On an irregular basis I consolidate
those blocks both programmatically and by eyeballing rational
megablocks. So on my mail server, 'ipfw list' includes 610 rules
blocking ports 110, 143, 465, 587, 993, and 995 for network ranges as
small as /24 and as large as /4. I can do that because my users are not
world travelers, but even on systems where a policy of "no mail
submission from RIPE or APNIC blocks" isn't possible, one can generally
be safe with rules like "no mail submission from AWS, GCP, Azure, OVH,
or Linode" and successfully shed a large fraction of the credential
stuffers.


--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)

On 3/3/20 3:40 AM, Marc Roos wrote:
> No problem I would say, it is good exchange thoughts and idea's

Agreed.

> Strange your webmail should be on https then it is difficult to catch
> passwords. I do not have this at al, that peoples passwords get stolen.
> Hardly ever. So maybe somewhere something is wrong in your setup. Maybe
> spammers get access via a remote exploit? I do not think this is a
> common problem.

I suspect that key loggers, or malicious browser add-ons, more nefarious
things (MitM proxies) are partially to blame.

> Please remember, that you are causing work for these companies. Someone
> is complaining. And someone is adding your ip to the blacklist.
> They get harassed why the shit is getting through their spam filters.

True.

> I would also ask amazon to pay me a few thousands for wasting my
> time constantly.

~chuckle~

> Sendmail has a nice filter that rate limits a user. I was always
> thinking of implementing this, when I run into a situation as yours.

I thought that Sendmail had a per authenticated user rate limit. If it
doesn't, I expect that a milter could be created to do that with little
effort.

I wonder if it would be possible to combine this rate limiting with
quarantining. That way the messages could be received from the client
and held on the server. Client's would likely be none the wiser. You
could then look at the count of quarantined messages and take action
based on that. You could also have an automated job that would email
the authenticated user when their messages were being quarantined; i.e.
they sent > X number of messages in the last Y hours. (25–50 & 24 seems
like a start. Check your logs for better numbers.)

> Things you should consider:
> - investigate what clients mostly have these problems. Give them a
> sperate outgoing server. This way when it happens again not everyone's
> email is blocked.

Hum. This seems somewhat problematic. How do you propose using
different SMTP servers based on authenticating client /without/
reconfiguring clients or playing DNS games? It seems like the front
line MSA would need to conditionally route messages to the next SMTP
server based on behavior & sending rate.

> ps. When I get spam I put the whole /24 range on the blacklist. So
> maybe get ip's in different ranges.
>
> - filter your logs of the last year that have outgoing spam. You wil
> see same ip ranges. Put all of them on your outgoing mailservers dns
> blacklist so they cannot connect.
>
> - google for outgoing milters. You get blacklisted on the bigger rbl's
> after sending a lot of spam.

At the risk of using buzz words, I wonder if anyone has applied A.I. /
M.L. to authenticated user / sending address / recipient address tuples.

Do you have any idea if the abusers are using different from addresses
(envelope and / or header) not associated with the authentication
credentials? It might be a low hanging fruit to associate
authentication credentials with the from addressees.

Do you filter on outbound messages? Make sure that you aren't violating
SFP / DMARC / spam / viruses.

> A user is not sending 100 emails a day.

Most users don't. I'm sure that I have done that in the past, though
rarely.

> Good luck, fighting these spammers!!!

+1



--
Grant. . . .
unix || die

Well for example of the trouble RBLS cause see this one for your own number:

> -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no
> trust
> [212.26.193.44 listed in list.dnswl.org]
>and then immediately forget it, which is what I want. It is the
people
>who use the webmail interface on multiple different systems, kiosk
>computers and the like, who are the problem. When hosts out on the
>Internet get busted into, the spammers get their passwords and
>email addresses and start relaying. I've confirmed this with several
>users I've called and it's always the same story.

>Strange your webmail should be on https then it is difficult to catch
>passwords.

As I mentioned already the issue isn't that people using the password on
the webmail interface are getting hacked, The issue is people using
the email password on -other- servers on the Internet, which then later
get hacked. Some users in fact never use the webmail interface yet
still get hacked, it is because they choose to use the same password on
multiple servers on the Internet.

It's more prevalent with the webmail users because those users type the
password in repeatedly, which commits it to their memory, and then since
it is committed to memory they find it easy to use elsewhere.

2FA isn't going to help unless 2FA could be applied to the SMTP Auth
port. In fact, since my incoming and outgoing mailservers are
independent servers, I can use different passwords for incoming and
outgoing servers, which is one answer. However, that is a decision that
would have been great if it was made back in 2004 when I split the
mailserver into independent servers.

The main coorelation I have is that users who call me asking "what is my
email password" because they are setting up new phones, etc. - they are
never hacked. It's the users that remember the passwords that get
hacked - obviously because they are using them elsewhere.

Ted

On 3/3/2020 5:53 AM, Riccardo Alfieri wrote:
> On 03/03/20 08:54, Benny Pedersen wrote:
>
>> Ted Mittelstaedt skrev den 2020-03-03 08:26:
>>
>>> What do other people do for this problem?
> Hi Ted,
>
> <vendor>
>
> What I can suggest you is to look at our DQS product
> (https://www.spamhaustech.com/dqs/), that even in it's free subscription
> model includes AuthBL, a list made of botnet's known to be used to spam
> with abused credentials. A simple 5xx if a client connect to your
> submission port using a listed IP would take care of *most* of your
> problems.
>

Well since I also am fully IPv6 compliant I don't think I have the space
for a real dynamic blacklist. A spammer with half a brain can simply
forgo IPv4 completely and have almost an infinite number of IP's to
attack me from. Of course most spammers are too stupid to setup a
rotator on an IPv6 line so maybe we might get a few more years in the
IPv4 space but much of this blacklist stuff can be easily defeated
once more people run IPv6.

> </vendor>
>
> After that, just running a daily report with a table like:
>
> sasl_username - number of different ips observed in the latest 24h.
>

Yes, this is what I have been thinking is most likely going to be the
most useful approach - that is, writing a log analysis script that runs
when the mailog is rolled over, and stuffs all authid IP addresses and
corresponding userIDs into a mysql database. Then a second report
script that queries the database looking for excessive use.
Unfortunately while it's the least kludgy approach it's also the most
complicated one. :-(

> Can help you find out abused credentials that were being used by bots
> (still) not in AuthBL.
>
> I've observed in the field that this is an approach that works when you
> have up to 20-30k users; after this threshold you may want to write
> something to automate warnings and/or automatically block accounts if
> they exceed a defined threshold of (different_ips per sasl_username) per
> hour.
>

Unfortunately that just opens a DoS hole as an attacker who is attacking
a particular userID can stuff the log and lock out a legitimate user.

Unlike Google who gives out accounts for free I collect money for them
and so therefore unlike Google I can't just do whatever the eff I want
to them for no reason anytime I feel like.

That's WHY Google gives out free accounts. That, and they have enough
of them they can gather all that lovely marketing data by scraping
people's emails for keywords.

Ted

If password rotating is out of the question, you might want to check your IPs against blacklists multiple times at a day, it wouldn't stop it but it may notify you earlier to stop an outbreak.

Other thing that comes to mind is, you may try rate limiting your users and setup a cron to monitor the number of outgoing messages and notify you if there's a sudden surge of mail requests.





M. Omer GOLGELI
---
AS202365

      https://as202365.peeringdb.com
      https://bgp.he.net/AS202365

NOC:
     Phone:         +90-533-2600533
     Email:      omer@chronos.com.tr


March 3, 2020 10:26 AM, "Ted Mittelstaedt" <tedm@ipinc.net> wrote:

> I know this is probably off topic but I'm getting desperate enough to ask.
>
> I run a commercial mailserver that regularly seems to have spammers relay mail through it that have
> obtained stolen credentials for a user. Many years ago I stopped allowing users to change passwords
> on it and I setup passwords for all users added to it, and the passwords are random strings of 8
> characters or more.
>
> The problem is of course that since the passwords are difficult to remember, once the users do
> remember them they merrily proceed to use
> this "highly secure password that I can now remember" on every stupid
> website out on the Internet that they care to login to. The problem
> isn't really the people using Thunderbird or Outlook or their cell phones or whatever, because they
> save the password in the email client and then immediately forget it, which is what I want. It is
> the people who use the webmail interface on multiple different systems, kiosk
> computers and the like, who are the problem. When hosts out on the
> Internet get busted into, the spammers get their passwords and
> email addresses and start relaying. I've confirmed this with several
> users I've called and it's always the same story.
>
> By the time I see what's going on the server is blacklisted everywhere
> and I have to waste time delisting it, and asskissing all of the
> little tiny blacklists run by little pricks who want me to pay money
> or wait a month to be delisted, etc. (no I'm NOT talking about
> spamcop, or barracuda or anyone professional - THEY know what they are
> doing and don't look at this as a chance for a shakedown)
>
> I estimate that last year this happened around 5 times and I just
> lost an afternoon today answering the passle of help requests from
> users because it happened again.
>
> What I am wondering is how to tighten up my monitoring on my servers to
> more rapidly identify when this starts happening. What I'm doing now is
> a kludge but I run mailq (this is a sendmail system) and when I see the
> number of pending mail mesages in there exceed a threshold I send an alert to my cell. It is a
> kludge and the problem is that
> the mailq doesn't start filling up until my server gets blacklisted.
>
> I've considered several ideas like running a script out of cron that
> checks the number of authid's per hour but all of these seem like even
> worse kludges. The only idea that I have come up with that I really
> like is taking an AK-47 to the spammers but unfortunately spammers
> know that they are unloved and cowardly hide away in Russia and scummier
> places and I can't reach 'em. (maybe I could offer a bounty? A nickle a head? That would pay for
> the bullet at least. I don't think those people are worth even that, though)
>
> I do run a daily sendmail statistics report but by the time I read that
> and see the bump in traffic it's too late.
>
> What do other people do for this problem?
>
> Ted

On Tue, 03 Mar 2020 16:05:31 -0800
Ted Mittelstaedt wrote:


> 2FA isn't going to help unless 2FA could be applied to the SMTP Auth
> port.

Sometime 2FA on webmail is combined with separate autogenerated
passwords for pop/imap/submission.

On 4 Mar 2020, at 14:43, RW wrote:

> On Tue, 03 Mar 2020 16:05:31 -0800
> Ted Mittelstaedt wrote:
>
>
>> 2FA isn't going to help unless 2FA could be applied to the SMTP Auth
>> port.
>
> Sometime 2FA on webmail is combined with separate autogenerated
> passwords for pop/imap/submission.

A.k.a. "application passwords" which people may be accustomed to as a
feature of both Google's and Apple's 2FA implementations.

It is also possible to couple 2FA with OAuth 2.0 (as Google does)
although that does put you in the position of forcing users to adopt
MUAs that support OAuth 2.0.




--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

Fails with travelling clients.

-------- Original Message --------
On Mar 3, 2020, 16:49, Benny Pedersen wrote:

> Marc Roos skrev den 2020-03-03 16:15:
>> Use ipset, hardly causing any latency using 50k entries.
>
> i dont need to block 50k entries, but only whitelist few accepted client
> ips, where i resolve asn and open this specifik asn to have access, if
> there is abuse it will be removed so its again is blocked, i have tryed
> blockin 50k entries it failed maserable, for me it does not matter of
> ipsets or not was used
>
> keeping it tieght helps alot
>
> the log i showed was not from clients that already had access, so no
> need to block it
>
> if you know iptabels you dont need ipsets :=)

On 04 Mar 2020, at 16:27, Rupert Gallagher <ruga@protonmail.com> wrote:
> Fails with travelling clients.

Depends. I block several countries from accessing my mail server. If someone travels to one of those countries, they can use webmail to access their mail.

There are always options.

However, most people simply use a VPN.

Rupert Gallagher skrev den 2020-03-05 00:27:
> Fails with travelling clients.

my custommers want vacation without stress :=)