Re: [mailop] Outgoing Spam from Microsoft IPs

[Hans-Martin Mosner via mailop]

Am 16.02.24 um 03:37 schrieb Matt Palmer via mailop:

Although I must say that


without reverse DNS

would seem to be the easier blocking option -- when was the last time you
saw legitimate mail from an IP without rDNS?

- Matt


We do that, with some exceptions, as we indeed get some legitimate mail 
without rDNS. However, there seems to be some issue with our rule-based 
engine which results in those e-mails not getting the proper 4.7.1 
response that we use for missing rDNS.


Since the rule engine is lacking in other areas, too (basically we can't 
express complex rules based on combinations of triggers), I intend to 
rewrite it, but that's a volunteer work in my spare time, of which there 
isn't that much :-)


Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] CloudSererblocks - was Re: Outgoing Spam from Microsoft IPs

[Andrew C Aitchison via mailop]

On Fri, 16 Feb 2024, Matt Palmer via mailop wrote:


On Wed, Feb 14, 2024 at 07:57:09AM +0100, Hans-Martin Mosner via mailop wrote:

  Is there some way to identify the host IPs which are
used by those cloud servers, so one could block incoming SMTP from them if
Microsoft can't be bothered to block outgoing SMTP?


https://www.microsoft.com/en-au/download/details.aspx?id=56519 would seem to
meet the case.  I can't help but chuckle at the admonition that people
should download the JSON file each week, when they don't appear to provide a
stable URL to do so...


For Amazon and Google
"Jo" https://list.mailop.org/private/mailop/2021-June/019392.html 
recommended:


AMAZON
   https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html
   https://ip-ranges.amazonaws.com/ip-ranges.json

GOOGLE
   https://cloud.google.com/compute/docs/faq#find_ip_range
   https://www.gstatic.com/ipranges/cloud.json

---

For ALIBABA,
   whois -H 2600:3100::
lead me to
   https://whois.arin.net/rest/org/AL-3/nets
   https://rdap.arin.net/registry/entity/AL-3

I have not seen these advertised so can't call them official
and they may contain legitimate mail senders ...
I don't have traffic from Alibaba so cannot judge for myself.

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

Re: [mailop] Opinions on what qualifies as a "false positive" RBL listing that should be fixed?

[Robert L Mathews via mailop]

On Feb 15, 2024, at 6:13 PM, Dave Crocker via mailop  wrote:

> Not using COI, as well as hitting spamtraps are both solid, affirmative 
> indications of spam. Full stop.

Interesting, thanks. I find I disagree with the "full stop" part, but it seems 
I'm in the minority.

Don't get me wrong -- lack of COI is annoying to others, and an indication of 
poor list hygiene that should be fixed. And in many cases, lack of COI 
obviously *is* connected to further abuse ("spam").

But in my mind, when seen by itself -- that is, when it's "some 
otherwise-legitimate transactional messages are going to typoed addresses 
because the unwise lack of COI" without other problems -- it's not "malicious 
activities" or "spam". I think of misdirected transactional mail as being in a 
separate category than, say, an open web form being abused by spammers where 
they control both the recipient addresses and the message subject/contents.

The latter is the kind of thing I want an RBL to block for my users, regardless 
of whether there is also a small amount of legitimate mail coming from that 
form. But I generally wouldn't want to block addresses because they send some 
misdirected transactional mail, unless it's being used as part of a mailbombing 
amplification attack or something.

But from the responses, I'm just being naïve in expecting RBLs to treat those 
differently. Thanks!

-- 
Robert L Mathews

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

[mailop] Verifying receipients?

[Jesse Hathaway via mailop]

What is this current attitude on using something like
Postfix's `reject_unverified_recipient`?
Does probing for recipients work these days, is it considered abusive?

Yours kindly, Jesse Hathaway
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] CloudSererblocks - was Re: Outgoing Spam from Microsoft IPs

[Slavko via mailop]

Dňa 16. februára 2024 19:42:08 UTC používateľ Andrew C Aitchison via mailop 
 napísal:

>AMAZON
>   https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html
>   https://ip-ranges.amazonaws.com/ip-ranges.json

Please, is somewhere described what "service" values means in it?

regards


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

Re: [mailop] Is forwarding to Gmail basically dead?

[Gellner, Oliver via mailop]

> On 15.02.2024 at 03:55 Philip Paeps wrote:
>
> On 2024-02-15 02:51:17 (+0800), Gellner, Oliver via mailop wrote:
>>> On 13.02.2024 at 17:05 John Levine via mailop wrote:
>>> More to the point, whether it's DKIM nor S/MIME or PGP, bad guys can
>>> and do sign their mail, too.
>> True, however I never came across a S/MIME- or PGP-signed spam or phishing 
>> message - and we receive a lot of S/MIME emails. I wonder if others on this 
>> list have made different experiences.
>
> I see a fair amount of S/MIME phishing.  As John points out: S/MIME is a very 
> regional thing.  As far as I can tell, it's something people in Europe do a 
> lot and people elsewhere do very rarely.
>
> Having said that: I have seen S/MIME and even PGP signed spear fishing.

In spear phishing attacks everything is possible, but can you share some 
information about which senders send S/MIME signed or perhaps even encrypted 
spam messages? I‘d be interested to learn more about this.

—
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.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Verifying receipients?

[Marco Moock via mailop]

Am Fri, 16 Feb 2024 14:49:12 -0600
schrieb Jesse Hathaway via mailop :

> Does probing for recipients work these days, is it considered abusive?

Use the VRFY SMTP command for that. If the remote site doesn't provide
it, they don't want that somebody probes for the mailboxes.

Some dnsbl (e.g. uceprotect) list servers that probe wit RCPT TO.

If you want to make forging harder, strictly check SPF/DKIM and make it
mandatory for senders to deliver mail to you.

You also need to notice that a positive result from RCPT TO doesn't
mean that the mailbox really exists.
Some sites accept such messages and create a bounce later.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Verifying receipients?

[Bill Cole via mailop]

On 2024-02-16 at 15:49:12 UTC-0500 (Fri, 16 Feb 2024 14:49:12 -0600)
Jesse Hathaway via mailop 
is rumored to have said:


What is this current attitude on using something like
Postfix's `reject_unverified_recipient`?


ONLY use this when you are relaying for specific domains that you 
service where you do not have any way to obtain a definitive user list.



Does probing for recipients work these days, is it considered abusive?


Probing for recipients on systems where you do not have explicit prior 
permission to do so is asking to be treated like a criminal. It also 
tends not to work.


The same goes for sender verification.

--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Opinions on what qualifies as a "false positive" RBL listing that should be fixed?

[John Levine via mailop]

It appears that Robert L Mathews via mailop  said:
>On Feb 15, 2024, at 6:13 PM, Dave Crocker via mailop  wrote:
>
>> Not using COI, as well as hitting spamtraps are both solid, affirmative 
>> indications of spam. Full stop.
>
>Interesting, thanks. I find I disagree with the "full stop" part, but it seems 
>I'm in the minority.
>
>Don't get me wrong -- lack of COI is annoying to others, and an indication of 
>poor list hygiene that should be fixed. And in many
>cases, lack of COI obviously *is* connected to further abuse ("spam").

I think a lot of us agree with you. If a sender has some way to be
reasonably sure that the people they're mailing want the mail, I don't
really care whether it's COI or something else. But the cases where
there is something other than COI that actually works are not common.

In a case like this, I expect that some people mistyped their address,
and some gave fake addresses because they didn't trust the library to
handle their address properly.  Whatever the reason, they're sending
spam to people who didn't ask for it and don't want it.

>The latter is the kind of thing I want an RBL to block for my users, 
>regardless of whether there is also a small amount of legitimate
>mail coming from that form. But I generally wouldn't want to block addresses 
>because they send some misdirected transactional mail,
>unless it's being used as part of a mailbombing amplification attack or 
>something.

We are really, really tired of excuses about why it's too hard to
manage address lists properly and we are so nice that you can't
block us.

As you may have heard a few times, if you don't want to be treated as a 
spammer, don't act like one.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Verifying receipients?

[Slavko via mailop]

Dňa 16. februára 2024 21:03:18 UTC používateľ Marco Moock via mailop 
 napísal:

>Use the VRFY SMTP command for that. If the remote site doesn't provide
>it, they don't want that somebody probes for the mailboxes.

IMO only between own servers, if at all. Disabling it (for public access)
is suggested by RFC 2505 (25 years ago).

>Some dnsbl (e.g. uceprotect) list servers that probe wit RCPT TO.

Of course, one simple cannot use my resources for own security (nor
harvesting)!

regards


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

Re: [mailop] Opinions on what qualifies as a "false positive" RBL listing that should be fixed?

[Michael Rathbun via mailop]

On Fri, 16 Feb 2024 12:33:21 -0800, Robert L Mathews via mailop
 wrote:

>Interesting, thanks. I find I disagree with the "full stop" part, but it seems 
>I'm in the minority.

Perhaps.  I take Google for an example.  Fossicking through the logs here, I
find...

>> cidrsearch *all /nonu /ru=google.cid   | search screening
> Fri 2024-02-09 05:05:03.170: SMTP screening added 209.85.216.52; sender 
> triggered a spam honeypot
> Fri 2024-02-09 05:06:13.206: SMTP screening added 209.85.214.175; sender 
> triggered a spam honeypot
> Fri 2024-02-09 10:42:24.109: Dynamic screening refused connection to 
> 192.168.1.2:25 from 209.85.216.52; 1104 minutes remain
> Sat 2024-02-10 09:53:13.686: SMTP screening added 209.85.208.169; sender 
> triggered a spam honeypot
> Thu 2024-02-15 13:33:20.263: SMTP screening added 209.85.218.66; sender 
> triggered a spam honeypot
> Thu 2024-02-15 23:11:21.318: SMTP screening added 35.221.19.77; sender 
> triggered a spam honeypot

which tells us that Google has sent (or rather, has enabled to be sent) email
to "honeypots", which I designate as "sudden death spamtraps".  If you send to
one of these, your IP will be dropped into a list which will cause
>  530 4.7.0 Connection refused 
to be the response for 1 day, 3 days, 9 days, or 11 days, 9 hours, 4 minutes.

The "refused" connection was for the delivery of a message from an old friend
and current business partner.  He subsequently forwarded the DSN to me, with
the original message appended, I explained the business continuity risks of
using "free" email services that apparently have ineffective policy
enforcement (not to mention that we are discussing details of a product that
will, should it succeed, seriously challenge Google in one of its areas of
interest, especially since I know with certainty that their system reads every
message you send or receive).

If you are sending email to "nadine @ honet.com" or to some guy in Switzerland
who signed up at dozens of porno sites using a honet.com user ID well before
honet.com was registered (1997), you are NOT a legitimate sender of email.

Full stop

mdr
-- 
The hits just keep on coming for poor "Nadine". See the sad tale 
of email lists gone horribly wrong at 
F - IWAA #2157 GEVNP
  

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