Re: [mailop] SPF and DMARC Passed Phishing Spam from Oracle.com

[Hans-Martin Mosner via mailop]

Am 23.02.23 um 05:30 schrieb Peter Beckman via mailop:

It seems that if you are able to get a server in oraclecloud.com, you can
send SPF- and DMARC-passing spam to be sent by Oracle.com, which includes a
phishing URL attempt.


Actually, sending SPF- and DMARC-passing spam is possible from about any cloud 
service.

As long as the cloud providers don't enforce a strict KYC requirement for 
allowing outbound SMTP, this won't change.
Requiring accurate domain WHOIS information would at least make it a lot harder for spammers to create new domains to 
spam from, but that train has long passed the station, reached the final destination, been deposited on the scrap heap.


Cheers,
Hans-Martin

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Compromised email account trends

[Taavi Eomäe via mailop]

Why should I need to use a program registered to the service provider
in order to read my email? (Or in my case, register myself as a
developer with Microsoft in order to allow me and my colleagues to
read our own mail.)



You are confusing one vendor's implementation with the standard.



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: Compromised email account trends

[Marcel Becker via mailop]

On Wed, Feb 22, 2023 at 13:32 Julian Bradfield via mailop 
wrote:

>
In what way is it easier to revoke an OAuth2 token than it is to
> change a password?


It’s easier to revoke access of a specific app without interrupting the
users access to other apps. Vs. Invalidating the password which interrupts
everything…

Most people have no clue about how OAuth2 works.


Correct. And they don’t have to. Just like most people don’t know how IMAP,
SMTP or MIME works — still they use email.

They just know that it's something that gets in the way of working
> practices they've been using for 40 years.


Data of actual normal users (and the abuse we see) suggests otherwise.

And I guess people also argued that filling up a car with petrol gets in
the way of working practices they’ve been using for 100 years…
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Compromised email account trends

[Julian Bradfield via mailop]

On 2023-02-22, Taavi Eomäe via mailop  wrote:
> This discussion is getting awfully close to reinventing OAuth2.
>
> It's quite clear by now that long-lived tokens that are nearly 
> impossible to properly revoke just don't work well in any human-operated 
> contexts.
>
> Hopefully we'll see an increase in the adoption of OAuth2 instead of 
> rather crude ways of mitigating only half of the issue. Large players 
> started pushing Oauth2 for both SMTP and IMAP for a really good reason 
> after all.

Ugh.
Why should I need to use a program registered to the service provider
in order to read my email? (Or in my case, register myself as a
developer with Microsoft in order to allow me and my colleagues to
read our own mail.)

In what way is it easier to revoke an OAuth2 token than it is to
change a password? Most people have no clue about how OAuth2 works.
They just know that it's something that gets in the way of working
practices they've been using for 40 years.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Compromised email account trends

[Sebastian Nielsen via mailop]

Problem with OAuth2 is that many commercial mail clients only support it for a 
select number of big providers thus you have 2 choices, either implement 
geo-restriction, or have a 2FA auth portal where you authorize IPs to access 
your account.
 Originalmeddelande Från: Taavi Eomäe via mailop 
 Datum: 2023-02-22  19:42  (GMT+01:00) Till: 
mailop@mailop.org Ämne: Re: [mailop] Compromised email account trends 
___mailop mailing 
listmailop@mailop.orghttps://list.mailop.org/listinfo/mailop___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Compromised email account trends

[Taavi Eomäe via mailop]

This discussion is getting awfully close to reinventing OAuth2.

It's quite clear by now that long-lived tokens that are nearly 
impossible to properly revoke just don't work well in any human-operated 
contexts.


Hopefully we'll see an increase in the adoption of OAuth2 instead of 
rather crude ways of mitigating only half of the issue. Large players 
started pushing Oauth2 for both SMTP and IMAP for a really good reason 
after all.




On 22/02/2023 13:32, Jaroslaw Rafa via mailop wrote:

Dnia 22.02.2023 o godz. 01:51:41 Sebastian Nielsen via mailop pisze:

If you run a hosting service available internationally, do
this:Use a IP to Country service, to get their country.Append country to
password at both creation, change and login time.For example, if my
password is Password123, the password hash in database would be
hash(Password123-Sweden)When trying to login, if I login from sweden, it
would work wonderfully.But if I try to login from Germany, the password
hash would become hash(Password123-Germany) which doesn't match
hash(Password123-Sweden).This is a great way to IP restrict a account so
it only works from the country it was created/bought from.

With this approach, you must *very explicitly* warn your users that their
accounts will work only within the same country. Otherwise, users who are
travelling to another country and expect to be able to access their e-mail
accounts there, might be *very* disappointed. And if someone eg. loses a
big contract due to not being able to access e-mail, you might probably get
sued.

I have also one more idea. Remember the old "POP-before-SMTP" approach from
the times there was no SMTP AUTH yet? I have observed that the
password-cracking bots are heavily attacking submission services, while
relatively very rarely trying to login to IMAP service. On the other hand,
any regular email client first does IMAP login to get the mailbox index, and
then after the user tries to send a message, authenticates to submission
service. So one might simply reject *any* password on submission service, if
there is no recent successful IMAP login to the same account from the same
IP address.


smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] New Groups.io mail servers

[Mark Fletcher via mailop]

Hi All,

fyi, over the next week or two, we'll be warming up 6 additional mail
servers, to complement the two that we already use. Below are all 8 IP
addresses; the first two are our original servers.

Cheers,
Mark

66.175.222.12
66.175.222.108
45.79.227.220
45.79.224.9
45.79.224.7
192.53.124.123
173.255.243.56
192.53.124.254
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Compromised email account trends

[Slavko via mailop]

Dňa 22. februára 2023 14:08:25 UTC používateľ Giovanni Bechis via mailop 
 napísal:

>you should also consider then geolocalization is not perfect and that there
>might be some FP/FN.

Yes, recent days i live in Poland, at least by Maxmind's
GeoIP2Lite Country DB :-)

regards


-- 
Slavko
https://www.slavino.sk/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Compromised email account trends

[Andrew C Aitchison via mailop]

On 2/22/23 12:32, Jaroslaw Rafa via mailop wrote:

I have also one more idea. Remember the old "POP-before-SMTP"
approach from the times there was no SMTP AUTH yet? I have observed
that the password-cracking bots are heavily attacking submission
services, while relatively very rarely trying to login to IMAP
service. On the other hand, any regular email client first does
IMAP login to get the mailbox index, and then after the user tries
to send a message, authenticates to submission service. So one
might simply reject *any* password on submission service, if there
is no recent successful IMAP login to the same account from the
same IP address.


Nice idea.

I would want to check that it works for users like me who
download messages to a local machine (eg with fetchmail).
We might be more likely to write before reading.

Do confirm that the submission port remains open to machine/user pairs
as long as an IMAP connection is using IDLE.

On Wed, 22 Feb 2023, Giovanni Bechis via mailop wrote:

this would not work for me, on my servers ~6% of imap logins are
from bots.


*Successful* IMAP logins ?

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Compromised email account trends

[Gellner, Oliver via mailop]

On 2023-02-22 15:08, Giovanni Bechis via mailop wrote:

>> I have also one more idea. Remember the old "POP-before-SMTP" approach
>> from the times there was no SMTP AUTH yet? I have observed that the
>> password-cracking bots are heavily attacking submission services,
>> while relatively very rarely trying to login to IMAP service. On the
>> other hand, any regular email client first does IMAP login to get the
>> mailbox index, and then after the user tries to send a message,
>> authenticates to submission service. So one might simply reject *any*
>> password on submission service, if there is no recent successful IMAP
>> login to the same account from the same IP address.

> this would not work for me, on my servers ~6% of imap logins are from bots.

Also you have to consider CGNAT scenarios and other setups where the egress IP 
address of a user might change, which would cause intermittent, unexplainable 
breaks when trying to send emails.

--
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.


smime.p7s
Description: S/MIME cryptographic signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Compromised email account trends

[Giovanni Bechis via mailop]

On 2/22/23 12:32, Jaroslaw Rafa via mailop wrote:

Dnia 22.02.2023 o godz. 01:51:41 Sebastian Nielsen via mailop pisze:

If you run a hosting service available internationally, do
this:Use a IP to Country service, to get their country.Append country to
password at both creation, change and login time.For example, if my
password is Password123, the password hash in database would be
hash(Password123-Sweden)When trying to login, if I login from sweden, it
would work wonderfully.But if I try to login from Germany, the password
hash would become hash(Password123-Germany) which doesn't match
hash(Password123-Sweden).This is a great way to IP restrict a account so
it only works from the country it was created/bought from.


With this approach, you must *very explicitly* warn your users that their
accounts will work only within the same country. Otherwise, users who are
travelling to another country and expect to be able to access their e-mail
accounts there, might be *very* disappointed. And if someone eg. loses a
big contract due to not being able to access e-mail, you might probably get
sued.


you should also consider then geolocalization is not perfect and that there
might be some FP/FN.


I have also one more idea. Remember the old "POP-before-SMTP" approach from
the times there was no SMTP AUTH yet? I have observed that the
password-cracking bots are heavily attacking submission services, while
relatively very rarely trying to login to IMAP service. On the other hand,
any regular email client first does IMAP login to get the mailbox index, and
then after the user tries to send a message, authenticates to submission
service. So one might simply reject *any* password on submission service, if
there is no recent successful IMAP login to the same account from the same
IP address.

this would not work for me, on my servers ~6% of imap logins are from bots.

 Regards
  Giovanni


OpenPGP_signature
Description: OpenPGP digital signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Compromised email account trends

[Jaroslaw Rafa via mailop]

Dnia 22.02.2023 o godz. 01:51:41 Sebastian Nielsen via mailop pisze:
> If you run a hosting service available internationally, do
> this:Use a IP to Country service, to get their country.Append country to
> password at both creation, change and login time.For example, if my
> password is Password123, the password hash in database would be
> hash(Password123-Sweden)When trying to login, if I login from sweden, it
> would work wonderfully.But if I try to login from Germany, the password
> hash would become hash(Password123-Germany) which doesn't match
> hash(Password123-Sweden).This is a great way to IP restrict a account so
> it only works from the country it was created/bought from.

With this approach, you must *very explicitly* warn your users that their
accounts will work only within the same country. Otherwise, users who are
travelling to another country and expect to be able to access their e-mail
accounts there, might be *very* disappointed. And if someone eg. loses a
big contract due to not being able to access e-mail, you might probably get
sued.

I have also one more idea. Remember the old "POP-before-SMTP" approach from
the times there was no SMTP AUTH yet? I have observed that the
password-cracking bots are heavily attacking submission services, while
relatively very rarely trying to login to IMAP service. On the other hand,
any regular email client first does IMAP login to get the mailbox index, and
then after the user tries to send a message, authenticates to submission
service. So one might simply reject *any* password on submission service, if
there is no recent successful IMAP login to the same account from the same
IP address.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Compromised email account trends

[Carsten Schiefner via mailop]

Sebastian & all -

On 22.02.2023 01:51, Sebastian Nielsen via mailop wrote:
Didn't get steve's mail for some reason (guess it was because i forgot 
to renew exim tls cert, but its renewed now), but replying to it here.


I have also noticed that: this particular email did not pop into my 
inbox either.


After having looked a bit deeper into this, it appears that Steve 
Freegard replied directly and only to Jarland Donnell on 21 Feb, 12:10 
(timezone?).


Jarland Donnell in turn has then replied publicly to the list again on 
21 Feb, 17:04:02 -0600.


That at least is how I would interpret the present/missing) list footers.

So no mails missed! :-)

Cheers,

-C.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop