Re: [mailop] Help with handling backscatter

[Jesse Hathaway via mailop]

On Sun, Jul 14, 2024 at 12:49 PM Alessandro Vesely via mailop
 wrote:
> Did ARC seals verify?

We are not verifying arc seals at present, but rspamd seems to have
support, which is
a milter we are currently using, so that is worth investigating, thanks.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Help with handling backscatter

[Jesse Hathaway via mailop]

On Fri, Jul 12, 2024 at 7:59 PM Grant Taylor via mailop
 wrote:
> It's not BATV but it does help filter bogus use of the Null Reverse
> Path.  Maybe this will help some.
>
> Link - SirWumpus/milter-null: Filter legitimate DSN and MDN messages
> from those generated as a result of spam backscatter.
>   - https://github.com/SirWumpus/milter-null
>
> I implemented milter-null within the last month on five Postfix systems.
>   It's helped stop enough bogus DSNs / MDNs to make it worth my time to
> do so.
>
> And Anthony cleaned up his old code and uploaded it per my request.  I'd
> consider that still supported, or at least not abandoned.

Thanks Grant, milter-null looks like a very interesting alternative to BATV
as it would sidestep any BATV interoperability issues.

> Aside:  I've had EXTREMELY good luck with Snert milters over the last
> two decades.  Their milter for ClamAV and SpamAssassin are my preferred
> milters because of the various options that can be put into
> /etc/mail/access(.db) to alter how the milter behaves for specific
> senders and / or recipients.

Good to know, I'll definitely take a look at their other milters.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Help with handling backscatter

[Jesse Hathaway via mailop]

On Fri, Jul 12, 2024 at 4:14 PM Slavko via mailop  wrote:
> I didn't notice which MTA you are using. Exim has tools for BATV
> signing and verification, i don't know how others.

Coincidentally, we just migrated from Exim to Postfix, so I think a
separate milter
is my only option at present.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Help with handling backscatter

[Alessandro Vesely via mailop]

Il 11/07/24 23:23, Slavko via mailop ha scritto:

Dňa 11. júla 2024 20:01:17 UTC používateľ Jesse Hathaway via mailop 
 napísal:


1.  Why are the non-delivery notifications sent to
 rather than to ?


NDR have to be send to Return-Path of original message, thus it depends
what was in its MAIL FROM. IMO including foreign (google) IP range opens
big hole in SPF.



The bounced message had:

Return-Path: 
To: 

Neither of those seem to have anything to do with the Received: from 
shopify.com line and with the diagnostic (which mentions 
ebuerg...@sbcglobal.net).  I doubt the From: 
_𝐀𝐟𝐟𝐨𝐫𝐝𝐚𝐛𝐥𝐞_𝐖𝐢𝐧𝐝𝐨𝐰𝐬_ (in MATHEMATICAL BOLD) is real, 
and the Subject: doesn't seem to match the content of the message.


Did ARC seals verify?

Best
Ale
--





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

Re: [mailop] Help with handling backscatter

[Grant Taylor via mailop]

On 7/12/24 14:57, Jesse Hathaway via mailop wrote:
I had not yet considered it. It looks like there is a milter available, 
but it is unmaintained. I would be a little wary of setting it up, 
given the lack of maintenance.


:-/


Are there other opensource BATV milters?


It's not BATV but it does help filter bogus use of the Null Reverse 
Path.  Maybe this will help some.


Link - SirWumpus/milter-null: Filter legitimate DSN and MDN messages 
from those generated as a result of spam backscatter.

 - https://github.com/SirWumpus/milter-null

I implemented milter-null within the last month on five Postfix systems. 
 It's helped stop enough bogus DSNs / MDNs to make it worth my time to 
do so.


And Anthony cleaned up his old code and uploaded it per my request.  I'd 
consider that still supported, or at least not abandoned.


Aside:  I've had EXTREMELY good luck with Snert milters over the last 
two decades.  Their milter for ClamAV and SpamAssassin are my preferred 
milters because of the various options that can be put into 
/etc/mail/access(.db) to alter how the milter behaves for specific 
senders and / or recipients.




--
Grant. . . .


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

Re: [mailop] Help with handling backscatter

[Slavko via mailop]

Dňa 12. júla 2024 20:45:30 UTC používateľ Jesse Hathaway via mailop 
 napísal:

>BATV seems like the best solution, but as said in my rely to Mark Alley,
>I am a little wary of standing it up, given the lack of maintained open
>source milters.

I didn't notice which MTA you are using. Exim has tools for BATV
signing and verification, i don't know how others.

regards


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

Re: [mailop] Help with handling backscatter

[Jesse Hathaway via mailop]

On Thu, Jul 11, 2024 at 4:33 PM Slavko via mailop 
wrote:

> Do you see in bounces from what IP was original send?

No, not that I can find

> The BATV was inventend to solve that problem, you sign own Return-Path
> and then check this signature in bounces and reject when bounce (NDR)
> is send  to unsigned RCPT as bounce to message not send by you.. But
> it was never standardised and is not always applicable (i use it).
>
> If you decide to apply it, do it in two stages, first start to sign
> Return-Path and then, after some days, start rejecting (to allow to
> receive bounces for yet unsigned messages). You can temporary reject
> unsigned bounces in between, but if you are under attack, it will do
> more harm than help.

BATV seems like the best solution, but as said in my rely to Mark Alley,
I am a little wary of standing it up, given the lack of maintained open
source milters.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Help with handling backscatter

[Jesse Hathaway via mailop]

On Thu, Jul 11, 2024 at 4:17 PM Michael Peddemors via mailop
 wrote:
> Can you add a little more details to be sure? Are you using Google
> services at all?

Employees of the Wikimedia Foundation have Google Workspace accounts, our MX
servers for wikimedia.org relay employee mail to Google's servers. Also, as a
consequence, google's servers are part of the wikimedia.org SPF record.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Help with handling backscatter

[Jesse Hathaway via mailop]

On Thu, Jul 11, 2024 at 3:45 PM Mark Alley via mailop
 wrote:

> Is BATV an option for you?

I had not yet considered it. It looks like there is a milter available,
, but it is
unmaintained. I would be a little wary of setting it up, given the lack
of maintenance. Are there other opensource BATV milters?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Help with handling backscatter

[Slavko via mailop]

Dňa 11. júla 2024 20:01:17 UTC používateľ Jesse Hathaway via mailop 
 napísal:

>1.  Why are the non-delivery notifications sent to
> rather than to ?

NDR have to be send to Return-Path of original message, thus it depends
what was in its MAIL FROM. IMO including foreign (google) IP range opens
big hole in SPF.

Do you see in bounces from what IP was original send?

>2.  Does the backscatter email show evidence of miss configuration on my
>side?

Backscatter is fault of NDR's sending MTA/MSA, which doesn't properly verifies
Return-Path or accepts mails and then fails to delivery it (instead of rejecting
at SMTP time). You didn't reveal sending host, but if it is not your host, it 
is not
your mistake. You are just victim.

>3.  What mitigations do folks recommend to drop these types of messages?

As i see, SPF nor DMARC is helping you, and they will not help, if remote
MTA doesn't reject on that base.

There are public RBLs which contains backscatter MTA, i don't use any,
thus i cannot comment their quality.

The BATV was inventend to solve that problem, you sign own Return-Path
and then check this signature in bounces and reject when bounce (NDR)
is send  to unsigned RCPT as bounce to message not send by you.. But it
was never standardised and is not always applicable (i use it).

If you decide to apply it, do it in two stages, first start to sign Return-Path
and then, after some days, start rejecting (to allow to receive bounces
for yet unsigned messages). You can temporary reject unsigned bounces
in between, but if you are under attack, it will do more harm than help.

Don't afraid to apply ratelimit for bounces by recipient address.

regards

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

Re: [mailop] Help with handling backscatter

[Michael Peddemors via mailop]

There are SO many things wrong with this don't know even where to start..

Received: from shopify.com ([89.190.156.188])
Duplicate Return-Path
X-Original-Message-ID: 
<668ef133.170a0220.9c6db.ca0esmtpin_added_bro...@mx.google.com>


(google.com: domain abaimiddle.school.test-google-a.com configured 
89.190.156.188 as internal address)


But in the end, this appears to obviously be a Google problem..

But easy to see why you are confused. Typically, any service that 
generates backscatter would quickly find itself on a spam RBL. But when 
the 'Too Big to Block' do it.. it's frustrating.


But I don't know if this is technically traditional 'backscatter' issue.

IF it is passed off to Google to handle the email delivery, and SBC 
correctly rejects it during the SMTP phase with a user does not exist, 
this is more like internal Google blowback. (Still as it isn't returning 
it to the original sender, it is backscatter)  We have seen other cases 
of backscatter from them.


Can you add a little more details to be sure? Are you using Google 
services at all?


wikimedia.org descriptive text "v=spf1 include:_cidrs.wikimedia.org 
include:_spf.google.com ip4:74.121.51.111 ~all"




On 2024-07-11 13:01, Jesse Hathaway via mailop wrote:

We received a thousand or so of the attached backscatter emails this
morning, each one to a different recipient, but with the same
return-path, . I don't have much experience dealing
with backscatter, so I was hoping for some guidance from this list.

Questions:

1.  Why are the non-delivery notifications sent to
  rather than to ?
2.  Does the backscatter email show evidence of miss configuration on my
 side? I don't believe so, but we did recently stand up some new
 postfix servers, whereas our existing servers run exim.
3.  What mitigations do folks recommend to drop these types of messages?

Thanks, Jesse


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



--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Reg. TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

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

Re: [mailop] Help with handling backscatter

[Mark Alley via mailop]

On 7/11/2024 3:01 PM, Jesse Hathaway via mailop wrote:

We received a thousand or so of the attached backscatter emails this
morning, each one to a different recipient, but with the same
return-path,. I don't have much experience dealing
with backscatter, so I was hoping for some guidance from this list.

Questions:

1.  Why are the non-delivery notifications sent to
   rather than to?
2.  Does the backscatter email show evidence of miss configuration on my
 side? I don't believe so, but we did recently stand up some new
 postfix servers, whereas our existing servers run exim.
3.  What mitigations do folks recommend to drop these types of messages?

Thanks, Jesse


Is BATV an option for you?

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

[mailop] Help with handling backscatter

[Jesse Hathaway via mailop]

We received a thousand or so of the attached backscatter emails this
morning, each one to a different recipient, but with the same
return-path, . I don't have much experience dealing
with backscatter, so I was hoping for some guidance from this list.

Questions:

1.  Why are the non-delivery notifications sent to
 rather than to ?
2.  Does the backscatter email show evidence of miss configuration on my
side? I don't believe so, but we did recently stand up some new
postfix servers, whereas our existing servers run exim.
3.  What mitigations do folks recommend to drop these types of messages?

Thanks, Jesse
--- Begin Message ---

** Address not found **

Your message wasn't delivered to ebuergler@sbcglobal​.net because the address 
couldn't be found, or is unable to receive mail.



The response from the remote server was:
550 5.2.1 ... Addressee unknown, relay=[108.177.16.9]
Reporting-MTA: dns; googlemail.com
Received-From-MTA: dns; wiki@wikimedia.org
Arrival-Date: Wed, 10 Jul 2024 13:38:11 -0700 (PDT)
X-Original-Message-ID: <668ef133.170a0220.9c6db.ca0eSMTPIN_ADDED_BROKEN@mx.google.com>

Final-Recipient: rfc822; ebuergler@sbcglobal.net
Action: failed
Status: 5.2.1
Remote-MTA: dns; ff-ip4-mx-vip2.prodigy.net. (144.160.159.22, the server for
 the domain sbcglobal.net.)
Diagnostic-Code: smtp; 550 5.2.1 ... Addressee unknown, relay=[108.177.16.9]
Last-Attempt-Date: Thu, 11 Jul 2024 08:46:42 -0700 (PDT)
--- Begin Message ---
Hi KOSUDL,

Thanks for adding an email to your Wikipedia account, registered from IP 
address 41.140.152.187.

Please click on the link below to confirm this as the email address you'd like 
to link to your account "KOSUDL":

https://en.wikipedia.org/wiki/Special:ConfirmEmail/37dc24cda5d650e817bfa8217414481c

Note: this confirmation code expires at 20:15, 17 July 2024.

Thanks,

Wikipedia



To cancel the email address confirmation (because you did not register the 
account or for any other reason), click on this cancellation link:

https://en.wikipedia.org/wiki/Special:InvalidateEmail/37dc24cda5d650e817bfa8217414481c--- End Message ---
--- End Message ---
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop