Re: [mailop] [INFORMATION] What's happening in the world of spam/email abuse update

[Noel Butler via mailop]

On 28/04/2021 17:05, Jaroslaw Rafa via mailop wrote:


Dnia 28.04.2021 o godz. 10:19:17 Noel Butler via mailop pisze:


What's so hard about 1 ?

What do we do with any S.P. that emits tonnes of crap, we block
them, often outright, nothing hard about that.

It shouldn't matter how big a company is, it certainly didn't 20
years ago when most people here who were around at the time would
have blocked AOL
for the exact same thing, yet people are scared to block the
freemailers these days, why, it's those actions that force said
companies to pull their finger out of their arse and clean up their
network, if they don't, well, like i said,  AOL, they become
irrelevant.


From "normal" people (ie. not email-related professionals like on this
list) that I correspond with, about 70% have email addresses on Gmail. 
There
are also numerous companies that use Gsuite for their work email (and 
among

them are really big corporations, like my employer). The popularity of
smartphones and mobile applications has a big impact on this. So 
blocking
Google is like blocking 70% or more of your possible correspondents. If 
you
can afford this, then good luck, but most people cannot. Google just 
grew

too big and for a small email operator (and almost everyone is small
compared to Google) blocking Google will hurt themselves more than it 
will

hurt Google.


you see, this is EXACTLY what I am talking about

it is EXACTLY what google counts on and google does S F A about it.

I've blocked them in the past yes, I have no hesitation in doing so 
again.


nobody, but nobody, is too big to block to protect my users.

--
Regards,
Noel Butler

This Email, including attachments, may contain legally privileged 
information, therefore at all times remains confidential and subject to 
copyright protected under international law. You may not disseminate 
this message without the authors express written authority to do so.   
If you are not the intended recipient, please notify the sender then 
delete all copies of this message including attachments immediately. 
Confidentiality, copyright, and legal privilege are not waived or lost 
by reason of the mistaken delivery of this message.___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Blocked by AOL/Yahoo

[Lili Crowley via mailop]

Please contact me off list.
thanks!

Lili Crowley
Postmaster
Verizon Media


On Wed, Apr 28, 2021 at 9:34 AM Ryan Wittenauer via mailop <
mailop@mailop.org> wrote:

> Hello,
>
>
>
> Any Verizon postmasters out there I can speak with?
>
> We had a compromised user on our network spam overnight and a recent
> server upgrade broke our IDS rules we have in place to stop something like
> this (Smartermail 7776 if anyone is curious).
>
>
>
> We’ve swapped over to a different sending IP that is close to our original
> and is still getting blocked.
>
> Anyone out there that can assist and give us a slightly faster resolution?
>
>
>
> *Ryan Wittenauer ** System Administrator*
>
> p. 330-707-0432 Option 3  |  www.idmi.net
> 
> | support.idmi.net
>
> *IDMI.Net* |  124 South Main St. |  Poland, Ohio 44514
>
>
> ___
> mailop mailing list
> mailop@mailop.org
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__list.mailop.org_listinfo_mailop=DwIGaQ=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmiT9yOhqES_g_wVY=VCg-Q9ZdQlK27bNQMmErgRlkvpS8hDriASSkCoU3s2s=rcm01Ev3cmcFUEGiwYxwU18zmpada9Wf7CceibkKYWc=OUKioCdmhCeIG6LUQCbhfFz9PCMmnKusSZWJjQ8aLQ4=
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Blocked by AOL/Yahoo

[Ryan Wittenauer via mailop]

Hello,

Any Verizon postmasters out there I can speak with?
We had a compromised user on our network spam overnight and a recent server 
upgrade broke our IDS rules we have in place to stop something like this 
(Smartermail 7776 if anyone is curious).

We've swapped over to a different sending IP that is close to our original and 
is still getting blocked.
Anyone out there that can assist and give us a slightly faster resolution?

Ryan Wittenauer  System Administrator
p. 330-707-0432 Option 3  |  www.idmi.net | 
support.idmi.net
IDMI.Net |  124 South Main St. |  Poland, Ohio 44514

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

Re: [mailop] Spam from Google Work Space sender domain via Google IP(s)

[Vsevolod Stakhov via mailop]

On 28/04/2021 05:27, vsai--- via mailop wrote:
> Hi,
>  
> I've been receiving spam and phishing scams from Google IP(s).
> 
> All these messages have the sender domains associated either with
> Godaddy or with Google work space.
> 
> Some of the sample sender domains are listed below:
> 
> **
> craigmaldonado.monster
> kepinbujang35.online
> kepinbujang247.online
> memekssuper247.online
> bujangmememks287.online
> baukkmemmek23792.online
> memekbusukk23.online
> memekssuper.online
> baukkmemmek23993.online
> kilokara.monster
> rogelioholland.today
> memekspromhome23.online
> bujangmememks248.online
> komkarasa.monster
> loduviskin.monster
> tommienguyen.world
> **

If you use Rspamd, then the solution recipe is pretty trivial. Use rbl
module with a custom selector to filter out fresh domains from the
X-BeenThere header (using, for example Spam Eating Monkey list). Here is
the complete example:

Add the following to the `/etc/rspamd/rspamd.local.lua` to register a
custom extraction routine:

```
-- Add to rspamd.local.lua
local lua_selectors = require "lua_selectors"
local rspamd_util = require "rspamd_util"

lua_selectors.register_extractor(rspamd_config, 'x_been_there_tld', {
  get_value = function(task, args)
local res = {}
local hdr = task:get_header_full('X-BeenThere')

if hdr then
  for _,h in ipairs(hdr) do
local email_maybe = rspamd_util.parse_mail_address(h.decoded,
task:get_mempool())

if email_maybe and email_maybe[1] then
  table.insert(res, rspamd_util.get_tld(email_maybe[1].domain))
end
  end
end
return res, 'string_list'
  end,
  description = 'Table with a list of X-Been-There eslds'
})
```

Then use this selector in the RBL module by adding the following to
`/etc/rspamd/local.d/rbl.conf`:

```
# local.d/rbl.conf
rules {
  SEM_FRESH_X_BEEN_THERE {
selector = "x_been_there_tld()";
rbl = fresh30.spameatingmonkey.net;
score = 4.0;
  }
}
```

This rule is pretty aggressive so I would also limit it with some list
of the most abused top level domains (such as `.today`, `.xyz` and other
crap).
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Spam from Google Work Space sender domain via Google IP(s)

[Arne Jensen via mailop]

Den 28-04-2021 kl. 06:27 skrev vsai--- via mailop:
> I've been receiving spam and phishing scams from Google IP(s).
>
> All these messages have the sender domains associated either with
> Godaddy or with Google work space.
>
> Some of the sample sender domains are listed below:
>
> **

Several of these domains exists in Spam Eating Monkey's FRESH lists,
since they were registered very recently, some of them 2 days old, some
of them around 10 days.

-> https://spameatingmonkey.com/

You might be able to use the FRESH list to trigger on domains that were
registered (very) recently, with their FRESH lists.

A couple of the listed domains that does not appear in SEM FRESH, seems
to exist in URIBL's "black" zone:

-> https://uribl.com/


Licenses and terms/conditions for various of such "reputation" lists may
vary quite a lot, so you will seriously need to go through their
policies, to figure out if you are able to incorporate their data in
your systems.

Not doing so from the beginning, might cause severe consequences...


>
> I could see couple of patterns in these spam.
>
> 1. Spamming from Google groups with topic 25838:
>
>    Example: List-Help:
> ,

SEM FRESH and URIBL mentioned above would here require you to split it
out to the real domain, e.g. "lanawilliams.today", before you look it up.

Even if you  go to
"https://support.google.com/a/this.stuff.does.not.exist.invalid/bin/topic.py?topic=25838;,
you will also be redirected to
"https://support.google.com/a/topic/25838;, so you have some options here:

a) With the classic kind of learning spam/ham in spam filters, you might
be able to make your systems"learn" the full/exact link towards being
either spam/ham, but with the amount of different possibilities there
could be, e.g.:

->
https://support.google.com/a/this.stuff.does.not.exist.invalid/bin/topic.py?topic=25838
->
https://support.google.com/a/another.one.that.does.not.exist.invalid/bin/topic.py?topic=25838

That option may not be very feasible, ... for some.

b) You could split out the "real domain" from the URI if it matches the
Google link, and then look up the domain in various of those URI / RHS
lists.

->
https://support.google.com/a/bfjnusfg.lanawilliams.today/bin/topic.py?topic=25838
(lookup: lanawilliams.today)
->
https://support.google.com/a/a.very.simple.example.net/bin/topic.py?topic=25838
(lookup: example.net)
->
https://support.google.com/a/another.fancy.example.co.uk/bin/topic.py?topic=25838
(lookup: example.co.uk)

Depending on your systems, this may not be very simple, such as e.g.
getting "example.co.uk" and other second-, third- (or further level)
registrations like there.


For the extracting, I would however suggest using the Public Suffix list:

-> https://publicsuffix.org/

There are some libraries out there for many programming languages out there.

>    
> 2. Received lines has lines either single or multiple "X-Received: by
> 2002"
>
>    Example:
>     ***
>     X-Received: by 2002:ac2:5f75:: with SMTP id
> c21mr4375339lfc.600.1618693533415;
>     Sat, 17 Apr 2021 14:05:33 -0700 (PDT)
IPv6 subnet 2002:ac2:5f75::/48, refers to IPv4 address 10.194.95.117.
>     Received: by 2002:a05:6512:c22:: with SMTP id
> z34ls4162850lfu.2.gmail; Sat, 17
>      Apr 2021 14:05:32 -0700 (PDT)
IPv6 subnet 2002:a05:6512::/48, refers to IPv4 address 10.5.101.18.
>     X-Received: by 2002:a19:7508:: with SMTP id
> y8mr7152413lfe.123.1618693532208;
>     Sat, 17 Apr 2021 14:05:32 -0700 (PDT)
>     ***

IPv6 subnet 2002:a19:7508::/48, refers to IPv4 address 10.25.117.8.

These IPv6 addresses/subnets are part of the 2002::/16 6to4 anycast
network. So I wouldn't put any weight to them.

Maybe if you expanded them to the IPv4 addresses (hex decode the IPv4
with the first two groups after 2002: minus any :'s in the middle
(ac25f75, a056512 & a197508)), and then maybe if these were actually
revealing other "public IP addresses", and not private/reserved IP
addresses, there might be a chance of using them to detect stuff.

The majority (if not all) of Google email headers seem to indicate
Google is using the 10.0.0.0/8 equivalent of the 6to4 IPv6 space (e.g.
2002:a00::/24  (2002:0a00:::::: -
2002:0aff::::::)) in their internal networks.

>     
> Please let us know if anyone is observing same trend of spam and what
> measures are taken to prevent these patterns.

Personally, I'm not currently experiencing it with Google, however - the
trend of using (... very) fresh domains seems to have raised over the
last months, and I do not mind rejecting domains younger than e.g. 30
days myself.


Another situation you could do to above, but which can cause collateral
damage in several situations, would be to look up each 

Re: [mailop] [INFORMATION] What's happening in the world of spam/email abuse update

[Jaroslaw Rafa via mailop]

Dnia 28.04.2021 o godz. 10:19:17 Noel Butler via mailop pisze:
> 
> What's so hard about 1 ?
> 
> What do we do with any S.P. that emits tonnes of crap, we block
> them, often outright, nothing hard about that.
> 
> It shouldn't matter how big a company is, it certainly didn't 20
> years ago when most people here who were around at the time would
> have blocked AOL
> for the exact same thing, yet people are scared to block the
> freemailers these days, why, it's those actions that force said
> companies to pull their finger out of their arse and clean up their
> network, if they don't, well, like i said,  AOL, they become
> irrelevant.

From "normal" people (ie. not email-related professionals like on this
list) that I correspond with, about 70% have email addresses on Gmail. There
are also numerous companies that use Gsuite for their work email (and among
them are really big corporations, like my employer). The popularity of
smartphones and mobile applications has a big impact on this. So blocking
Google is like blocking 70% or more of your possible correspondents. If you
can afford this, then good luck, but most people cannot. Google just grew
too big and for a small email operator (and almost everyone is small
compared to Google) blocking Google will hurt themselves more than it will
hurt Google.
-- 
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

[mailop] WG: Best practices for outbound rate limiting?

[Stefan Bauer via mailop]

Hi Nami,



incoming rate limiting works fine, if your users send through a mailsever, that 
can deal with the 400-errors, your MTA generates, throttle and try again later. 
However if you have mail clients that send, a 400-error is a real error to the 
user and they probably do not even understand, whats going on and will try on 
and on.



Also outgoing rate limiting should be in place to not annoy other mailservers.



Additonally i always like to learn from users behavior. So i would not only 
limit amount of mail, i would also scan for spam/virus etc and monitor all of 
it.



Spammers do not only send many mails at once, they send also at very low rate 
but ongoing. Rate limiting would not take care of this.





Stefan Bauer.



-Ursprüngliche Nachricht-
Von: missytake via mailop 
Gesendet: Dienstag 27 April 2021 18:31
An: mailop@mailop.org
Betreff: [mailop] Best practices for outbound rate limiting?



Hi,

we have a small semi-open-registration mail server (not systemli.org, in

case you are wondering) and we would like to learn more about best
practices for rate limiting outgoing mail. We are using postfix.

We don't want to restrict our users too much, but obviously we also care

about not burdening the mail ecosystem with spam, and it's possible,
though not very likely that spammers find out how to automatically use
our registration mechanism.

The smtpd_client_message_rate_limit option seems to do the trick, and we

are thinking about setting it to 20 - is this enough to make it
unprofitable for spammers, but not annoy our users? What are your
experiences?

Thanks,
Nami

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