Re: [mailop] script to collect SPF addresses by domain?

[Peter Nicolai Mathias Hansteen via mailop]

> On 30 Oct 2023, at 20:01, Michael W. Lucas via mailop  
> wrote:
> 
> Hi,
> 
> Trying to not reinvent the wheel here.
> 
> I want to create an allow list of the big providers that retry from
> multiple IP addresses. (Spam from them won't be caught by
> protocol-level checks like postscreen, it needs rspamd or somesuch).
> 
> It seems that someone surely would have created a "grab the SPF
> records and create a list" script, recursing the included
> records. Search engines are not useful to find it, though.
> 
> Any pointers?

I wrote a piece some years back about just that. 

Assuming you are running on OpenBSD or other system that has a recent-ish 
OpenSMTPD, you could use OpenSMTPD's "smtpctl spf walk", much like the script 
described in https://nxdomain.no/~peter/goodness_enumerated_by_robots.html (or 
if you tolerate big G's trackers in exchange for incrementally nicer 
formatting, 
https://bsdly.blogspot.com/2018/11/goodness-enumerated-by-robots-or.html).

Anyway, that script and the data it generates when I run it at quasi-random 
intervals is what I use for the scenario you describe.

All the best,
Peter



-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://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

[mailop] Contact info for antispamcloud.com ?

[Peter Nicolai Mathias Hansteen via mailop]

Hi,

Does anyone here have usable contact info for the domain antispamcloud.com 
?

Something there is apparently trying to contact postmaster@ in one of our 
domains, but since they have no valid MX record and their actual outbound SMTP 
senders do not match their SPF, so even the coddling described in 
https://bsdly.blogspot.com/2018/11/goodness-enumerated-by-robots-or.html is no 
use.

- Peter

--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://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.






signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] abuse@ equivalent for yahoo dot com?

[Peter Nicolai Mathias Hansteen via mailop]

Hi,

My attempt at reaching the conventional abuse contact for yahoo dot com bounced 
as undeliverable, apparently what they rewrote to on incoming does not in fact 
exist:

Sorry, we were unable to deliver your message to the following address.

:
550: 5.1.1 User Unknown

Fwiw, the report I sent was

Date: Fri, 30 Sep 2022 18:50:46 +0200
From: Peter Nicolai Mathias Hansteen 
To: ab...@yahoo.com
Subject: New samples of spam sent by your customers
X-Mailer: Apple Mail (2.3696.120.41.1.1)
New messages have been added to the archive at  
https://www.bsdly.net/~peter/yahoo-abuse/

The messages are saved in that directory as 
MMDD_user@origin.tld_u...@target.tld.txt, please check the collection for 
further data.

Please check this URL regularly; it is likely that further updates will occur 
in-between these alert messages.

Yours,
Peter N. M. Hansteen


—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://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.

—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://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.






signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Peter Nicolai Mathias Hansteen via mailop]

> 15. apr. 2022 kl. 16:24 skrev Al Iverson via mailop :
> 
> PPS- Don't send to Gmail over IPv6.

I would rather say «don’t try to send to gmail over IPv6 unless you have a 
correct reverse DNS for your IPv6 address». Google apparently decided to raise 
the bar a little when it comes to receiving over IPv6.

I just sent as a test the message preserved at 
https://www.bsdly.net/~peter/somebody_mentioned_ipv6.eml.txt 
 which was 
delivered over IPv6, as the headers will show, so it’s definitely possible.

I have however at times seen people with gmail accounts either not getting 
messages from my domains at all or only finding them in the spam folder, when 
my logs record the messages as accepted by the Google servers.

I would most certainly have preferred some sort of error message, but that 
appears not to be Google’s way of doing things.

The domain’s reputation in Google’s view may have been tainted by their 
classifying some automatically generated mail *about* spam activity as spam. I 
was originally somewhat reluctant to mention those episodes, but for those 
bored witless and curious the bounces are archived at 
https://home.nuug.no/~peter/googlefail/ 
. It’s even possible that some of the 
items at the first link in my signature has more information in a field notes 
type of style.

- Peter

—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://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.






signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Best email server for home use...

[Peter Nicolai Mathias Hansteen via mailop]

> 23. feb. 2022 kl. 14:10 skrev Sinclair, John via mailop :
> 
> Staring at the end of the Google Suite (aka Workspace) free lunch days.  
> Trying to find a free solution that will still let me use a custom domain, 
> not coming up with much, so thinking about going back to rolling and hosting 
> my own email server for the family.  What’s the best of breed these days for 
> small/micro servers hosting five-ish email accounts, probably no more than 
> 1TB total – looking for as-close-to-gmail-as-possible webmail, IMAP access 
> for mobile, might even throw a nextcloud/freenas type of environment on for 
> file storage/sharing.  Not interested in hosting my own IMAP and using a free 
> gmail account as a client – looking to only have the family have to keep one 
> username (on the custom domain) and basically cut out Google entirely.  I 
> have the hardware and the bandwidth, it’s more of a what OS/email/webmail is 
> best of breed these days, not only for robustness/security, but also 
> something that can have at least some attempt at blocking most of the spam…

If you have a reasonable insight into unix things, you could do worse than 
going with OpenBSD and an OpenSMTPD setup along the lines of what Aaron 
Poffenberger describes in his tutorial here: 
https://vdocuments.site/opensmtpd-for-the-real-world-mail-server-tutorial-introductionabackground.html
 

 (originally a BSDCan session I believe).

I’ve been running similar setups for years (but with exim as the MTA mainly for 
inertia reasons), documented mainly in articles you can find via the first link 
in my signature. The most comprehensive is perhaps 
https://bsdly.blogspot.com/2014/02/effective-spam-and-malware.html 
, others 
will be tagged with keywords like spam, mail, spamd, smtp and so forth.

All the best,
Peter


—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://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.






signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Working contact info for abuse at godaddy dot com ?

[Peter Nicolai Mathias Hansteen via mailop]

I just got a bounce for a message sent to the abuse address godaddy.com 
supplies in their whois info, where the meat of the message was

"ab...@godaddy.com
There's a problem with the recipient's mailbox. Please try resending the 
message. If the problem continues, please contact your email admin.»

It appears that their mail is actually at least partly hosted by Microsoft.

But anyway, I would appreciate any hints on how to reach a relevant human in 
that organization offlist.

All the best,
Peter N. M. Hansteen

—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://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.






signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] How to detect fraud login in POP IMAP or SMTP?

[Peter Nicolai Mathias Hansteen via mailop]

This discussion made me think of one of the several bizarre episodes involving 
my spamtraps apparently becoming part of the must-try user IDs for other 
services - 
https://bsdly.blogspot.com/2014/08/password-gropers-take-spamtrap-bait.html 
 
which lead eventually to me publishing the list of IP addresses that have tried 
and failed to access pop3 here.

A slightly newer piece gives an overview of the various lists we generate for 
free consumption: 
https://bsdly.blogspot.com/2018/08/badness-enumerated-by-robots.html 
.

The data presented is all free to use. If you repackage, please include some 
sort of indicator of where the data came from; if you find any errors or 
unreasonable inclusions, please let me know.

All the best,
Peter


—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://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.






signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Anyone here from SiteGround or .mailspamprotection.com?

[Peter Nicolai Mathias Hansteen via mailop]

> 20. sep. 2021 kl. 23:10 skrev Jaroslaw Rafa via mailop :
> 
> Dnia 20.09.2021 o godz. 19:40:24 Peter N. M. Hansteen via mailop pisze:
>> 
>> if you do reach a human there, could you do us all a favor and ask
>> them whether they still believe in the tooth
>> fairy^H^H^H^H^H^H^H^H^H^H^H^HSMTP callbacks and show them 
>> https://bsdly.blogspot.com/2017/08/twenty-plus-years-on-smtp-callbacks-are.html?
> 
> I think you're wrong claiming in that article that SMTP callbacks are "only
> verifying in a very limited sense that the domain's mail exchanger was
> indeed equipped with a functional SMTP service." They verify much more than
> that, they verify whether the target address actually exists.

I am quite aware of what the intention behind the proposed mechanism was.

However, the concept never went beyond the experimental stage, never reached 
anything near critical mass adoption and has now been deprecated for decades.

Besides, what we are seeing does not at all match the behavior you describe. 
The requests are consistently for some generated string that is pretty much 
guaranteed not to be a deliverable address.

The most generous interpretation I an offer of what I see is that the other end 
is trying to use a mechanism that essentially nobody else has enabled and that 
they do not actually understand the mechanism they are attempting to use.

And anyway the number of sites that attempt this is low enough that the volume 
never really rises above the level of background noise. I’m just not that happy 
with noise in any system.

- Peter

—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://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.






signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Hotmail spam (again)

[Peter Nicolai Mathias Hansteen via mailop]

> 15. aug. 2021 kl. 14:05 skrev Markus E. via mailop :
> 
> Hi all,
> 
> How do you guys combat Hotmail spam? Like:
> 
> 
> Received: from APC01-SG2-obe.outbound.protection.outlook.com 
> (mail-oln040092253066.outbound.protection.outlook.com [40.92.253.66])
> ...
> Received: from PSAPR06MB4488.apcprd06.prod.outlook.com 
> ([fe80::9988:fc0e:d162:608]) by PSAPR06MB4488.apcprd06.prod.outlook.com 
> ([fe80::9988:fc0e:d162:608%4]) with mapi id 15.20.4415.022; Sun, 15 Aug 2021 
> 11:32:01 +
> ...
> From: "smeta...@hotmail.com" 
> ...
> To: Undisclosed recipients:;
> ...
> Received: from [192.168.2.2] (62.113.21.160) by 
> VI1PR0701CA0068.eurprd07.prod.outlook.com (2603:10a6:800:5f::30) with 
> Microsoft SMTP Server (version=TLS1_0, 
> cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA) id 15.20.4436.9 via Frontend 
> Transport; Sun, 15 Aug 2021 11:32:00 +
> ...
> 
> 
> I'm so tired of this. Is there a known IP address range used only by the 
> Hotmail service?

My impression at least is that valid mail from hotmail.com 
 and other Microsoft attached domains can come from 
essentially anywhere in Microsoft’s IP address ranges.

Also, in my experience, sending any offending messages with full headers intact 
to j...@office365.microsoft.com  (more 
likely than not the offenders are in fact Office 365 customer) and abuse@ 
whichever was the sending domain is as close to a useful thing to do with those.

How I found out: 
https://bsdly.blogspot.com/2018/02/a-life-lesson-in-mishandling-smtp.html 
 and 
links therein.

All the best,
Peter


—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://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.






signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Duplicated DMARC reports from Google and Yahoo

[Peter Nicolai Mathias Hansteen via mailop]

> 5. aug. 2021 kl. 12:41 skrev Jaroslaw Rafa via mailop :
> 
> Could anybody explain why are these reports sent multiple times? This never
> happened with regular mail I receive from either Google or Yahoo.

I see exactly the same as you described.

However since both firms you mention rarely if ever respond directly to 
queries, I have always sort of shrugged this phenomenon off with thinking it’s 
likely that their sending setup for those reports has not been told about 
greylisting, or for that matter, queueing.

Then again, if the source address we see is among the ones the sender domains 
publish as allowed senders in their SPF records, greylisting here should not be 
a factor (the setup we use is described after a somewhat wordy preamble in 
https://bsdly.blogspot.com/2018/11/goodness-enumerated-by-robots-or.html 
).

All the best,
Peter


—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://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.






signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Online.no (Telenor) deferred SMTP message

[Peter Nicolai Mathias Hansteen via mailop]

> 19. jul. 2021 kl. 15:12 skrev Victor Roemgens via mailop :
> 
> Hi all,
> 
> We see below Online.no deferred SMTP message. Anyone know what this means?
> 
> to=mailto:x...@online.no>>, relay=mx.online.no 
> [193.213.115.10]:25, delay=406, delays=406/0/0.08/0, 
> dsn=4.7.0, status=deferred (host mx.online.no 
> [193.213.115.10] refused to talk to me: 421 4.7.0 Not 
> allowed.)
> 
> Hope to hear from you or Online.no representative.


I am not familiar with the internals of the online.no  
setup, but I don’t think I’ve ever had any major issues delivering to them.

There are several possibilities, but my hunch is that you could be seeing a 
variant of greylisting (although the choice of status codes here seems a little 
odd). Anyway, if it *is* greylisting, retries within a reasonable time will 
succeed and the problem will resolve itself that way.

It would have been useful to know the sending IP address here, if nothing else 
to check for blocklist entires or similar.


—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://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.






signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Greylisting never passing on retry

[Peter Nicolai Mathias Hansteen via mailop]

> 21. apr. 2021 kl. 21:34 skrev John Levine via mailop :
> 
> It appears that Peter Nicolai Mathias Hansteen via mailop  
> said:
>> Greylisting implementations tend to expect retries to come from the same IP 
>> address as the original one. Some of us are still quite cross that
>> the writers-of-RFCs did not care to make that a MUST requirement (see [1] 
>> for my grumble on that from a while back).
> 
> SMTP was defined in the late 1970s and we didn't invent greylisting
> until about 2003. I don't think you can blame them for not being
> clairvoyant.

No clairvoyance was required for taking account of greylisting in the 2008 
update that the article was about, but you’re probably right in a largish chunk 
of cases about this bit:

> I find that fuzzing the IP addresses to anything in the same ipv4 /24
> or ipv6 /64 handles most of the different IP retries without letting
> any more spam through.

Cheers,
Peter

—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://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.






signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Greylisting never passing on retry

[Peter Nicolai Mathias Hansteen via mailop]

> 21. apr. 2021 kl. 12:23 skrev Neil Youngman via mailop :
>> 
> 
> It doesn't behave exactly like a normal mail server, but it does retry
> more than five times. Not all retries are from the same IP, but I have
> observed that retries from the same IP don't get delivered.

That may be the exact source of the problem.

Greylisting implementations tend to expect retries to come from the same IP 
address as the original one. Some of us are still quite cross that the 
writers-of-RFCs did not care to make that a MUST requirement (see [1] for my 
grumble on that from a while back).

If you can’t guarantee that, please consider letting the retries run for a 
reasonable amount of time, at least a few days.

Some of us have bent over backwards to compensate for those failures by 
introducing mechanisms to whitelist hosts that appear in known sites’ SPF 
records and a few other tricks (see [2]].

[1] 
https://bsdly.blogspot.com/2008/10/ietf-failed-to-account-for-greylisting.html 

[2] https://bsdly.blogspot.com/2018/11/goodness-enumerated-by-robots-or.html 


All the best,
Peter

—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://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.






signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Chuckle of the day..

[Peter Nicolai Mathias Hansteen via mailop]

> 17. mar. 2021 kl. 23:46 skrev Michael Peddemors via mailop 
> :
> 
> Never get enough chance to look at logs anymore but this one jumped out while 
> checking something out..
> 
> 89.248.169.12 -> 587 GeoIP = [GB] PTR = security.criminalip.com
> 
> hehehe.. wonder if we should help them fix their broken bot..

I thought there were more, but at least we have

$ doas spamdb | grep 89.248.169
TRAPPED|89.248.169.12|1616119406

$ grep 89.248.169 pop3gropers.txt
   89.248.169.12
   89.248.169.16
   89.248.169.36

It’s more than likely they have more than one netback though, since that whois 
output (snipped here for brevity) seems very familiar. ENOCOFFEE means no 
further checks from here at the moment, but yes, they are worthy of LARTing.

- Peter

—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://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.






signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Abuse contact info?

[Peter Nicolai Mathias Hansteen via mailop]

> 4. mar. 2021 kl. 22:01 skrev Eric Tykwinski via mailop :
> 
> Looking for abuse contact information for Microsoft Office 365..
> A common customer of ours had a phishing attempt made from what looks like 
> another Office365 client with a domain spelling.

The best I can offer is based on an episode a couple of years ago[1]: If it 
looks to be from an Office365 customer, send your complaint with any background 
material to j...@office365.microsoft.com . 
It likely does not hurt to put abuse@ other Microsoft-attached domains that 
appear to be involved on Cc:.

There are indications that at least a significant subset of messages sent there 
eventually reach a human.

All the best,
Peter N. M. Hansteen

[1] https://bsdly.blogspot.com/2018/02/a-life-lesson-in-mishandling-smtp.html


—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://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.






signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SPF prevents enabling IPv4+IPv6?

[Peter Nicolai Mathias Hansteen via mailop]

I keep thinking that the world has changed a lot since SPF and friends were 
thought up, and faster than anybody anticipated at the time.

Back in the day it would not be unreasonable to assume that most domains would 
designate a small number of specific hosts as valid senders.

Today, in contrast, you more often than not have SPF records with multiple 
includes. I have seen cases (Microsoft.com comes to mind, but they’re not the 
only one) where tens of *subnets* are designated as expected SMTP sources.

If you have access to an OpenBSD system or something else with OpenSMTPd, you 
can  play around much like I did for the research for this article 
https://bsdly.blogspot.com/2018/11/goodness-enumerated-by-robots-or.html 
 — 
and I just checked a few domains, some come in with more than 100 subnets, and 
some of those subnets are IPv6 /36s (I kid you not).

Retrieving the full SPF info in those cases could eat up significant parts of 
your timeouts, and if you happen to need to work around firewall admins of the 
‘DNS is strictly UDP’ school, you will not get complete results anyway.

All the best,
Peter

—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://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.






signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] When RBLs go bad

[Peter Nicolai Mathias Hansteen via mailop]

> 14. feb. 2021 kl. 22:41 skrev John Covici via mailop :
> 
> Its 70.109.53.110 .

Nothing in the bsdly.net  block from tables, but in the 
meantime I reproduced the problem from a machine in a Norwegian academic 
network netblock.

It could be a routing problem or similar at the hosting (terrahost.no) where 
bsdly.net  lives. Or a rogue blacklist ;)

All the best,
Peter


—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://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.






signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] When RBLs go bad

[Peter Nicolai Mathias Hansteen via mailop]

> 14. feb. 2021 kl. 21:58 skrev John Covici via mailop :
> 
> It seems that bsdly.net is not working. I cannot ping or connect to
> the website mentioned.

That is a odd, and perhaps a cause of concern.

If you give me the IP address you would have come from (or range) I can check 
things at this end.

All the best,
Peter

—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://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.






signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] When RBLs go bad

[Peter Nicolai Mathias Hansteen via mailop]

Just to add to the datapoints of services ‘gone bad’ — I suspect the story 
behind several of these episodes is that whoever actually knew how their 
systems worked left the organization, and whoever is left to take over is not 
actually up to the task, and bad things happen.

I’m fairly convinced that was what happened in this case from a few years back 
https://bsdly.blogspot.com/2017/08/twenty-plus-years-on-smtp-callbacks-are.html 
.
 It is anyway fairly clear that whoever did great labour in an effort to avoid 
actually answering questions did not have a clue how any of this actually works.

Another frequent problem is that the list maintainers are not too transparent 
about the actual mechanisms of getting on or off the lists.

I would advise that any listing service that does not clearly document 
inclusion criteria should not be trusted.

I slant in the direction that inclusion criteria should be as simple as 
possible, but even complex ones should be documented to whatever detail 
feasible and available to the general public.

Just as a random example, here is my inclusion criteria document — short and 
sweet — for my known spam sources list: 
https://www.bsdly.net/~peter/traplist_ethics.shtml 
. In addition, my system 
generates a few other blacklists, summarized in this blog post: 
https://bsdly.blogspot.com/2018/08/badness-enumerated-by-robots.html 


I hope this is vaguely useful to one or more somebodies out there.

All the best,
Peter

—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://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.






signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail deliverability issues of domain after double sendings

[Peter Nicolai Mathias Hansteen via mailop]

> 28. jan. 2021 kl. 22:46 skrev John Levine via mailop :
> 
> In article <35c39cda-e6a3-4b8e-ba03-e28276f07...@bsdly.net> you write:
>> Interestingly, IIRC last time somebody in my immediate surroundings was bit 
>> by Googgle’s policies on this, it looked like while they
>> are fairly forgiving for IPv4 hosts, they are very much not forgiving of any 
>> errors or deviations as soon as delivery is attempted over
>> IPv6.
> 
> Google has said as much. If you want to send them mail over IPv6 it
> has to have a valid DKIM signature or pass SPF. If you can't do that,
> stick to IPv4.

It’s been a couple of years my memory could be off, but in the case I was 
thinking of I *think* both DKIM and SPF were correct, but for reasons unknown 
the reverse for the IPv6 address used was not.

Under any circumstances it was a learning experience for several of the people 
involved.

All the best,
Peter

—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://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.






signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail deliverability issues of domain after double sendings

[Peter Nicolai Mathias Hansteen via mailop]

> 27. jan. 2021 kl. 12:23 skrev Laura Atkins via mailop :
> 
>> I know it sounds like a chore, but I would start by ensuring that the hosts 
>> involved do meet the minimum standards such as having a valid reverse lookup.
>> 
> This is one of those checkbox things I do recommend, but my experience is 
> that Google is pretty forgiving of technical nits like this. And when they do 
> have problems with how your IP address is configured they outright reject the 
> mail, not accept it and drop it in the bulk folder.

Interestingly, IIRC last time somebody in my immediate surroundings was bit by 
Googgle’s policies on this, it looked like while they are fairly forgiving for 
IPv4 hosts, they are very much not forgiving of any errors or deviations as 
soon as delivery is attempted over IPv6.

There is no easy way to tell from here whether this is a factor here, though.

- Peter

—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://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.






signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [FEEDBACK] Azure Spammer Activity

[Peter Nicolai Mathias Hansteen via mailop]

> 14. jan. 2021 kl. 12:20 skrev Hans-Martin Mosner via mailop 
> :
> 
> Am 09.12.20 um 08:43 schrieb Hans-Martin Mosner via mailop:
>> Today we got a response to our abuse reports requesting that we report these 
>> to j...@office365.microsoft.com - I
>> would've thought that within one corporation, forwarding of abuse tickets 
>> should work somehow.
> 
> Well it looks like reporting to j...@office365.microsoft.com is completely 
> useless. No response, no reaction, no
> reduction in spam.
> 
> Is there a reporting address for azure that is read and acted upon?

I tend to include abuse at the parent domains (hotmail.com 
, outlook.com  and Microsoft.com) as 
cc:. You probably will not get any response other than the automated one from 
«The Outlook team», but the flow has decreased somewhat since I started cc-ing 
those addresses.

- Peter

—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://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.






signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Are there any grown-ups at hotmail.com / outlook.com / microsoft.com?

[Peter Nicolai Mathias Hansteen via mailop]

It appears that since last time I had any contact with the powers that be 
behind Office365 (see 
https://bsdly.blogspot.com/2018/02/a-life-lesson-in-mishandling-smtp.html 
) 
they appear to have abandoned any pretense at having any abuse reporting 
address.

The junk@ address that they supplied back in 2018 for reporting purposes does 
produce auto-replies, as do the abuse@ addresses in the parent domains. 
However, that does not appear to affect the steady stream of, of all things, 
Chinese language spam aimed at a few special-purpose addresses here.

See https://www.bsdly.net/~peter/hotmail-office365/ 
 for recent samples of the 
junk.

The problem with outlook.com  and all other 
Microsoft-attached services is that you can’t usefully blacklist them since a 
largish subset of quite ordinary businesses and individuals use those services 
for legitimate purposes.

So if anybody here has contact info for actual flesh-and-blood adult humans 
that could be persuaded to look into this, I would be most grateful to be 
contacted off-list.

All the best,
Peter N. M. Hansteen

—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://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.






signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Current OSS anti-spam software best practice?

[Peter Nicolai Mathias Hansteen via mailop]

> 16. des. 2020 kl. 09:03 skrev Dr. Christopher Kunz via mailop 
> :
> 
> I'm wondering which software is currently the best practice in OSS (incoming) 
> spam detection and filtering?
> 
> We are still using Spam Assassin on our main setup, but I feel that it's not 
> aggressive enough to cope with current spam patterns, especially with regards 
> to its rather conservative bayesian learning parameters.
> 
> Is it generally being superseded by other OSS solutions, or should I be 
> looking into fine-tuning it? It's a shared cluster, so per-mailbox bayesian 
> learning is an important feature for us.


FWIW, I’ve been quite happy with a setup that has OpenBSD spamd(8) doing 
greylisting and tarpitting based on locally generated and imported greytrapped 
blacklists, feeding on to the actual mail server(s) that do their content and 
header filtering using Spamassassin or what the local admins prefer.

My now probably ripe for refresh writeup can be found at 
https://bsdly.blogspot.com/2014/02/effective-spam-and-malware.html 
 (with 
other field notes to be found nearby)

All the best,
Peter N. M. Hansteen

—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://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.






signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft blocking/spammarking messages

[Peter Nicolai Mathias Hansteen via mailop]

Hi Nate,

I’m not in any way associated with Microsoft, but

> 10. des. 2020 kl. 18:07 skrev Nate Burke via mailop :
> 
> Hello, I was hoping someone from Microsoft could contact me offlist for help 
> getting our server (66.151.17.22) removed from the Microsoft blacklist.  I'm 
> having problems sending to outlook.com/msn.com and others with domains hosted 
> at office365.  I can't find any issues with the server, and I don't appear to 
> be on any other blacklists, but all messages to Microsoft are either getting 
> rejected or sent to the spam folder.  The mailserver has been at this IP for 
> many many years, but these issues just started about 10 days ago.
> 

reading the message you quote,

> Any help would be appreciated.
> 
> Error message;
> 
> <<< 550 5.7.1 Unfortunately, messages from [66.151.17.22] 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. 
> [BN8NAM12FT057.eop-nam12.prod.protection.outlook.com]

it looks to me they’re really telling you to talk to your upstream (Internap if 
I read the whois for 66.151.17.22 correctly.


> The link does not appear to have any way for admins to view/remove the server 
> from the blacklist.

As is par for the course. It is the natural default assumption that the problem 
is caused elsewhere.

FWIW, the last interaction I had with the powers that be at Microsoft over a 
related manner, it took a few days after I had published a blog article 
(https://bsdly.blogspot.com/2018/02/a-life-lesson-in-mishandling-smtp.html 
) 
before any visible reaction from their end.

- Peter

—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://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.






signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Peter Nicolai Mathias Hansteen via mailop]

> 6. des. 2020 kl. 14:12 skrev Hans-Martin Mosner via mailop 
> :
> 
> 
> In addition, manual checks against spam mails from hosts on spam-supporting 
> or indifferent network IP ranges shows that
> spammers provide SPF records for their domains, of course, so properly 
> applied SPF is bound to have a significant
> percentage of false negatives.
> 
> So, there are much more false positives and false negatives than I'm willing 
> to accept. But obviously others have
> different experiences, otherwise they would not publish SPF records and check 
> them on mail reception.
> 
> In your experience, where does SPF really help? What are the use cases that I 
> don't see in my spam-blocker tunnel vision?


In my experience, using SPF fail or otherwise as the only or strongly weighted 
criterion for reject or accept is not a good idea. In my own configs it is one 
of several factors considered mainly (but not exclusively, see the last one 
below) after passing greylisting (which I have found more useful) along with 
Spamassassin’s content and header checks.

A few notes from the field that involve various potential and quite real 
pitfalls with SPF and friends:

https://bsdly.blogspot.com/2016/10/is-spf-simply-too-hard-for-application.html 

 (they trusted SPF so much their application could not handle mail from 
correctly setup domains)

https://bsdly.blogspot.com/2018/02/a-life-lesson-in-mishandling-smtp.html 
 
(they should have known better than to run the checks *there*)

https://bsdly.blogspot.com/2018/11/goodness-enumerated-by-robots-or.html 
 (how 
I implemented sort-of trusting the thing)

Hopefully useful or possibly good for a few laughs.

All the best,
Peter


—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://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.






signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Delivery problem on Microsoft e-mail (code 250 but does not receive)

[Peter Nicolai Mathias Hansteen via mailop]

> 20. okt. 2020 kl. 12:41 skrev Daniele Rossi via mailop :
> 
> Hi,
> 
> we try to send to Microsoft Account and we receive this message:
> 
> Queued mail for delivery -> 250 2.1.5
> The problem is that the mail does not arrive either in spam or in the inbox.
> This happens for most of our ip's.
> 
> 

That should simply not happen, ever.

You could report a temporary problem (as in greylist), otherwise the valid 
options are to reject (bounce) or accept and deliver, optionally with spam 
tagging if checks on headers or content warrant that.

> Can anyone explain this abnormal behavior to me?
> 
Your report is not the first that indicates that the company in question has 
built itself a mail transfer and delivery architecture that is getting far more 
complex than needed (my own 
https://bsdly.blogspot.com/2018/02/a-life-lesson-in-mishandling-smtp.html 
 is 
another example), and they’re not very good at actually communicating with 
people reporting problems.

There is always a chance that there *could* be some seemingly minor issue at 
your end, however, so please check that

* any host involved in delivering mail for your domain(s) has a valid reverse 
record for all IP addresses (IPv4 and IPv6 both), and that

* your name service delivers valid results for such things as SPF, DMARC

The second actually bit me recently — a common BIND misconfiguration will try 
to send too-big-to-fit-in-one-packet answers via UDP with predictable results 
for SPF queries, leading to quasi-random failures claiming SPF failures due to 
timeout now that people actually started using the info in earnest after only 
about 20 years of ignoring. Essentially your named.conf needs somewhere in its 
options block

edns-udp-size 1232;
max-udp-size 1232;

Other implementations will have similar tweakables.

All the best,

—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://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.






signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop