Re: [mailop] "unmaintained" milter (was: Help with handling backscatter)

[ml+mailop--- via mailop]

On Fri, Jul 12, 2024, Jesse Hathaway via mailop wrote:

> I am a little wary of standing it up, given the lack of maintained open
> source milters.

If a program just works, why should it be updated?

-- 
Please don't Cc: me, use only the list for replies, even if the
mailing list software screws up the Reply-To header.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] getting unblocked at outlook?

[incoming-mailop--- via mailop]

On 7/11/24 12:52 PM, Michael W. Lucas via mailop wrote:
> Just started getting these today. Looks like one of my colo neighbors
> behaved badly. No useful info at the suggested link, no contact
> given. Any suggestions on how to get my address unblocked?
>
>
> host
> outlook-com.olc.protection.outlook.com[52.101.68.28] said: 550 5.7.1
> Unfortunately, messages from [23.139.82.3] weren't sent. Please contact
> your Internet service provider since part of their network is on our block
> list (S3150). You can also refer your provider to
> http://mail.live.com/mail/troubleshooting.aspx#errors.
> [DU2PEPF00028D10.eurprd03.prod.outlook.com 2024-07-11T16:43:51.745Z
> 08DC9DEBD6582F32] (in reply to MAIL FROM command)
>
> Thanks,
> ==ml

I've seen those messages before and have used the snds link as mentioned
by others in this thread. I've also used the  Sender Information for
Outlook.com Delivery form.  Often times it took me 2 or more days to get
the issue resolved.

More recently I discovered that *I could log a ticket with my service
provider* and in some cases it would be unblocked in as little as 2
hours.  It doesn't exactly thrill me that my provider sells service to
spammers but they (my provider) are able to get microsoft to unblock me
much quicker than when I deal with microsoft myself.

Natu


___
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

[mailop] Telekom to Yahoo/att

[Jeff Pang via mailop]

Hello list,

I am also using Telekom's email service. But telekom has the issues on 
sending messages to all aol/yahoo/att servers. Here are the bounce 
message.


: host mta7.am0.yahoodns.net[67.195.228.94] said: 421
4.7.0 [TSS04] Messages from 194.25.134.84 temporarily deferred due 
to

unexpected volume or user complaints - 4.16.55.1; see
https://postmaster.yahooinc.com/error-codes (in reply to MAIL FROM 
command)


: host mx-aol.mail.gm0.yahoodns.net[67.195.228.84] said: 
421
4.7.0 [TSS04] Messages from 194.25.134.84 temporarily deferred due 
to

unexpected volume or user complaints - 4.16.55.1; see
https://postmaster.yahooinc.com/error-codes (in reply to MAIL FROM 
command)


: delivery temporarily suspended: connect to
al-ip4-mx-vip2.prodigy.net[144.160.235.144]:25: Connection timed out

: connect to
al-ip4-mx-vip2.prodigy.net[144.160.235.144]:25: Connection timed out


Do you know what's the background? All parties involved are big players, 
and they should not be unable to communicate with each other.


Should I submit the feedback to Telekom or Yahoo/att?

regards.

--
Jeff Pang
jeffp...@aol.com
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Best practices for VPS providers?

[Jeff Pang via mailop]

On 2024-07-13 05:19, Mark E. Jeftovic via mailop wrote:

I'm just wondering what the techniques are for monitoring this.



This is how fastmail does:

VadeSecure uses "fingerprints" to identify messages it thinks are spam. 
A "fingerprint" is any unique string in a message. They commonly include 
URLs, email addresses, telephone numbers and host names/IP addresses of 
sending machines. They can also include sufficiently unique text strings 
within a message. For this reason, VadeSecure may identify messages that 
include spam. So, for instance, if you are writing back to a friend and 
telling them that their account has been compromised, and you included 
the full text of the spam you received, your response still includes the 
"fingerprint," and may be flagged. We recommend contacting your friend 
without the full content of the message.



--
Jeff Pang
jeffp...@aol.com
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Best practices for VPS providers?

[Mark E. Jeftovic via mailop]

I'm just wondering what the techniques are for monitoring this.

The cisco logging is one way to do it.

I'll post more as I come across them


On 2024-07-12 4:56 PM, Jeff Pang via mailop wrote:
Some ISP monitor the outgoing messages for spam detection. For 
example, Cogent, if an IP sends some amount Spams (IIRC 10) they will 
charge the downstream VPS company $20.



On 2024-07-13 03:36, Mark E. Jeftovic via mailop wrote:

On 2024-07-12 2:21 PM, Marco Moock wrote:

Am 12.07.2024 um 10:57:15 Uhr schrieb Mark E Jeftovic via mailop:

Implement a policy that if big amounts of spam are going out you can
immediately block outgoing port 25.
Is there anything commonly used for monitoring the level of outbound 
SMTP? Or are vendors forcing all outbound through an egress server to 
scan everything, or homerolling wireshark, tcpdump, web flo scripts.


You'd need to be able to break down which unit is generating the spam.

- mark

-
Mark E. Jeftovic 
Co-founder & CEO easyDNS Technologies Inc.
+1-(416)-535-8672 ext 225

/"Never expect a thing you do not want,
and never desire a thing you do not expect."
-- Bob Proctor /
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop



--
Mark E. Jeftovic 
Co-founder & CEO easyDNS Technologies Inc.
+1-(416)-535-8672 ext 225

/"Never expect a thing you do not want,
and never desire a thing you do not expect."
-- Bob Proctor /___
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] Best practices for VPS providers?

[Jeff Pang via mailop]

Some ISP monitor the outgoing messages for spam detection. For example, 
Cogent, if an IP sends some amount Spams (IIRC 10) they will charge the 
downstream VPS company $20.



On 2024-07-13 03:36, Mark E. Jeftovic via mailop wrote:

On 2024-07-12 2:21 PM, Marco Moock wrote:

Am 12.07.2024 um 10:57:15 Uhr schrieb Mark E Jeftovic via mailop:

Implement a policy that if big amounts of spam are going out you can
immediately block outgoing port 25.
Is there anything commonly used for monitoring the level of outbound 
SMTP? Or are vendors forcing all outbound through an egress server to 
scan everything, or homerolling wireshark, tcpdump, web flo scripts.


You'd need to be able to break down which unit is generating the spam.

- mark

-
Mark E. Jeftovic 
Co-founder & CEO easyDNS Technologies Inc.
+1-(416)-535-8672 ext 225

/"Never expect a thing you do not want,
and never desire a thing you do not expect."
-- Bob Proctor /
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


--
Jeff Pang
jeffp...@aol.com
___
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] Best practices for VPS providers?

[Marco Moock via mailop]

Am 12.07.2024 um 12:36:10 Uhr schrieb Mark E. Jeftovic:

> On 2024-07-12 2:21 PM, Marco Moock wrote:
> > Am 12.07.2024 um 10:57:15 Uhr schrieb Mark E Jeftovic via mailop:
> >
> > Implement a policy that if big amounts of spam are going out you can
> > immediately block outgoing port 25.  
> Is there anything commonly used for monitoring the level of outbound 
> SMTP? Or are vendors forcing all outbound through an egress server to 
> scan everything, or homerolling wireshark, tcpdump, web flo scripts.
> 
> You'd need to be able to break down which unit is generating the spam.

I think abuse reports will be fine for that.
You can use outgoing logging only for the port 25 (e.g. Cisco ACL
permit  any eq 25 log
permit any any
)
should provide you the logging. Then compare that with the abuse
reports.
I don't know an automatic mechanism, but implementing one should be
possible.

-- 
Gruß
Marco

Send unsolicited bulk mail to 1720780570mu...@cartoonies.org
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Best practices for VPS providers?

[Mark E. Jeftovic via mailop]

On 2024-07-12 2:21 PM, Marco Moock wrote:

Am 12.07.2024 um 10:57:15 Uhr schrieb Mark E Jeftovic via mailop:

Implement a policy that if big amounts of spam are going out you can
immediately block outgoing port 25.
Is there anything commonly used for monitoring the level of outbound 
SMTP? Or are vendors forcing all outbound through an egress server to 
scan everything, or homerolling wireshark, tcpdump, web flo scripts.


You'd need to be able to break down which unit is generating the spam.

- mark

-
Mark E. Jeftovic 
Co-founder & CEO easyDNS Technologies Inc.
+1-(416)-535-8672 ext 225

/"Never expect a thing you do not want,
and never desire a thing you do not expect."
-- Bob Proctor /___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Best practices for VPS providers?

[L. Mark Stone via mailop]

All of the providers with whom we are familiar block TCP Port 25 Outbound by 
default, either entirely, or, except to approved paid relaying 
partner-providers.  If you want to send outbound email directly, there is an 
application/approval process to be followed.

AWS over the past few months has become more strict in granting such approvals 
we have seen, and have recommended customers use AWS SES when they deny opening 
port 25 outbound -- which probably helps explain if only in part why we all are 
seeing more spam from AWS SES.

Hope that helps, 
Mark 

-- 
_ 
L. Mark Stone, Founder 
North America's Leading Zimbra VAR/BSP/Training Partner 
For Companies With Mission-Critical Email Needs

- Original Message -
| From: "Mark E Jeftovic via mailop" 
| To: "mailop" 
| Sent: Friday, July 12, 2024 1:57:15 PM
| Subject: [mailop] Best practices for VPS providers?

| The responsible cloud hosts thread has me wondering about the state of the art
| of best practices for VPS providers
| 
| When someone provisions a VPS there’s a danger that they’ll just spin up and
| blast - if they’re using stolen credit cards, etc you can mitigate and filter
| on that side using fraud detection methods (Stripe radar, etc)
| 
| But let’s say they get a VM provisioned - now what?
| 
| We do RBL checks on our VPS IPs but it takes some time for that to show up
| 
| What about monitoring net flows out of the IP? Are there any modules or 
plugins
| for the hyper vizors - or management panels (Proxmox ) to monitor?
| 
| Are there any third party services?
| 
| Thanks
| 
| - mark
| 
| Sent from my iPhone
| ___
| 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] Best practices for VPS providers?

[Marco Moock via mailop]

Am 12.07.2024 um 10:57:15 Uhr schrieb Mark E Jeftovic via mailop:

> But let’s say they get a VM provisioned - now what?

Block outgoing connections to port 25 by default, tell that the
customers and only enable it for users who intentionally want it.
Implement a policy that if big amounts of spam are going out you can
immediately block outgoing port 25.

Also enable it only to users who want to buy the VPS for some months
and make sure they prepay it. This will almost put off most spammers
because they will have to pay more and just can't rent a machine for
some hours.

-- 
Gruß
Marco

Send unsolicited bulk mail to 1720774635mu...@cartoonies.org
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] safe-mail.net

[Benny Pedersen via mailop]

Bill Cole via mailop skrev den 2024-07-12 16:13:


Any SMTP client which does not fall back to the A record when no MX
records exists is fundamentally broken.


and here its more fun when domain is nullMX it would be fail to failback 
to A/ :)


sendmail -f yourmailaddrhere -bv f...@example.org

back to see more football or tour de france :)

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

[mailop] Best practices for VPS providers?

[Mark E Jeftovic via mailop]

The responsible cloud hosts thread has me wondering about the state of the art 
of best practices for VPS providers 

When someone provisions a VPS there’s a danger that they’ll just spin up and 
blast - if they’re using stolen credit cards, etc you can mitigate and filter 
on that side using fraud detection methods (Stripe radar, etc)

But let’s say they get a VM provisioned - now what?

We do RBL checks on our VPS IPs but it takes some time for that to show up

What about monitoring net flows out of the IP? Are there any modules or plugins 
for the hyper vizors - or management panels (Proxmox ) to monitor?

Are there any third party services?

Thanks 

- mark 

Sent from my iPhone
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Cloud hosts for responsible mail servers?

[John Levine via mailop]

It appears that Alessandro Vesely via mailop  said:
>Stupid as it is, DMARC is the best attempt we have at shifting 
>reputation gathering from IP numbers to domain names.

You misspelled DKIM.

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

Re: [mailop] Cloud hosts for responsible mail servers?

[Alessandro Vesely via mailop]

Il 10/07/24 02:18, Lyndon Nerenberg (VE7TFX/VE6BBM) via mailop ha scritto:

I publish SPF records, but refuse to participate in DKIM or DMARC.
By avoiding the latter two, I don't have to navigate all their
associated stupidity, and my mail goes through just fine.



Stupid as it is, DMARC is the best attempt we have at shifting 
reputation gathering from IP numbers to domain names.


Best
Ale
--



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

Re: [mailop] getting unblocked at outlook?

[Ralf Schenk via mailop]

Dear List,

I have the same problem (reaching @outlook.com and @hotmail.com) for a 
mail-service handcrafted for sending side govermental "German 
Environment Agency's Single-Use Plastics Fund platform" see 
https://www.einwegkunststofffonds.de/en


It's built in an azure tenant of german government running on Microsofts 
own netrange !


My last two mails included the "please escalate this to someone who can 
help me." and:


regarding "missing" standards: The Mail-Service at 51.116.98.43 for 
domain "einwegkunststofffonds.de" is built along the highest standards 
of German "Federal Office for Information Security".


BSI TR-03108 "Secure Email Transport" 
https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr03108/tr03108_node.html


According to public available "assessment" at i.e. 
https://internet.nl/mail/einwegkunststofffonds.de/1184937/#
100% of a very profound scan can be reached and beats qualification of 
Mail-Domain @outlook.com by far. (87%: 
https://internet.nl/mail/outlook.com/1291051/)


This domain and mailservices provides all current standards in 
Mail-Security and even modern standards like DANE TLS using DNSSEC 
based DNS Services that your services "@outlook.com" and 
"@hotmail.com" cannot provide. We offer DMARC and TLS-Reportng etc. etc.


Looking forward to get this IP of your own network range used in Azure 
Location FFM unblocked fast.


inetnum:    51.116.0.0 - 51.116.255.255
org:    ORG-MA42-RIPE
netname:    MICROSOFT
descr:  Microsoft Limited UK
country:    GB
admin-c:    DH5439-RIPE
tech-c: MRPA3-RIPE
status: LEGACY
mnt-by: RIPE-NCC-LEGACY-MNT
mnt-by: MICROSOFT-MAINT
created:    2015-05-21T16:59:44Z
last-modified:  2016-07-25T09:38:58Z
source: RIPE


Bye

Am 12.07.2024 um 05:48 schrieb Michael Rathbun via mailop:

On Thu, 11 Jul 2024 16:42:55 -0400, Bill Cole via mailop
wrote:


As far as I've ever been able to tell, S3150 means "Our Pseudo-AI thinks
you stink!" and the way out is to find the link on that page for senders
with  problems, jump through the hoops, respond to any requests for
info, and eventually get a reply from "Hotmail Sender Support" using the
magic phrase "not eligible for mitigation."  This incantation does not
mean what it seems. It is actually a signal that you have reached the
point where you can get a solution (usually?) by replying with the magic
phrase "PLEASE ESCALATE THIS TO SOMEONE WHO CAN ACTUALLY ASSIST ME"
which may or may not need to be in all caps.

This essentially represents my understanding of the net effect of the systems
being build when I worked there.


This may sound like I'm joking, but I am not.

This is sound reverse-engineering.


   No one has ever claimed
to have an explanation for why a S3150 blockage happens or what exactly
the 'mitigation' consists of.

Not that I have seen.  You might need a GUTS clearance to find out.

mdr

--
Databay AG Logo

*Ralf Schenk
*
fon:+49 2405 40837-0
mail:   r...@databay.de
web:www.databay.de 

Databay AG
Jens-Otto-Krag-Str. 11
52146 Würselen



Sitz/Amtsgericht Aachen • HRB: 8437 • USt-IdNr.: DE 210844202
Vorstand: Ralf Schenk, Dipl.-Ing. Jens Conze, Aresch Yavari, Dipl.-Kfm. 
Philipp Hermanns

Aufsichtsratsvorsitzender: Dr. Jan Scholzen

Datenschutzhinweise für Kunden: Hier nachlesen 

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

Re: [mailop] safe-mail.net

[Mark Delany via mailop]

On 12Jul24, Bill Cole via mailop apparently wrote:
> > Nearly 1/2 a century later, it's still the case that most mail clients 
> > will look for address RRs in the absence of an MX.
> 
> Because failing to do so would be ignoring a requirement of the SMTP 
> specification.

Yes. Everyone knows this.

The main observation, which appears to need spelling out, is that at the time 
it was hoped
that this would be a "transition plan" for an Internet protocol which has 
proved to be a
harbinger for many other "transition plans" that followed.


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

Re: [mailop] safe-mail.net

[Bill Cole via mailop]

On 2024-07-11 at 23:35:05 UTC-0400 (Fri, 12 Jul 2024 03:35:05 +)
Mark Delany via mailop 
is rumored to have said:

Nearly 1/2 a century later, it's still the case that most mail clients 
will look for

address RRs in the absence of an MX.


Because failing to do so would be ignoring a requirement of the SMTP 
specification.


Any SMTP client which does not fall back to the A record when no MX 
records exists is fundamentally broken.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo@toad.social and many *@billmail.scconsult.com 
addresses)

Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop