Re: [mailop] Extortion spam from OVH-hosted *.sbs domains

[Christopher Hawker via mailop]

If the abuse contact (ab...@ovh.net) is not responding to e-mails report the 
lack of response to RIPE NCC, the RIR that delegated the resources to them. I 
know that if members under APNIC fail to maintain an abuse and IRT contact 
their account is suspended until it is validated.

I already filter all mail traffic from OVH. They are notorious for failing to 
act on abuse reports.

Regards,
Christopher Hawker

From: mailop  on behalf of Hans-Martin Mosner via 
mailop 
Sent: Thursday, January 25, 2024 5:10 PM
To: mailop 
Subject: [mailop] Extortion spam from OVH-hosted *.sbs domains


Tonight we received a huge wave of extortion spams from OVH hosted domains 
trying to get bitcoin payments. The senders claim that recipients watched child 
porn.

This is the final straw for me to add a rule to reject all mail traffic from 
OVH until the sender is whitelisted. OVH is completely unresponsive to abuse 
complaints, they won't even react when clearly criminal activity happens from 
their IP space.

The domains used were:

aoyn.sbs
bnop.sbs
burx.sbs
enux.sbs
fojr.sbs
hnls.sbs
nbot.sbs
ouhb.sbs
pxur.sbs
rnuh.sbs

with the IP addresses

51.89.5.129
51.89.5.145
51.89.175.30
51.89.175.173
51.89.175.196
54.38.1.200
57.128.16.249
57.128.60.137
57.128.83.193
57.128.123.32
57.128.165.75
57.128.166.120
91.134.96.213
91.134.97.224
91.134.97.232
135.125.66.34
135.125.66.86
135.125.66.217
135.125.217.78
141.94.64.94
141.95.108.175
148.113.137.42
148.113.139.81
148.113.140.91
148.113.141.117
148.113.143.4
162.19.68.117

It's probably pointless to call for a general OVH boycott, as much as I would 
like to do that :-)

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

Re: [mailop] Is Google jumping the gun for SPF / DKIM requirement?

[Marco Moock via mailop]

Am 24.01.2024 um 21:48:39 Uhr schrieb Grant Taylor via mailop:

> I knew that Google was going to start requiring SPF or DKIM (in
> addition to other sender guidelines [1].  But I thought they were
> starting February 1st, per their own sender guidelines.

IIRC Google starts to require DKIM for bulk senders (more than 5000
msgs) in Feb.

<<< 550-5.7.26  DKIM = did not pass
<<< 550-5.7.26  SPF [redacted.example.net] with ip: [192.0.2.1] = 
did not pass

Both don't pass here, so fix SPF and try again.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Extortion spam from OVH-hosted *.sbs domains

[Hans-Martin Mosner via mailop]

Tonight we received a huge wave of extortion spams from OVH hosted domains trying to get bitcoin payments. The senders 
claim that recipients watched child porn.


This is the final straw for me to add a rule to reject all mail traffic from OVH until the sender is whitelisted. OVH is 
completely unresponsive to abuse complaints, they won't even react when clearly criminal activity happens from their IP 
space.


The domains used were:

aoyn.sbs
bnop.sbs
burx.sbs
enux.sbs
fojr.sbs
hnls.sbs
nbot.sbs
ouhb.sbs
pxur.sbs
rnuh.sbs

with the IP addresses

51.89.5.129
51.89.5.145
51.89.175.30
51.89.175.173
51.89.175.196
54.38.1.200
57.128.16.249
57.128.60.137
57.128.83.193
57.128.123.32
57.128.165.75
57.128.166.120
91.134.96.213
91.134.97.224
91.134.97.232
135.125.66.34
135.125.66.86
135.125.66.217
135.125.217.78
141.94.64.94
141.95.108.175
148.113.137.42
148.113.139.81
148.113.140.91
148.113.141.117
148.113.143.4
162.19.68.117

It's probably pointless to call for a general OVH boycott, as much as I would 
like to do that :-)

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

Re: [mailop] Is Google jumping the gun for SPF / DKIM requirement?

[Grant Taylor via mailop]

On 1/24/24 22:12, Alexander Neilson via mailop wrote:

Was this over v6?


Nope.  Hence the Test-Net-1 IPv4 address.

This was on a friends system and said friend is an IPv4 stalwart in that 
he sees no benefit for the additional time and overhead for IPv6 for his 
small business that has sufficient IPv4 space.  --  I've tried to get 
him to use IPv6, even a tunnel from H.E. and he has declined many times.



Haven’t they required this on v6 for a while so this may just be that.


Yes.



--
Grant. . . .


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

Re: [mailop] Is Google jumping the gun for SPF / DKIM requirement?

[Grant Taylor via mailop]

On 1/24/24 22:09, Russell Clemings via mailop wrote:

I saw it a couple of weeks ago.
I wonder if what they meant by February 1st is that's when they would 
hit the 100% requirement and they are doing the 1% / 5% / 10% / 50% / 
80% / 100% ramp up now.



Similar, a server reporting in via cron.


ACK

It was pretty easy to fix once I realized that I needed a separate 
SPF for each subdomain.
Ya.  I'll end up creating very basic SPF records for each host.  I guess 
I know what I'm working on over the next few days.


I had thought the record for the parent domain would cover it, but 
I guess I was the only person who thought that.


I used to think that a long time ago.  But I don't remember when I 
stopped or what I ran into that caused me to stop.




--
Grant. . . .


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

Re: [mailop] Is Google jumping the gun for SPF / DKIM requirement?

[Alexander Neilson via mailop]

Regards
Alexander

Alexander Neilson
Neilson Productions Limited
021 329 681
alexan...@neilson.net.nz

> On 25/01/2024, at 16:56, Grant Taylor via mailop  wrote:
> 
> Hi,
> 
> I knew that Google was going to start requiring SPF or DKIM (in addition to 
> other sender guidelines [1].  But I thought they were starting February 1st, 
> per their own sender guidelines.
> 
> I saw a bounce from a system (cron job output) trying to send directly to 
> gmail.com, no forwarding involved.

Was this over v6? Haven’t they required this on v6 for a while so this may just 
be that. 

> 
>   <<< 550-5.7.26 This mail has been blocked because the sender is 
> unauthenticated.
>   <<< 550-5.7.26 Gmail requires all senders to authenticate with either SPF 
> or DKIM.
>   <<< 550-5.7.26
>   <<< 550-5.7.26  Authentication results:
>   <<< 550-5.7.26  DKIM = did not pass
>   <<< 550-5.7.26  SPF [redacted.example.net] with ip: [192.0.2.1] = did not 
> pass
>   <<< 550-5.7.26
>   <<< 550-5.7.26  For instructions on setting up authentication, go to
>   <<< 550 5.7.26 https://support.google.com/mail/answer/81126#authentication 
> d20-20020a05683025d400b006dc5452f468si4641458otu.190 - gsmtp
>   554 5.0.0 Service unavailable
> 
> Am I missing something obvious or has Google started implementing this new 
> requirement ahead of their published schedule?
> 
> The only surprise to me is that this happened ~8 days before the published 
> February 1st date.
> 
> [1] 
> https://support.google.com/a/answer/81126#zippy=%2Crequirements-for-all-senders
> 
> 
> 
> --
> Grant. . . .
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Is Google jumping the gun for SPF / DKIM requirement?

[Jeffrey Williams via mailop]

In past mailop posts, Brandon Long from Google has posted about that.  For
example, on September 12th, 2023:
"And yes, we are continuing to ramp no auth, no entry."

There was also a more recent post on the list with additional details about
their Feb. 1st changes.

Hope this helps,
-Jeffrey

On Wed, Jan 24, 2024 at 9:48 PM Grant Taylor via mailop 
wrote:

> Hi,
>
> I knew that Google was going to start requiring SPF or DKIM (in addition
> to other sender guidelines [1].  But I thought they were starting
> February 1st, per their own sender guidelines.
>
> I saw a bounce from a system (cron job output) trying to send directly
> to gmail.com, no forwarding involved.
>
> <<< 550-5.7.26 This mail has been blocked because the sender is
> unauthenticated.
> <<< 550-5.7.26 Gmail requires all senders to authenticate with
> either SPF or DKIM.
> <<< 550-5.7.26
> <<< 550-5.7.26  Authentication results:
> <<< 550-5.7.26  DKIM = did not pass
> <<< 550-5.7.26  SPF [redacted.example.net] with ip: [192.0.2.1] =
> did not pass
> <<< 550-5.7.26
> <<< 550-5.7.26  For instructions on setting up authentication, go to
> <<< 550 5.7.26
> https://support.google.com/mail/answer/81126#authentication
> d20-20020a05683025d400b006dc5452f468si4641458otu.190 - gsmtp
> 554 5.0.0 Service unavailable
>
> Am I missing something obvious or has Google started implementing this
> new requirement ahead of their published schedule?
>
> The only surprise to me is that this happened ~8 days before the
> published February 1st date.
>
> [1]
>
> https://support.google.com/a/answer/81126#zippy=%2Crequirements-for-all-senders
>
>
>
> --
> Grant. . . .
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>


-- 
*Jeffrey Williams, Tech Lead*
*Berkeley IT (bIT)* 
j...@berkeley.edu
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Is Google jumping the gun for SPF / DKIM requirement?

[Russell Clemings via mailop]

I saw it a couple of weeks ago. Similar, a server reporting in via cron. It
was pretty easy to fix once I realized that I needed a separate SPF for
each subdomain. I had thought the record for the parent domain would cover
it, but I guess I was the only person who thought that.

On Wed, Jan 24, 2024, 7:54 PM Grant Taylor via mailop 
wrote:

> Hi,
>
> I knew that Google was going to start requiring SPF or DKIM (in addition
> to other sender guidelines [1].  But I thought they were starting
> February 1st, per their own sender guidelines.
>
> I saw a bounce from a system (cron job output) trying to send directly
> to gmail.com, no forwarding involved.
>
> <<< 550-5.7.26 This mail has been blocked because the sender is
> unauthenticated.
> <<< 550-5.7.26 Gmail requires all senders to authenticate with
> either SPF or DKIM.
> <<< 550-5.7.26
> <<< 550-5.7.26  Authentication results:
> <<< 550-5.7.26  DKIM = did not pass
> <<< 550-5.7.26  SPF [redacted.example.net] with ip: [192.0.2.1] =
> did not pass
> <<< 550-5.7.26
> <<< 550-5.7.26  For instructions on setting up authentication, go to
> <<< 550 5.7.26
> https://support.google.com/mail/answer/81126#authentication
> d20-20020a05683025d400b006dc5452f468si4641458otu.190 - gsmtp
> 554 5.0.0 Service unavailable
>
> Am I missing something obvious or has Google started implementing this
> new requirement ahead of their published schedule?
>
> The only surprise to me is that this happened ~8 days before the
> published February 1st date.
>
> [1]
>
> https://support.google.com/a/answer/81126#zippy=%2Crequirements-for-all-senders
>
>
>
> --
> Grant. . . .
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Is Google jumping the gun for SPF / DKIM requirement?

[Grant Taylor via mailop]

Hi,

I knew that Google was going to start requiring SPF or DKIM (in addition 
to other sender guidelines [1].  But I thought they were starting 
February 1st, per their own sender guidelines.


I saw a bounce from a system (cron job output) trying to send directly 
to gmail.com, no forwarding involved.


   <<< 550-5.7.26 This mail has been blocked because the sender is 
unauthenticated.
   <<< 550-5.7.26 Gmail requires all senders to authenticate with 
either SPF or DKIM.

   <<< 550-5.7.26
   <<< 550-5.7.26  Authentication results:
   <<< 550-5.7.26  DKIM = did not pass
   <<< 550-5.7.26  SPF [redacted.example.net] with ip: [192.0.2.1] = 
did not pass

   <<< 550-5.7.26
   <<< 550-5.7.26  For instructions on setting up authentication, go to
   <<< 550 5.7.26 
https://support.google.com/mail/answer/81126#authentication 
d20-20020a05683025d400b006dc5452f468si4641458otu.190 - gsmtp

   554 5.0.0 Service unavailable

Am I missing something obvious or has Google started implementing this 
new requirement ahead of their published schedule?


The only surprise to me is that this happened ~8 days before the 
published February 1st date.


[1] 
https://support.google.com/a/answer/81126#zippy=%2Crequirements-for-all-senders




--
Grant. . . .


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

Re: [mailop] Samsung and SIZE

[Ángel via mailop]

On 2024-01-15 at 16:03 -0800, Randolf Richardson, Postmaster wrote:
> > I have seen my share of MUAs that behave in weird ways when
> > encountering things larger than it can handle, so you have
> > to  always cope for them in the mail server. Implementing different
> > types of restrictions, and filtering things out of subjects and
> > certain headers to evade crashing MUAs.
> 
>   998 characters (not including CRLF), as I recall, is the
> maximum 
> limit, which is specified in RFC 5322 (section 2.1.1):
> 
>   RFC 5322 :: Internet Message Format
>   
> https://datatracker.ietf.org/doc/html/rfc5322#section-2.1.1

That's the limit for the *physical* line. The Subject: header could
span multiple lines and thus be larger.

Not that a Subject so large would make sense. I doubt your client would
be able to show it to the user.
Processing the email as if the subject was made of just the first 255
characters seems acceptable to me.

OTOH, I have seen people writing long emails, all in the Subject: line,
with hundreds of bytes.

Yes, some people advocate for subject-only emails, but it didn't seem
done on purpose.
https://www.lifewire.com/what-is-eom-end-of-message-1171156

It didn't make sense. The user somehow confused the field where they
should write...




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

Re: [mailop] [External] seeking a spamtrap milter

[Jaroslaw Rafa via mailop]

Dnia 24.01.2024 o godz. 11:57:13 Randolf Richardson, Postmaster via mailop 
pisze:
> > But, in reality not really worth the trouble.. domains are easy to 
> > forge, and innocent companies maybe trying to verify the address, 
> > because a bad guy used it in a contact form..
> 
>   Not when SPF/DKIM/DMARC are configured properly.  Unfortunately, you 
> are generally correct because many domains that are actively used for 
> legitimate eMail don't employ SPF/DKIM/DMARC to prevent forgeries. :(

As far as I understand, this staement was referring to *receiving* domain,
and not the *sending* domain - especially that "contact form" is mentioned.

The OP wants to process messages *received* by domains that *should not be
mailed to* and use these messages to feed a spamtrap. The "domains are easy
to forge" statement referred - in my opinion - to the fact that some malicious
actor can put an address in this "not-to-be-mailed" domain for example in a
newsletter subscription form on a completely legitimate website. That
website will send a confirmation message (which will be properly
SPF/DKIM/DMARC autenticated) to a "spamtrap" address, thus ending up blocked.
-- 
Pozdrowienia,
   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] [External] seeking a spamtrap milter

[Randolf Richardson, Postmaster via mailop]

> On 2024-01-23 12:35, Randolf Richardson, Postmaster via mailop wrote:
> >>> Hi folks,
> >>>
> >>> I suspect this exists, but can't come up with the right search.
> >>>
> >>> I have domains that should never receive mail. I'd like a milter that
> >>> looks for mail to those domains and feeds the IP of the sender to an
> >>> outside program.
> >>>
> >>> Surely someone wrote this spamtrap software? Or does everyone just
> >>> parse the log?
> >>
> >> Ever looked at MIMEDefang?  You can write your milter code in Perl.
> > 
> > MIMEDefang is an excellent suggestion.
> > 
> >> Only thing is I think you'll have to let the domains that should never
> >> receive email get email for your MTA so the milter "sees" the email.
> > 
> > Setting up MX records will certainly make it easier for the spammers
> > to spew their crap to your systems, but in my experience their
> > spamware seems to fall back to the "A" and "" records in the
> > absence of an MX records (and sometimes in addition to the presence
> > of an MX record when any or all of the defined MXes rejects their
> > attempts with 4yz {temporary} or 5yz {permanent} SMTP error codes).
> 
> But, in reality not really worth the trouble.. domains are easy to 
> forge, and innocent companies maybe trying to verify the address, 
> because a bad guy used it in a contact form..

Not when SPF/DKIM/DMARC are configured properly.  Unfortunately, you 
are generally correct because many domains that are actively used for 
legitimate eMail don't employ SPF/DKIM/DMARC to prevent forgeries. :(

(I'm holding off until February 2024 to re-consider rejecting or 
tagging eMail from domains without SPF/DKIM/DMARC configured.  At 
this point we're still seeing plenty of legitimate eMail coming from 
such systems to the point that even system-wide tagging with 
SpamAssassin will be problematic for many of our users.)

> Not to mention, how does that stop Gmail or o365 spammers from targeting 
> your traps.. we auto blockling gmail now? (oh, yeah it might be time 
> soon, but not yet)

I'm seeing significantly more spam emanating from Microsoft's 
netblocks than from Google's (although Google's GMail users certainly 
don't have clean hands either).  At least Google seems to be more 
willing to terminate spammer accounts than Microsoft does.  YMMV.

-- 
Postmaster - postmas...@inter-corporate.com
Randolf Richardson, CNA - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
https://www.inter-corporate.com/


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

Re: [mailop] seeking a spamtrap milter

[Peter N. M. Hansteen via mailop]

This thread had me think for long enought that I thought it might be useful to
do a short (for me at least) writeup - 

A Simpler Life: Trapping Spambots Based on Target Domain Only 
https://nxdomain.no/~peter/domain-only-trapping.html 
(or tracked 
https://bsdly.blogspot.com/2024/01/a-simpler-life-trapping-spambots-based.html) 

Thanks again to Michael for having me ponder this.

All the best,
Peter

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] seeking a spamtrap milter

[Grant Taylor via mailop]

On 1/23/24 1:40 PM, Michael W. Lucas via mailop wrote:

Hi folks,


Hi,

I have domains that should never receive mail. I'd like a milter that 
looks for mail to those domains and feeds the IP of the sender to an 
outside program.


I'm interpreting your statement to mean that you are talking about email 
inbound to local domains that you own / manage / etc. and not outbound 
to remote domains that you want to never send to.


I'm not sure if you need this to happen during the SMTP transaction, 
milters playground, or just want a near real time processing where a 
short (O(seconds)) delay would be okay.


If a short delay is okay, I would wonder if standard SYSLOG might 
suffice.  I assume that your MTA logs enough data that you could get a 
list of IPs that send to -- what I'm going to call -- protected 
recipient domains.  I'm going to further assume that you could tune your 
SYSLOG implementation to send just the facility and level that have the 
interesting log files to a program for parsing and extracting the IPs 
sending to the protected domains.  I take it for granted that if you the 
IP in a variable that you can feed it where you want to do whatever you 
want.


Surely someone wrote this spamtrap software? Or does everyone just 
parse the log?


"spamtrap" seems like a much broader term than what I think you are 
after.  I have seen many spam trap configurations, but I'm not aware of 
them doing what you are after.




--
Grant. . . .
unix || die
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop