Re: [mailop] Anyone from Prodigy

[Bill Cole via mailop]

On 2024-05-29 at 02:13:50 UTC-0400 (Wed, 29 May 2024 06:13:50 +)
Mark Dale via mailop 
is rumored to have said:


Is there anyone from Prodigy on the list?

We're seeing mail blocked that is addressed to @sbcglobal.net, 
@att.net


And no response from postmaster[AT]prodigy nor 
abuse_rbl[AT]abuse-att.net


In my most recent experiences with them, I have noticed that the latter 
address gets action, but it will likely take 2 business days.



2024-05-29T06:04:23.831730+00:00 hio postfix/smtp[2868369]: 
069BF41D39: to=, 
relay=ff-ip4-mx-vip1.prodigy.net[144.160.159.21]:25, delay=0.8, 
delays=0/0.01/0.7/0.08, dsn=5.3.0, status=bounced (host 
ff-ip4-mx-vip1.prodigy.net[144.160.159.21] said: 553 5.3.0 flpd573 
DNSBL:RBL 521< REDACTED_IP >_is_blocked.For assistance forward this 
error to abuse_...@abuse-att.net (in reply to MAIL FROM command))


Thanks,
Mark


--
-- - --
   MailmanLists
   Mailman hosting in Australia, Europe, UK, USA
   www.mailmanlists.net
   Tel: +61 .2 7255 9924
-- - --
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop



--
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

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Bill Cole via mailop]

On 2024-05-18 at 17:12:11 UTC-0400 (Sat, 18 May 2024 21:12:11 +)
Gellner, Oliver via mailop 
is rumored to have said:


On 18.05.2024 at 21:02 Dave Crocker via mailop wrote:

[...]
Seems like the right approach is to seek community-wide pressure to 
deprecate it.  First through operational pressure and then with an 
update to the spec.


I‘m with you on the operational pressure to deprecate the length 
attribute, however this requires MTA software that allows you to 
differentiate between DKIM signatures with and without l. Is there any 
other than the mentioned mailauth, which doesn’t seem to have a 
direct MTA integration.


It would be easy enough to write a SpamAssassin rule for this or to make 
such a check part of the local config for MIMEDefang or MailMunge (both 
of which use arbitrary Perl for their local config.) It could even be 
done in a Postfix header_check if you don't ask much subtlety of it.


Changing the existing DKIM specification is probably a big challenge. 
Another approach could be to update the wip BIMI specification with a 
statement that a DMARC pass must be ignored if it is solely based on 
valid DKIM signatures with length attributes. The BIMI specification 
already contains such exceptions, like DMARC quarantine policies that 
must be ignored if they include a pct value of less than 100, so this 
wouldn’t be completely new grounds.


BIMI seems like a very gentle tool for operational pressure.


--
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

Re: [mailop] Does iCloud accept forwards?

[Bill Cole via mailop]

On 2024-05-16 at 23:40:57 UTC-0400 (Thu, 16 May 2024 20:40:57 -0700)
Mark Fletcher via mailop 
is rumored to have said:

Does the above mean that the message we sent was forwarded on from 
siark.com

to an iCloud address?


Yes. That's a SRS address. Invented and deployed to preserve viability 
of forwarding in the face of SPF.



If that's true, the envelope from and the message
from are domains other than groups.io, so why would they associate any
authentication failures to us (and start deferring email from us)?


Incompetence?


Just from the DKIM header?


That's the only obvious source, but you'd have to find out from them. 
Whatever they are doing is wrong.



--
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

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Bill Cole via mailop]

On 2024-05-17 at 14:38:00 UTC-0400 (Fri, 17 May 2024 18:38:00 +)
Gellner, Oliver via mailop 
is rumored to have said:

While it’s not new information that the length attribute of DKIM 
poses a security risk, it’s still worthwhile to draw attention to it 
every once in a while and the usual suspects who keep on using it.


Who uses it?

I'm not seeing it at all in my recent personal "mail worth keeping" 
corpus except for one idiosyncratic case of a sender who always uses it 
with the full message length.



--
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

Re: [mailop] Reason for being listed at Spamhaus CSS and XBL unclear

[Bill Cole via mailop]

On 2024-04-19 at 07:21:47 UTC-0400 (Fri, 19 Apr 2024 12:21:47 +0100)
Sebastian Arcus via mailop 
is rumored to have said:


On 18/04/2024 14:05, Marco Moock via mailop wrote:

Am 18.04.2024 schrieb Bill Cole via mailop :


I can't say that Spamhaus lists IPs that engage in the abusive
practice of remote sender verification but I would be happy to hear
that they are doing so and CSS+XBL listing is a reasonable 
expression

of that sort of world-hostile behavior.


If that sender verification includes trying to send an email until
RCPT TO:, this is abusive in many cases and also uceprotect will list
such servers.


I would have to look further into this, but I was under the impression 
that Exim uses the VRFY command for callout verification?


If it does that, it is a menace to both ends of the connection. The 
problem is that the site asking for verification is exporting its mail 
authentication load to both senders (acceptable) and random forged 
unrelated 3rd parties, which is not acceptable.  The vast majority of 
SMTP mail servers have not answered usefully to VRFY in this millennium, 
so if you were to ask one of those, your answer may bear no relationship 
to reality. Which is fair.


Just to be 100% clear: your first step must be to turn off sender 
verification.


Whether that solves your Spamhaus problem, I cannot say. It will help 
you avoid a thousand little less-visible reputation problems that you 
may be building with every attempt to verify the sender of a forged 
spam.



--
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

Re: [mailop] Reason for being listed at Spamhaus CSS and XBL unclear

[Bill Cole via mailop]

I can't say that Spamhaus lists IPs that engage in the abusive practice 
of remote sender verification but I would be happy to hear that they are 
doing so and CSS+XBL listing is a reasonable expression of that sort of 
world-hostile behavior.


(I saw your Exim-Users discussion)


On 2024-04-18 at 06:52:20 UTC-0400 (Thu, 18 Apr 2024 11:52:20 +0100)
Sebastian Arcus via mailop 
is rumored to have said:

I hope this is within the allowable topics for this list. I tried 
searching the archives, but haven't found an answer for the issue 
below yet. If anyone could shed some light, it would be very much 
appreciated.


A few days ago I started having issues with the public IPv4 address of 
one network I look after ending up on the Spamhaus XBL and CSS 
blacklists. I have taken good hard look at the setup and applied to be 
delisted twice, but it is blacklisted again - so I must be missing 
something. I read through the Spamhaus docs on their website. The 
following applies to this site:


1. Port 25 outbound is completely blocked for the entire network, 
except our inhouse email server which uses Exim

2. The inhouse server doesn't do any sort of relaying.
3. The site doesn't do any sort of marketing or mailing list type 
activity as far as I know - and the Spamhaus detected connections are 
out of working hours - so this being caused by employees sending any 
unwanted emails seems unlikely.
4. I have checked the Exim logs, and there is no sign so far it has 
been compromised in any way, or it is sending out any unusual email 
traffic.
5. This is a low volume site - I would say less than 100 emails sent 
per day.
6. Spamhaus provides the date and timestamp of last rogue connection 
detected - but there is nothing in our Exim log which matches that 
date and time.

7. The information they provided is:

(IP, UTC timestamp, HELO value)
 2024-04-18 05:25:00 

The wording on Spamhaus' website is a bit generic, and seems to hint 
that you can end up blacklisted if infected with a variety of other 
viruses/exploits, not only those to do with smtp. However, because of 
the format of the info above, I was digging in the direction of an 
exploit which uses the smtp protocol to spam the internet.


Does anybody here have some experience with Spamhaus blacklists? Am I 
barking up the wrong tree, and should I cast the net wider, and look 
for any type of infection which scans any other ports on the internet 
- not only the type which would be scanning smtp servers on port 25 
trying to send spam? In our case that should be technically 
impossible, as port 25 outbound is blocked completely on the 
gateway/firewall (except for the email server)? Grateful for any hints 
- as it would be useful to narrow down a bit what am I looking for.

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



--
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

Re: [mailop] Reason for being listed at Spamhaus CSS and XBL unclear

[Bill Cole via mailop]

On 2024-04-18 at 07:18:46 UTC-0400 (Thu, 18 Apr 2024 13:18:46 +0200)
Matus UHLAR - fantomas via mailop 
is rumored to have said:

If you have more than one IP for your network, I recommend use 
separate IP to translate connections from/to your mailserver.


+1
+1000

Don't make your mail server indistinguishable from nearby compromised 
Windows machines and IoT devices.



--
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

Re: [mailop] Anyone from Google - Sudden Gmail bounces??

[Bill Cole via mailop]

On 2024-03-31 at 10:21:40 UTC-0400 (Sun, 31 Mar 2024 17:21:40 +0300)
Odhiambo Washington via mailop 
is rumored to have said:

I have just had several email bounces from a mailing list that I have 
been

running since 2005.
I have contacted Google using this form

and gotten a reference number 7-289335971.

The strangest thing is that I have gotten only 37 bounces whereas my
mailing list has several hundreds of gmail.com addresses.

The bounce text looks like this:

```
  john...@gmail.com
host alt2.gmail-smtp-in.l.google.com [142.251.9.26]
SMTP error from remote mail server after end of data:
550-5.7.1 [41.212.32.14] The IP you're using to send mail is not
authorized to
550-5.7.1 send email directly to our servers. Please use the SMTP 
relay

at your
550-5.7.1 service provider instead. For more information, go to
550 5.7.1  https://support.google.com/mail/?p=NotAuthorizedError
j21-20020a508a9500b0056bacdf79e0si3584946edj.443
- gsmtp
```
Now, this server - 41.212.32.14 - is authorized (by ALL DNS 
requirements
and policies)  to handle mail for lists.kictanet.or.ke which is the 
domain

name used for the mailing lists.

Why would this happen?


Something bad seems to have gained the ability to use that IP...

See https://check.spamhaus.org/listed/?searchterm=41.212.32.14

Google is not known to specifically use Spamhaus listings, so this is 
likely to indicate that both organizations have independently deemed 
your IP to be badly behaving.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Debt Collection Client Email Servers

[Bill Cole via mailop]

On 2024-03-25 at 12:53:31 UTC-0400 (Mon, 25 Mar 2024 17:53:31 +0100)
Jaroslaw Rafa via mailop 
is rumored to have said:

Does USA have a government-certfied platform for electronic delivery 
of

documents


Not for general use. The IRS is piloting a direct tax filing system for 
a small number of taxpayers this year, but that is a very narrow and new 
application. Other departments have their own bespoke document 
submission rules and mechanisms. Some units of government use DocuSign 
or similar services.


There is a general aversion in the USA to the government doing anything 
that even slightly resembles a service that anyone in the private sector 
is already trying to do for a profit. Any such proposal raises screams 
of "SOCIALISM!" which basically kills anything.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Debt Collection Client Email Servers

[Bill Cole via mailop]

On 2024-03-25 at 11:47:11 UTC-0400 (Mon, 25 Mar 2024 15:47:11 +)
Michael Irvine via mailop 
is rumored to have said:

how can we guarantee it to the inbox if many of the users mark it as 
SPAM and potentially blocks other communication.


You cannot. The fact that you have an email address is not any sort of 
evidence that the person who receives mail at that address knows 
anything about why you have it, much less evidence that you have their 
permission to send mail to it.


E.g. Were you to send such email to my most public address, it would be 
spam and I'd treat it as such, because while I have no debts to be 
collected, I am blessed with a fair number of people have given out that 
address maliciously over the past 2 decades; I get a lot of spam aimed 
at me by people who think I want (or deserve?) it. I don't care how 
anyone might have my address, if they send mail to it without 
permission, that email IS spam. So I expect to see none of your mail, 
but I would expect that *some* people receiving it legitimately can *AND 
SHOULD* report it as the spam that it is (for them.)


This is not good nor is it fair. It is a reality that is not going to 
change any time soon. I wish courts and legislators had enough basic 
technical comprehension to prohibit the use of email as a form of 
service for anything legal but they do not, never have, and likely never 
will. So you are going to do something (that you must do) which is 
intrinsically stupid and rude to a mix of some people who arguably 
deserve it and some whom you can only hope will be sympathetic and not 
report it as spam. Hopefully some day the dysfunction will provide 
enough negative feedback to make what you are doing illegal instead of 
unavoidable.




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [spamhaus] de-listing requests successful, but only for a couple of days.

[Bill Cole via mailop]

On 2024-03-14 at 20:26:00 UTC-0400 (Thu, 14 Mar 2024 17:26:00 -0700)
Jay Hennigan via mailop 
is rumored to have said:


On 3/14/24 15:18, Michael Grimm via mailop wrote:

OVH is sharing a /64 subnet among multiple customers since they 
started their public cloud project. You are only provided with a 
single IPv6 address for your instance. In the years before that, I 
had had access to an exclusive /64 subnet.


This is very bad practice on OVH's part. Why are they doing this? Are 
they afraid of running out of IPv6 addresses?


Unlikely.

They are afraid of running out of the scarcity that allows them to make 
money by hoarding addresses and selling the clean ones at a premium.


Proper IPv6 deployment by mass-market hosters and ISPs is an attack on 
their business models. It is, in a sense, anti-capitalist in that it 
eliminates any meaningful address scarcity and so eliminates the 
profitable market for usable addresses.




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled

[Bill Cole via mailop]

On 2024-03-13 at 14:30:40 UTC-0400 (Wed, 13 Mar 2024 20:30:40 +0200 
(EET))

Harald Hannelius via mailop 
is rumored to have said:

Are there SMTP-"clients" that actually are able to back down from 
STARTTLS and continue unencrypted?


I'm not aware of anyway to de-escalate after a STARTTLS on the same TCP 
connection. The plaintext fallback behavior that I'm aware of in MTAs' 
SMTP clients is by way of a fresh connection. Some have done so poorly 
at times and I'm not sure how good fallback is across the class. I don't 
think any MUA client knows how to fall back in any way.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled

[Bill Cole via mailop]

On 2024-03-13 at 14:22:55 UTC-0400 (Wed, 13 Mar 2024 13:22:55 -0500)
Robert Giles via mailop 
is rumored to have said:

Sort of surprising, but I don't think JPMorgan Chase (large U.S. bank) 
is able to do TLS 1.2+ from their outbound JavaMail infrastructure in 
159.53.111.0/24:


I can confirm that essentially all of the legit mail I see using 
TLSv1.[01] bears indicators of JavaMail.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled

[Bill Cole via mailop]

On 2024-03-13 at 10:56:53 UTC-0400 (Wed, 13 Mar 2024 15:56:53 +0100)
Marco Moock via mailop 
is rumored to have said:


Am 13.03.2024 um 10:43:27 Uhr schrieb Bill Cole via mailop:


Without one, disabling them is a cargo-cult praxis that is worse than
any false sense of security provided to oblivious peers who can't do
TLSv1.2 or better.


What are legitimate reasons today not to use TLS 1.2 or 1.3?


I have no idea what the reasons might be for systems that I do not 
manage. Systems that I *do* manage receive legitimate email which is 
affirmatively wanted by the intended recipients over TLSv1.0 
connections, which is an adequate legitimate reason to allow it, given 
that the added risk of allowing all TLS versions is, as far as I can 
tell, zero. The hypothetical vulnerabilities for TLSv1.0 and 1.1 I've 
tried to research fall apart in the context of SMTP and the ability to 
refuse known-weak ciphersuites.


I also have some legacy devices (not ones directly used by humans) which 
cannot be updated to use TLSv1.2 and need to send mail very rarely but 
when they do, I very much want it. Obviously I *could* treat those as a 
set of special cases, but why bother? Such configuration just adds 
complexity unnecessarily.




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled

[Bill Cole via mailop]

On 2024-03-13 at 07:28:18 UTC-0400 (Wed, 13 Mar 2024 11:28:18 + (UTC))
L. Mark Stone via mailop 
is rumored to have said:

> FWIW, our view is that poor encryption can be worse than no encryption, as it 
> can give the participants a false sense of security.  This seems like a good 
> move to us.
>
> We have configured Postfix in our Zimbra MTA servers to do only TLS 1.2/1.3, 
> and fall back to unencrypted if a TLS connection can't be negotiated (per RFC 
> 2487).

Every time I see this argument, I am struck by an important question:

   What is "poor" or "weak" about TLSv1.0 and TLSv1.1 which is relevant
   in the context of SMTP, other than their easily-disabled support for
   weak ciphers?

I've never found a coherent answer. Without one, disabling them is a cargo-cult 
praxis that is worse than any false sense of security provided to oblivious 
peers who can't do TLSv1.2 or better. It is a disservice to end recipients for 
a pair of MTAs to fall back to plaintext when both ends could in principle 
negotiate a rock-solid ciphersuite with TLSv1.0 or TLSv1.1.


-- 
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] % in SRS ?

[Bill Cole via mailop]

On 2024-03-08 at 12:07:23 UTC-0500 (Fri, 08 Mar 2024 17:07:23 +)
Julian Bradfield via mailop 
is rumored to have said:


Is there any reason not to use the old routing character '%' instead?


Yes: it is an old routing character

As such, some sites may misinterpret it in ways that are NOT appropriate 
for SRS.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] freenet.de routing issues anyone? (Cloudflare-OVH issue?)

[Bill Cole via mailop]

On 2024-03-08 at 09:13:32 UTC-0500 (Fri, 8 Mar 2024 15:13:32 +0100)
Stefano Bagnara via mailop 
is rumored to have said:


Well,

I undestand you all hate OVH, but this really doesn't look like an
intended block.


Sure it does.


I tested that when I log to my @freenet.de email I am not able to
write emails to any domain whose DNS are hosted by OVH.


That really looks like an intended block...


I know plenty
of italian companies whose domain zone is at OVH: even if their email
is at Google Workspace or somewhere else they currently cannot receive
emails from @freenet.de and you are telling me this is something
freenet.de done by purpose beucase they didn't want OVH spam? I'll
believe that once a freenet.de people will confirm it.

Considering OVH is the biggest registar in europe they are not
delivering email to most european domains.


Registrars, DNS providers, and hosters are very different things, even 
if they happen to sometimes be the same entity. For example, half of the 
domains I own don't even use DNS from their registrar, who doesn't even 
sell hosting.


OVH being a major registrar doesn't mean much. OVH providing a lot of 
DNS for their registration customers means a bit more, but one can 
resolve DNS indirectly so it's not huge. Being a massive hoster makes 
the cost of blocking them significant, but not necessarily excessive for 
some providers. Freenet.de knows their users better than you do. They 
may have a thousand pinhole exemptions from that blocking making the 
effective price for their customers near zero.



So, if they blocked the whole OVH ASN at their SMTP server I could
even get that (even if I'm not aware of anyone else doing that),


I block OVH ranges by announced route when I see anything in the range 
sending me spam, unless there's a concrete reason not to. It's not 
worthwhile to block by ASN, especially as I am not doing the blocking in 
BGP.



but I
really don't believe they blocked bidirectional routing between 2 ASN
just because freenet thinks OVH is spammy. We hardly see a similar
block when there is a war between 2 countries.


All of your argumentation against this being an intentional block is 
based on the fact that it isn't something YOU would do, because YOU 
would find the cost unacceptable.


That's not a very useful class of reasoning, especially when it is 
inconsistent with evidence. The evidence suggests a broad block of OVH 
by Freenet. That should not happen easily by accident, although it 
certainly could. It is far more likely that it was entirely intentional, 
but lacked careful analysis of the negative effects. It is possible that 
it was entirely intentional and the risks pre-mitigated in ways that you 
cannot see.






Stefano

On Fri, 8 Mar 2024 at 14:49, Yuval Levy via mailop  
wrote:


On 2024-03-08 07:48, Stefano Bagnara via mailop wrote:
On Fri, 8 Mar 2024 at 13:04, Mark Alley  
wrote:
Have you considered they may be blocking OVH ASNs on their 
firewall?


Well, blocking the whole ASNs even to their NS sounds something very
unexpected.


Extreme, yes. Unexpected? I disagree.  It is just another logical
escalation step towards the inevitable, but nothing new.  Think of a
collision between the internet's echo chambers and the Great 
Firewall:

one side wants to control what the other side receives; and the other
side wants to control what it does not receive.

Simple Venn diagram.  When the intersection between the two circles
(agreement on what both sides want to send/receive) has less net 
value
than one of the two separate half-moons, the concerned side may as 
well
block the whole ASN: the cost of sacrificing the intersection is 
lower

than the benefit from allowing the communication less the
filtering/sanitation cost.

Once one side decides that it gets less benefits than cost from the
communication, the other side has three strategic choices:  giving 
more
value; causing less cost; or accepting the disconnect.  They are now 
at

the accepting the disconnect, waiting to see who blinks first.  If
no-one blinks, the disconnect becomes permanent.

The problem is compounded by aggregation on the two sides: well 
behaved
senders will put pressure on their side; the rats may abandon ship 
and

raid the next ISP with weak policies.  Affected recipients will put
pressure on their side to remove the filter.  The question is where
those pressures will burst.  My hope is that someone at OVH will wake 
up

and mop up the neighborhood that they control.

Personally, I am still looking for the ideal firewall: block all ASNs
unless permitted.  And even after that, the next battlefields are
already in sight: wireless network traversal.

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




--
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs
___
mailop mailing list
mailop@mailop.org

Re: [mailop] Filter out emoji from email adresses

[Bill Cole via mailop]

On 2024-03-06 at 18:51:10 UTC-0500 (Wed, 6 Mar 2024 23:51:10 + 
(GMT))

Andrew C Aitchison via mailop 
is rumored to have said:


On Wed, 6 Mar 2024, John Levine via mailop wrote:

Right.  I am aware of communities of EAI mail users in India and 
Thailand,
but not anywhere else.  You might expect EAI users in China, but 
nope,

for reasons I can explain if anyone cares.

Everywhere else people use ASCII mail addresses, even though they are
often writing mail in non-ASCII character sets.


I get plenty of non-ASCII characters in the quote part of mail
addresses from European members of lists, including this one.



Right, but they do not use the SMTPUTF8/EAI mechanism (raw UTF8 
characters) but instead use the long-established MIME mechanism for 
encoding non-ASCII header fields using Base64 or Quoted-Printable.





--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] MTA-STS errors?

[Bill Cole via mailop]

On 2024-03-06 at 13:35:10 UTC-0500 (Wed, 6 Mar 2024 13:35:10 -0500)
Michael W. Lucas via mailop 
is rumored to have said:


On Wed, Mar 06, 2024 at 01:17:43PM -0500, Bill Cole via mailop wrote:


Call me crazy, but if the policy changes on sub-day cadence, I don't 
think I
want that email anyway. If you need me to re-check your policy twice 
a day,

it's not Policy.


Short timeouts are good for initial tests, but of course I'll be
bumping this up to a week when I know everything works.


Sure, but I was channeling the Big G. You're testing against their 
production, which is going to act like a production system and get all 
huffy about test-like behavior.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] MTA-STS errors?

[Bill Cole via mailop]

On 2024-03-06 at 12:44:18 UTC-0500 (Wed, 6 Mar 2024 12:44:18 -0500)
Michael W. Lucas via mailop 
is rumored to have said:

On Wed, Mar 06, 2024 at 05:46:06PM +0100, Bernardo Reino via mailop 
wrote:

On Wed, 6 Mar 2024, Michael W. Lucas via mailop wrote:


...
Apparently "Google will only process policies with a max_age higher 
than
86000 seconds. Policies with a max_age of 86000 or lower will be 
ignored and

a daily no-policy-found report will be sent if TLS-RPT is enabled."
(link: https://www.uriports.com/blog/mta-sts-explained/)

So if you want Google to consider your policy as "valid" you shoud 
make

max_age 86400 or higher. ¯\_(ツ)_/¯


Aha! Thank you!

There's the RFC, then there's what people expect...


Call me crazy, but if the policy changes on sub-day cadence, I don't 
think I want that email anyway. If you need me to re-check your policy 
twice a day, it's not Policy.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Filter out emoji from email adresses

[Bill Cole via mailop]

On 2024-03-06 at 12:30:30 UTC-0500 (Wed, 06 Mar 2024 17:30:30 +)
Slavko via mailop 
is rumored to have said:

Dňa 6. marca 2024 15:52:47 UTC používateľ John Levine via mailop 
 napísal:



There's an extension called SMTPUTF8, informally known as EAI for
Email Address Internationalization, that in principle allows any 
UTF-8

in addresses, but unless you are sending mail to people in India or
Thailand, you don't want to try it.


AFAIK, for most of the world is US-ASCII not enough, not only for
India or Thailand.


Absolutely true. However, I believe that what John meant to point out is 
that support for SMTPUTF8 *in MTAs operating as MXs* is not widespread 
enough to be useful except for mail to Indian and Thai addresses, 
because even the rest of the non-ASCII world has broadly not yet decided 
to allow SMTPUTF8. Hence, you are likely to not have success sending 
high-bit-set bytes in headers unless you have a narrowly limited 
audience of receivers.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Anyone from Yahoo?

[Bill Cole via mailop]

On 2024-03-05 at 18:12:05 UTC-0500 (Tue, 5 Mar 2024 19:12:05 -0400)
Thomas Johnson via mailop 
is rumored to have said:


Hello everyone-

We had an incident where a trusted connection from Microsoft had a 
nice large dump of spam - it appears that several of their customers 
were compromised.


"Trusted connection" is an obsolete concept. Has been for years, but 
people hate giving it up. People can be trusted, computers not so much.


Filter all your mail. Never forward anything that your filters think is 
spam or any other flavor of garbage. NO MAIL can be trusted based simply 
on where it came from.


We've stopped it, and we're sure it's not going to happen again, but 
yahoo has listed our IP address blocks with a dreaded "553 5.7.2 
[TSS09] All messages from X.X.X.X will be permanently deferred; 
Retrying will NOT succeed. See 
https://postmaster.yahooinc.com/error-codes;


I've filed a help request at senders.yahooinc.com, but I'd love if 
anyone has a contact at yahoo that could help.


I believe Lili Crowley has been helpful to people mentioning Yahoo/AOL 
issues here. Her address should be in the archives...


In my experience, at least in recent years, Yahoo has the only 
properly-working unblocking system among any of the behemoths. Not fast, 
but functional.


We've got a lot of schools that have parents with yahoo email 
addresses, and we really want to get things cleared up with them as 
quickly as possible.


My least favorite mail stream ever was school progress reports. Students 
are often motivated to report them as spam, which occasionally will 
convince a mail provider to filter them. And many providers who don't 
filter them will still send a steady stream of spam reports of them in 
their FBLs and instill a sense of impending doom.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Any Apple guys, with knowledge of their networks shed some light on this IP Space?

[Bill Cole via mailop]

On 2024-03-04 at 18:00:24 UTC-0500 (Mon, 4 Mar 2024 15:00:24 -0800)
Michael Peddemors via mailop 
is rumored to have said:

Does anyone know what this IP space is assigned for in general? 
Tracking some new threats..


inetnum:144.178.0.0 - 144.178.63.255
descr:  Apple Inc
status: LEGACY


I have a strong recollection of Apple using 144.* for network 
infrastructure, forever ago. Different millennium.


Don't ask how. I have no evidence.





remarks:Cupertino
admin-c:JD9555-RIPE
tech-c: JD9555-RIPE
netname:Apple-144-178-0-0-18
country:GB
mnt-by: APPLE-MNT
mnt-routes: APPLE-MNT
created:2017-04-19T07:38:55Z
last-modified:  2019-02-16T16:04:54Z
source: RIPE




--
"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



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] PTR check mechanism / gmail

[Bill Cole via mailop]

On 2024-03-03 at 14:36:25 UTC-0500 (Sun, 3 Mar 2024 20:36:25 +0100)
Marco Moock via mailop 
is rumored to have said:


Most server require that the PTR points to a domain name like
mail.example.org and that has the corresponding A/ records that
point to the IP address.


"Most" is probably an overstatement. Requiring that the PTR result 
resolves back to the client IP will lose you a small subset of mail from 
the Microsoft outbounds (a chronically small proportion of which are 
just wrong) and a whole lot of smaller sources of wanted email.


A common alternative configuration is requiring that an IP have a PTR 
(equivalent to Postfix's "reject_unknown_reverse_client_hostname") and 
sometimes people figure out ways to require more (e.g. that the name 
resolve to something.)



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Outgoing Spam from Microsoft IPs

[Bill Cole via mailop]

On 2024-02-19 at 08:26:18 UTC-0500 (Mon, 19 Feb 2024 13:26:18 +)
Slavko via mailop 
is rumored to have said:

Dňa 19. februára 2024 12:46:51 UTC používateľ "Gellner, Oliver 
via mailop"  napísal:


...the big email services providers need to make the first step in a 
coordinated procedure. Otherwise the sender is unlikely going to fix 
his setup and rather blame the receiver, because obviously he can 
deliver his emails everywhere, just not to our place.


Why big only? If cooradination have to be success (almost) all
have to be involved. Something as was DNS flag day...


Not at all. If the big mailbox providers switch and break mail to them 
from non-compliant senders, everything else still functions normally. No 
need for any sort of "flag day."



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Verifying receipients?

[Bill Cole via mailop]

On 2024-02-16 at 15:49:12 UTC-0500 (Fri, 16 Feb 2024 14:49:12 -0600)
Jesse Hathaway via mailop 
is rumored to have said:


What is this current attitude on using something like
Postfix's `reject_unverified_recipient`?


ONLY use this when you are relaying for specific domains that you 
service where you do not have any way to obtain a definitive user list.



Does probing for recipients work these days, is it considered abusive?


Probing for recipients on systems where you do not have explicit prior 
permission to do so is asking to be treated like a criminal. It also 
tends not to work.


The same goes for sender verification.

--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Why is mail forwarding such a mess?

[Bill Cole via mailop]

On 2024-02-12 at 14:23:39 UTC-0500 (Mon, 12 Feb 2024 20:23:39 +0100)
Thomas Walter via mailop 
is rumored to have said:

> Hey Bill,
>
> On 12.02.24 17:31, Bill Cole via mailop wrote:
>> On 2024-02-12 at 07:13:13 UTC-0500 (Mon, 12 Feb 2024 13:13:13 +0100)
>> Thomas Walter via mailop 
>> is rumored to have said:
>>
>>> There are other issues with this though. For example you are exposing 
>>> information you might not want to.
>>
>> Beyond that, it would enable both malicious reflection attacks and improper 
>> diversion of mail with very little visibility.
>
>
> I am not sure I understand your concerns, how would those work?

The mail server providing the redirection may not be doing what the original 
address owner OR the owner of the address to which they are redirecting 
actually wants. Redirection could allow malicious server operators to direct 
3rd parties to send unwanted mail to an unrelated victim or to send wanted mail 
which should be private to those from which it is meant to be kept secret. 
There is no standard way to record such a redirection in a Received header or 
any other header which would document why a message was routed in a particular 
way and no way for the sending system to validate that the redirection is 
benign.

-- 
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Why is mail forwarding such a mess?

[Bill Cole via mailop]

On 2024-02-12 at 07:13:13 UTC-0500 (Mon, 12 Feb 2024 13:13:13 +0100)
Thomas Walter via mailop 
is rumored to have said:

> There are other issues with this though. For example you are exposing 
> information you might not want to.

Beyond that, it would enable both malicious reflection attacks and improper 
diversion of mail with very little visibility.


-- 
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire


signature.asc
Description: OpenPGP digital signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] problem setting up open-dmarc

[Bill Cole via mailop]

On 2024-02-07 at 05:40:50 UTC-0500 (Wed, 7 Feb 2024 12:40:50 +0200)
Taavi Eomäe via mailop 
is rumored to have said:

[Snip. Quoting Michael P.]
>> Unless you are a big budget email sender, don't stress to much.  Maybe 
>> tomorrow we will need something like DMARC, but thankfully not yet today.
> You need it right now if you want to protect your communication against 
> forgeries.

Not so much. DKIM and SPF are adequate for most senders. Arguably, SPF would 
suffice for most sending domains if it were not for transparent forwarding.


-- 
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire


signature.asc
Description: OpenPGP digital signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DMARC on srs forwarding domains?

[Bill Cole via mailop]

On 2024-02-02 at 10:26:55 UTC-0500 (Fri, 2 Feb 2024 16:26:55 +0100)
Kai Bojens via mailop 
is rumored to have said:


Am 02.02.24 um 16:08 schrieb Mark E. Jeftovic via mailop:

We're having a bit of a theological debate internally on whether to 
implement DMARC on our SRS forwarder domains.


Skip SRS and implement ARC for forwarded e-mails. This should solve 
all these problems.


Telling the next hops that they need to parse ARC and trust your system 
instead of just checking SPF is a choice that one can make, yes.


Without SRS, SPF will fail on forwarded mail. It is going to be rare for 
anyone other than the behemoths to support ARC in any meaningful way for 
the near term (0-5 years) and you will always (effectively... ) have 
sites rejecting on SPF failures out of misguided "principle."




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

[Bill Cole via mailop]

On 2024-01-23 at 15:35:45 UTC-0500 (Tue, 23 Jan 2024 12:35:45 -0800)
Randolf Richardson, Postmaster via mailop 
is rumored to have said:

> spamware seems to fall back to the "A" and "" records in the
> absence of an MX records

Also known as "doing the right thing."

> (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).

Very much NOT the right thing.

-- 
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

[Bill Cole via mailop]

On 2024-01-23 at 15:00:01 UTC-0500 (Tue, 23 Jan 2024 15:00:01 -0500)
Kevin A. McGrail via mailop 
is rumored to have said:


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.  
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.


I don't believe that is true, since you can reject based on recipient 
addresses in the filter_recipient() subroutine, where you have both a 
current recipient and the client IP each time that it is called.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Spamhaus contact?

[Bill Cole via mailop]

On 2024-01-19 at 15:42:49 UTC-0500 (Fri, 19 Jan 2024 12:42:49 -0800)
Randolf Richardson, Postmaster via mailop 


is rumored to have said:


Spamhaus makes the DROP data available (which I believe is also
included in their SBL), which is useful for using firewalls to just
block or ignore connections from the worst offenders:

DROP Advisory Null List :: The Spamhaus Don't Route Or Peer 
Lists
https://www.spamhaus.org/drop/

UCE Protect also has level 3 listings for the worst offenders,
although I don't recall the list being downloadable for firewall use:

UCEPROTECT Blacklist Policy LEVEL 3
https://www.uceprotect.net/en/index.php?m=3=5


It is important to understand that theses are RADICALLY DIFFERENT 
DATASETS.


Spamhaus DROP is a fairly small list of address blocks (supplemented by 
the even smaller EDROP) that one can expect NO friendly traffic from. NO 
ONE should see any collateral damage from using DROP.


UCEPROTECT L3 is an intentional collateral damage list. If one COULD use 
it as a router blocking list, one would not perceive the Internet to be 
functional.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Anyone else noticing an increase in spam from Office365 distribution lists?

[Bill Cole via mailop]

On 2024-01-19 at 07:03:35 UTC-0500 (Fri, 19 Jan 2024 12:03:35 +)
Simon Arlott via mailop 
is rumored to have said:


On 19/01/2024 00:33, Randolf Richardson, Postmaster via mailop wrote:

The blacklists seem to be blocking mostly the ones that send
directly from @.onmicrosoft.com addresses, which
should make filtering easy if we can confirm for certain that no
legitimate eMail has these as the sender -- that is, not in the
"Return-Path:" header and not in the "From:" header.


I have a legitimate email today from @example.onmicrosoft.com (both
envelope sender and From: header) that is a cross-organisation meeting
invite. Normally all of their email uses their domain but some 
Microsoft

software is using this internal domain for meeting invites.

Indiscriminate blocking is going to unexpectedly reject real email.


There are some very well-known major corporations who have had policies 
of rejecting any meeting invites with .ics files unless the sender is 
whitelisted. Too many people do not expect random strangers "inviting" 
them to meetings and have their settings configured to auto-accept 
invites.





--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Spamhaus contact?

[Bill Cole via mailop]

On 2024-01-19 at 09:31:19 UTC-0500 (Fri, 19 Jan 2024 15:31:19 +0100)
hg user via mailop 
is rumored to have said:


Ok sorry not "most" but "some may"...

My checkpoint rep said that they get their reputation lists from other
companies... is it wrong ?


In all likelihood that means they don't manage their own blocking 
list(s) but rather buy information from DNSBL operators and other 
assemblers of raw data such as Spamhaus, Proofpoint, Cisco, and others.  
To the best of my knowledge, Checkpoint only uses that information in 
the devices they sell customers, and they are not operating their own 
generally available DNSBL.




On Fri, Jan 19, 2024 at 10:55 AM Atro Tossavainen via mailop <
mailop@mailop.org> wrote:


Since most RBLs exchange data,


Source?

--
Atro Tossavainen, Chairman of the Board
Infinite Mho Oy, Helsinki, Finland
tel. +358-44-5000 600, http://www.infinitemho.fi/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop




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



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Spamhaus contact?

[Bill Cole via mailop]

On 2024-01-19 at 05:31:12 UTC-0500 (Fri, 19 Jan 2024 10:31:12 +)
Graeme Fowler via mailop 
is rumored to have said:

On 19 January 2024 06:13:20 hg user via mailop  
wrote:

Since most RBLs exchange data


Small pedantic point: DNSBLs, not RBLs.


As an erstwhile MAPS employee, the persistence of this pedantry warms my 
heart...


Also, to author[-1], I think it is a bit of a misimpression that DNSBL 
operators share data. In some cases they may have overlapping sources, 
and obviously they can query each others' lists, but there's legal peril 
in DNSBL operators working together and using each others' non-public 
data. You can be fairly sure that if Spamhaus and SORBS (Proofpoint) and 
Barracuda are all listing an IP, they each have their own trustworthy 
data to back it up.


Trend Micro would still assert that the term RBL is their trademark 
(so far as I know), plus a non-small percentage of known DNS block 
lists could not be even marginally described as "real time".


Well, there is also that...

Graeme (wearing massive floppy felt pedant hat with huge gold tassels 
attached to make the point) :)


Excellence in headgear.

--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] o365 outbound senders.. Strange Failures sending .. widespread reports

[Bill Cole via mailop]

On 2023-12-19 at 01:12:56 UTC-0500 (Tue, 19 Dec 2023 07:12:56 +0100)
Benny Pedersen via mailop 
is rumored to have said:


EHLO after STARTTLS, clearly bots only


Nope. Vide:

Dec 19 08:31:47 shiny postfix/smtpd[94038]: disconnect from 
mxout1-he-de.apache.org[95.216.194.37] ehlo=2 starttls=1 mail=1 rcpt=1 
data=1 quit=1 commands=7



EHLO after STARTTLS is normal and proper. See the RFC.

--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] ECDSA DKIM validation?

[Bill Cole via mailop]

On 2023-12-18 at 15:03:16 UTC-0500 (Mon, 18 Dec 2023 15:03:16 -0500)
Michael W. Lucas via mailop 
is rumored to have said:

> Hi,
>
> Last I checked a few years ago, validation of ECDSA DKIM keys was
> still iffy on deployed servers. Has the situation improved? Can we
> recommend ECDSA DKIM yet without ruining people's day?

Exclusively? Not yet.

-- 
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Merry Christmas from Google?

[Bill Cole via mailop]

On 2023-12-17 at 04:45:04 UTC-0500 (Sun, 17 Dec 2023 10:45:04 +0100)
Benny Pedersen via mailop 
is rumored to have said:


false, every forwarder changes envelope sender,


No matter how many times you say this, it remains a dangerously 
misleading lie.


If, on a Unix-like system running Postfix or Sendmail in their most 
common configurations, you place a file in a user's home directory named 
".forward," then the MTA will not deliver messages locally but will 
relay them via SMTP to the address in  the .forward file using the same 
envelope sender as the message used in its arrival. Addresses which are 
directed via the /etc/aliases or other 'aliasing' mechanisms ALSO are 
relayed using the original envelope sender.


That FACT is the entire reason the SRS mechanism (and tools like 
postsrsd) exist. Traditional forwarding breaks SPF. Everyone involved 
knew this from the earliest discussions that resulted in SPF.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Hotmail complains about their own mail

[Bill Cole via mailop]

On 2023-12-16 at 11:31:18 UTC-0500 (Sat, 16 Dec 2023 17:31:18 +0100)
Thomas Walter via mailop 
is rumored to have said:

> On 16.12.23 12:11, ml+mailop--- via mailop wrote:
>> On Sat, Dec 16, 2023, Thomas Walter via mailop wrote:
>>
>>> 2. Our server bounces with 550 5.1.1 User doesn't exist.
>>
>> Does your server generate a DSN?
>> If the "User doesn't exist" then it seems you should be able to
>> determine that fact when RCPT is given -- or is this just a bogus
>> reply?
>
> It's a catchall forwarded domain "@olddomain -> @newdomain", so Postfix 
> accepted it before checking the final recipient.

That's not tenable in the modern world.

> Now that you said it, I'm going to suggest to the user to just alias 
> individual addresses instead of the catchall.

Another alternative that is available in Postfix would be to accept certain 
patterns (i.e. a regexp or pcre table) and not others, such that the user could 
create arbitrary addresses within the accepted patterns, which preferably are 
not matched by the delusions of random spammers

> I still think Microsoft should not complain about NDRs, especially if the 
> original was from them.

NDRs have become taboo over the past ~25 years. The sound reasons for 
generating them for non-deliverable mail from the world at large have been 
overwhelmed by the nuisance of "backscatter" from systems that 
accept-then-bounce bogus local addresses without doing an adequate job of 
authenticating the original envelope sender (which is not possible to do 
reliably.)

But yes: it is useless for MS (or anyone else) to complain about backscatter. 
It's far more efficient to just stop accepting mail from backscatter sources 
and wait for complaints. A large fraction of such systems never handle a 
legitimate message for the domains to which they send their garbage.


-- 
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire


signature.asc
Description: OpenPGP digital signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Another very strange microsoft originated email??

[Bill Cole via mailop]

On 2023-12-07 at 16:20:23 UTC-0500 (Thu, 7 Dec 2023 13:20:23 -0800)
Michael Peddemors via mailop 
is rumored to have said:

For the record, the command line 'whois' tool is getting long in the 
tooth, and the maintainer isnt' really interested in updating the 
tools, database.. (We offered to help)


Which whois?

The one at https://github.com/rfc1036/whois maintained by Marco D'Itri 
had a release last month, as can be seen at 
http://ftp.debian.org/debian/pool/main/w/whois/



But, because I end up showing this to our own staff, a little trick..

whois 49.13.172.216 -h whois.ripe.net

You CAN query the individual RIR's directly.. There are also other 
query methods directly available from RIR's, and 3rd parties like 
'ipinfo' you can also check..


Still have it on the project list for a new unified 'rwhois' 
standalone tool, and SaaS.. for the community.. .. but never enough 
hours in the day, or budgets for opensource projects ;0




Make sure you integrate RDAP.

ALSO: It should include a pony for every user.




On 2023-12-07 12:44, Randolf Richardson, Postmaster via mailop wrote:

I'm not familiar with Hertzner, but APNIC's WHOIS indicates a
country code of ZZ for the sending IP address's netblock, which the
ISO lists as "Unknown or unspecified country."

I guess the whole /23 is in the process of being moved?  The most
recent modification seems to be ~7 months ago (2023-May-17).

debian# whois 49.13.172.216
% [whois.apnic.net]
% Whois data copyright terms
http://www.apnic.net/db/dbcopyright.html


% Information related to '49.12.0.0 - 49.13.255.255'

% Abuse contact for '49.12.0.0 - 49.13.255.255' is 
'no-em...@apnic.net'


inetnum:49.12.0.0 - 49.13.255.255
netname:STUB-49-12SLASH15
descr:  Transferred to the RIPE region on 
2018-06-27T02:24:02Z.

country:ZZ
admin-c:STUB-AP
tech-c: STUB-AP
abuse-c:AS2444-AP
status: ALLOCATED PORTABLE
mnt-by: APNIC-STUB
mnt-irt:IRT-STUB-AP
last-modified:  2023-05-17T13:13:11Z
source: APNIC

irt:IRT-STUB-AP
address:N/A
e-mail: no-em...@apnic.net
abuse-mailbox:  no-em...@apnic.net
admin-c:STUB-AP
tech-c: STUB-AP
auth:   # Filtered
remarks:IRT for stub records.
remarks:We do not operate the referring network and
remarks:are unable to investigate complaints of network 
abuse.

remarks:For information about IRT, see www.apnic.net/irt
remarks:no-em...@apnic.net is invalid
mnt-by: APNIC-HM
last-modified:  2023-05-17T13:09:19Z
source: APNIC

role:   ABUSE STUBAP
address:N/A
country:ZZ
phone:  +0
e-mail: no-em...@apnic.net
admin-c:STUB-AP
tech-c: STUB-AP
nic-hdl:AS2444-AP
remarks:Generated from irt object IRT-STUB-AP
remarks:no-em...@apnic.net is invalid
abuse-mailbox:  no-em...@apnic.net
mnt-by: APNIC-ABUSE
last-modified:  2023-05-17T13:13:08Z
source: APNIC

person: STUB PERSON
address:N/A
country:ZZ
phone:  +00  
e-mail: no-em...@apnic.net
nic-hdl:STUB-AP
remarks:No contact information for stub records.
mnt-by: APNIC-HM
last-modified:  2019-09-23T04:53:33Z
source: APNIC

% This query was served by the APNIC Whois Service version 1.88.25 
(WHOIS-US4)


Free trial account on Microsoft 365 being relayed through Microsoft 
365 outbounds by a Hetzner IP


--srs

From: mailop  on behalf of Michael 
Peddemors via mailop 

Sent: Thursday, December 7, 2023 5:38:33 AM
To: mailop@mailop.org 
Subject: [mailop] Another very strange microsoft originated email??

Take a look at the headers for this one..
Appears to come from an sender IP on Hetzner, but related to 
Microsoft??


Some headers snipped for brevity, but something sure appears rotten 
in
denmark..  love the boundary.. Any takers on explained how this is 
being

allowed or performed?

Return-Path: 
Received: from mail-psaapc01on2064.outbound.protection.outlook.com 
(HELO

APC01-PSA-obe.outbound.protection.outlook.com) (40.107.255.64)

...

X-MS-Exchange-Authentication-Results: spf=fail (sender IP is 
49.13.172.216)
   smtp.mailfrom=cdklu.onmicrosoft.com; dkim=none (message not 
signed)
   header.d=none;dmarc=none action=none 
header.from=cdklu.onmicrosoft.com;

From: Autozone Department 
Subject: Celebrating Autozone anniversary with an DEWALT 200 Piece
Mechanics Tool Set
In-Reply: 
Content-Type: multipart/alternative; 
charset="UTF-8";boundary="FakOj.oyfbwp"





--
"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 Registered TradeMark of Wizard Tower TechnoServices 
Ltd.

Re: [mailop] Convincing clients of the importance of eMail recipient consent for mailing list subscriptions

[Bill Cole via mailop]

On 2023-11-28 at 08:39:13 UTC-0500 (Tue, 28 Nov 2023 13:39:13 +)
Laura Atkins via mailop 
is rumored to have said:

Hell, even if you are dishonest and make the costs of deliverability 
problems higher than they are it can still be challenging to make COI 
look more profitable.


I really wish this weren’t true and I’ve been trying to make it 
true for years. But, sometimes reality bites.



Yep.

If sending lots of mail to weakly engaged corespondents is your core 
business, COI is not likely to be worthwhile in cold hard cash vs. what 
I call "good faith single opt-in" where it is credible that subscribers 
are predominantly legit, by whatever means that is achieved. Unless a 
bulk-sending entity is engaged in  nearly pure spam using sketchy 
tactics, the risks of blocking costing a lot is low.


OTOH, if bulk mail is an auxiliary service to more valuable (per 
message) email,  the cost of being blocked can be the whole business. 
The more you handle typical conversational email, the less you can 
tolerate practices that lead to blocking.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Convincing clients of the importance of eMail recipient consent for mailing list subscriptions

[Bill Cole via mailop]

On 2023-11-27 at 13:42:58 UTC-0500 (Mon, 27 Nov 2023 10:42:58 -0800)
Randolf Richardson, Postmaster via mailop 
is rumored to have said:


What have you found to be some of the best approaches to convince
clients that the confirmed opt-in process is necessary for operating
eMail lists?  (The ethical aspects are pretty straight-forward.)



Specifying it explicitly in service contracts and making absolutely sure 
that the customer is aware that failing to confirm opt-ins will result 
in immediate permanent service termination, and they may receive any 
data associated with their account shipped to them on physical media by 
request. That is obviously only possible with full management support.


We've had exactly one misunderstanding of this in the past 15 years. As 
you say, the ethical aspects are clear and we have the luxury of being 
able to screen customers well. I expect this is only feasible for 
similar operations where mailing list hosting is not a free-standing 
offering, but only something we offer to our mailbox customers.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Historical spam loads - was Re: Google rate-limiting more aggressively than usual?

[Bill Cole via mailop]

On 2023-11-19 at 14:02:04 UTC-0500 (Sun, 19 Nov 2023 19:02:04 + 
(GMT))

Andrew C Aitchison via mailop 
is rumored to have said:


On Sun, 19 Nov 2023, Bill Cole via mailop wrote:


On 2023-11-19 at 06:59:37 UTC-0500 (Sun, 19 Nov 2023 12:59:37 +0100)
Alessandro Vesely via mailop 
is rumored to have said:

I don't think someone can drop almost all mail and still call itself 
a mail server.


Were you running a mail system in the early-mid 2000s?

At that time, I tracked the performance of a mid-sized spam control 
system for a business that handled around a million inbound SMTP 
sessions per day. The proportion of mail we rejected as spam was 
persistently over 90%, and at times broke 98%. We never had a 
significant FP problem.


Although the server I ran at that time did listen to the whole 
internet,

our MX pointed at a service that spared me from much of that spam,
though I was aware of it and knew the folks stopping it for me.


The state of email is better today,


That is a surprise to hear. Reading this list has given me the 
impression
that the spam volume is worse now than it was then. Spamming is a much 
bigger
business now and the internet is faster, so I would have thought 
spammers
would be sending more messages, even compared to the increase in 
legitimate

email.

If they are sending comparatively fewer messages I can only imagine
that is because their strike rate is better, which is *more* worrying.
What have I misunderstood ?


The biggest contributor to the reduction in spam:ham ratio from what 
I've seen is a decline in the volume of blatant spambots operating on 
compromised personal devices. Right behind that would be how much more 
B2C marketing mail people are eager to receive. Years of nominally 
legitimate businesses sending bulk mail with marginally acceptable 
practices have conditioned people to accepting more mail as "ham" today 
than they did 15-20 years ago.



And that could of course be particular to the SMB mailboxes of my users. 
Maybe non-business mailboxes are seeing more garbage, but my 
junk-catchers at GMail, Yahoo, Outlook.com, iCloud, and GMX haven't seen 
it. (They suffer from the flaw of having absolutely zero legit exposure 
to commercial entities, so they are not 'typical' freemail accounts.) 
The volume of junk hitting those mailboxes (both Inbox and "spam folder" 
delivery) has dropped over the past few years.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Google rate-limiting more aggressively than usual?

[Bill Cole via mailop]

On 2023-11-19 at 06:59:37 UTC-0500 (Sun, 19 Nov 2023 12:59:37 +0100)
Alessandro Vesely via mailop 
is rumored to have said:

I don't think someone can drop almost all mail and still call itself a 
mail server.


Were you running a mail system in the early-mid 2000s?

At that time, I tracked the performance of a mid-sized spam control 
system for a business that handled around a million inbound SMTP 
sessions per day. The proportion of mail we rejected as spam was 
persistently over 90%, and at times broke 98%. We never had a 
significant FP problem.


The state of email is better today, but I wouldn't be at all surprised 
if some sites still have a 90%+ spam burden.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] If one signature is good, 72 signatures must be better

[Bill Cole via mailop]

On 2023-11-16 at 06:49:03 UTC-0500 (16 Nov 2023 06:49:03 -0500)
John Levine via mailop 
is rumored to have said:

It appears that Gellner, Oliver via mailop  
said:

On 16.11.2023 at 03:05 John Levine via mailop wrote:

I just got a couple of quite remarkable messages from Sabre's 
Tripcase service, confirming that they'd received some info I mailed 
thmm.
Below you can see the Authentication Results header my mail server 
added.
All 72 valid DKIM signatures really are there, and I am trying to 
imagine what kind of screwup at Proofpoint added them. If anyone 
would like
the whole message, just ask. There's nothing interesting in it other 
than the signatures.


Probably they don't know how to apply a specific signature based on 
the From address. So instead they apply all DKIM signatures they have 
to all

emails.


I've gotten a lot of mail from Tripcase and this is the first one with 
72 signatures.  It's obviously

a bug, but it's a rather strange bug.


My bet is that it's a line-break error. Some text file somewhere is 
missing LFs



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] How to handle hostname and PTR mismatch?

[Bill Cole via mailop]

On 2023-10-27 at 09:19:33 UTC-0400 (Fri, 27 Oct 2023 15:19:33 +0200)
Cyril - ImprovMX via mailop 
is rumored to have said:


Hi!

It's been quite common to refuse a server connecting that doesn't have 
a
proper PTR, but I was wondering if there was any recommendation 
(either
official via RFC or standard practice) about a server connecting with 
a PTR
that is different from the announced hostname at the HELO/EHLO 
command.


RFC 2822 et seq. prohibit receivers from requiring the EHLO hostname to 
match the PTR. It has generally been recognized as unsafe to require 
that OR to require that the EHLO name resolve at all OR to require that 
the PTR name resolves back to the client IP address. The RFC-specified 
application of SPF to EHLO names is worthless.


But people do a lot of unsafe things.

For instance, if my server has a PTR with mail1.example.com, and I 
connect
by saying "HELO send.example.com". If the receiving server loads all 
the

IPs for "send.example.com" but doesn't find my server's IP, should it
refuse the email or accept it ?


It should not refuse the email *solely* for that reason.

The use of the word 'should' is intentionally vague. Some sites WILL 
refuse mail based on such absurdities and no amount of RFC-lawyering 
will change their minds.




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] fastmail and sender score snafu

[Bill Cole via mailop]

On 2023-10-09 at 03:46:08 UTC-0400 (Mon, 9 Oct 2023 07:46:08 +)
Gellner, Oliver via mailop 
is rumored to have said:

Postfix default of the maximum queue lifetime is 5 days: 
https://www.postfix.org/postconf.5.html#maximal_queue_lifetime
One month is very long, but I usually see systems to retry for at 
least three days to cover outages of MTAs that cannot be solved within 
a few hours or for example happen on a weekend. Not all MTAs are run 
by enterprises with 24/7 staff availability.


5 days has been a widespread norm since the core of the Internet was 
academic and traditional business organizations where you could 
reasonably expect an outage starting on Friday night would not even be 
noticed until Monday morning. I'm pretty sure my first IDA/KJS Sendmail 
machine had a 5-day queue lifetime, as I had no clue how to change it...


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Zero-day RCE for exim - whacky stats?

[Bill Cole via mailop]

On 2023-09-30 at 03:36:02 UTC-0400 (Sat, 30 Sep 2023 08:36:02 +0100 
(BST))

Andrew C Aitchison via mailop 
is rumored to have said:


On Sat, 30 Sep 2023, Jay R. Ashworth via mailop wrote:

I haven't even heard exim *mentioned* in like 20 years; these stats 
can't be

right, can they?

https://www.bleepingcomputer.com/news/security/millions-of-exim-mail-servers-exposed-to-zero-day-rce-attacks/


https://arstechnica.com/security/2023/09/critical-vulnerabilities-in-exim-threaten-over-250k-email-servers-worldwide/?comments=1

gives a more plausible stat.


The discrepancy is almost certainly an artifact of Exim being used so 
widely in cPanel.




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail says "Message bounced due to organizational settings."

[Bill Cole via mailop]

On 2023-09-26 at 20:57:10 UTC-0400 (26 Sep 2023 20:57:10 -0400)
John Levine via mailop 
is rumored to have said:


"Message bounced due to
organizational settings."


It should only be possible to get that from GMail if the sender is part 
of a GApps organization that has organization-wide rules set up. Or if 
they are sending *to* such an organization.


E.g. an org like arxiv.org:

# host  arxiv.org
arxiv.org has address 128.84.21.199
arxiv.org mail is handled by 10 alt3.aspmx.l.google.com.
arxiv.org mail is handled by 10 alt4.aspmx.l.google.com.
arxiv.org mail is handled by 1 aspmx.l.google.com.
arxiv.org mail is handled by 5 alt1.aspmx.l.google.com.
arxiv.org mail is handled by 5 alt2.aspmx.l.google.com.

So, clearly the problem is somewhere at Google...

--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Amazon SES using SAME sender Domain for multiple customer?

[Bill Cole via mailop]

On 2023-09-25 at 08:49:51 UTC-0400 (Mon, 25 Sep 2023 12:49:51 +)
Mike Hillyer via mailop 
is rumored to have said:

They do encourage users to send from their own domain, but they do not 
require it before using Amazon SES.


It might be tactically useful for people who can take the FP hit to 
create external pressure for Amazon & their customers to tighten up 
their practices...


(I've been doing my part in that effort for a couple years, but I've 
been rejecting nearly nothing from SES in recent months.)


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Authentication Bounces by Gmail

[Bill Cole via mailop]

On 2023-09-19 at 17:52:33 UTC-0400 (Tue, 19 Sep 2023 14:52:33 -0700)
Bill Sommerfeld via mailop 
is rumored to have said:

A similar form of damage I just noticed today was an 
outsourced-to-Microsoft mail service breaking a forwarded message's 
DKIM signature when it rewrote:


From:  
Reply-To:  

to

From: 
Reply-To: 

(in case it's too hard to spot, changing two spaces to one between the 
":" and the "<")


Putting anything other than a single space between the header name and 
content is a form of malicious compliance...




This change breaks the original sender's c=simple/simple DKIM 
signature.


Yes, I'm sure it does.

Using simple/simple canonicalization is not for people who want robust 
DKIM signatures.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Authentication Bounces by Gmail

[Bill Cole via mailop]

On 2023-09-19 at 11:46:28 UTC-0400 (Tue, 19 Sep 2023 17:46:28 +0200)
Alessandro Vesely via mailop 
is rumored to have said:

Comparing the bounced message with the original, it turned out the 
angle brackets were removed from the From: address, which is legal 
since there was no display-name, but breaks signatures.  Still no idea 
how that happened.


Removing brackets on addresses without display names is one of the 
things that Sendmail (in some common configurations...) does.


(A few years ago I was tasked with eliminating the DKIM signature damage 
being done in a custom milter chain that ultimately went through 
Sendmail delivery to local accounts (mbox or Maildir) or relayed via 
SMTP to GApps/MS365. Ultimately it required about a year of in-prod 
testing and iteratively creating a routine that reproduced all of the 
odd little Sendmail canonicalization/normalization quirks ahead of 
signing.)



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Google - Messages with multiple addresses in From: header are not accepted.

[Bill Cole via mailop]

On 2023-09-18 at 10:53:16 UTC-0400 (Mon, 18 Sep 2023 09:53:16 -0500)
Scott Mutter via mailop 
is rumored to have said:


I'm not sure if a leading space in a message header is proper.


Nope.

Any leading whitespace in a header line indicates that it is logically 
part of the prior header. You're generating broken email.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Increase of SSL/TLS errors

[Bill Cole via mailop]

On 2023-09-12 at 02:18:56 UTC-0400 (Tue, 12 Sep 2023 08:18:56 +0200)
Camille - Clean Mailbox via mailop 
is rumored to have said:


Hi Bill,

└─# openssl s_client -connect mx.clean-mailbox.com:25 -starttls 
smtp

[...]
---
Certificate chain
 0 s:CN = clean-mailbox.com
   i:C = US, O = Let's Encrypt, CN = R3
   a:PKEY: id-ecPublicKey, 256 (bit); sigalg: RSA-SHA256
   v:NotBefore: Aug 30 21:56:24 2023 GMT; NotAfter: Nov 28 21:56:23 
2023 GMT

 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Sep  4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 
2025 GMT

 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3



   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jan 20 19:14:03 2021 GMT; NotAfter: Sep 30 18:14:03 
2024 GMT

---
[...]

I think my certificate chain is fine, no trace of DST.


See '^^^' above.
The DST X3 root cert expired. Your chain as deployed depends on it.

Your CA (LetsEncrypt) says that is breakage and they offer a fix. Take 
it or leave it, but saying that it isn't broken is wrong.





My configuration around certificates:
smtpd_tls_cert_file=/etc/letsencrypt/live/clean-mailbox.com/fullchain.pem
smtpd_tls_key_file=/etc/letsencrypt/live/clean-mailbox.com/privkey.pem

Also I think it's normal that the client doesn't like the answer of my 
servers if the client tries to initiate a SSLv3 connection, as I've 
disabled it in Postfix.


In this case, the client alert was very specific about your problem 
being a bad certificate. Read the error message.




Best regards,
Camille

Le 12/09/2023 à 00:26, Bill Cole via mailop a écrit :

On 2023-09-11 at 17:05:00 UTC-0400 (Mon, 11 Sep 2023 23:05:00 +0200)
Camille - Clean Mailbox via mailop 
is rumored to have said:


Dear co-listers,

I'm seeing an increase of SSL/TLS errors for incoming emails to our 
service over the last few weeks.


Example from Mailjet, which is (I suppose) able to send email in TLS 
1.2 or 1.3 instead of SSLv3:
2023-09-11T21:19:31.079142+02:00 mx4 postfix/smtpd[633448]: 
SSL_accept error from o176.p8.mailjet.com[87.253.233.176]: -1
2023-09-11T21:19:31.079696+02:00 mx4 postfix/smtpd[633448]: warning: 
TLS library problem: error:0A000412:SSL routines::sslv3 alert bad 
certificate:../ssl/record/rec_layer_s3.c:1586:SSL alert number 42:


That's an indication that the client does not like your certificate.

As for why, see 
https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/


TL;DR: you need to fix the chain of trust for your certificate. You 
should remove any reference to the 'DST Root CA X3' certificate. You 
may also need to change how you maintain your certificate.





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



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Increase of SSL/TLS errors

[Bill Cole via mailop]

On 2023-09-11 at 17:05:00 UTC-0400 (Mon, 11 Sep 2023 23:05:00 +0200)
Camille - Clean Mailbox via mailop 
is rumored to have said:


Dear co-listers,

I'm seeing an increase of SSL/TLS errors for incoming emails to our 
service over the last few weeks.


Example from Mailjet, which is (I suppose) able to send email in TLS 
1.2 or 1.3 instead of SSLv3:
2023-09-11T21:19:31.079142+02:00 mx4 postfix/smtpd[633448]: SSL_accept 
error from o176.p8.mailjet.com[87.253.233.176]: -1
2023-09-11T21:19:31.079696+02:00 mx4 postfix/smtpd[633448]: warning: 
TLS library problem: error:0A000412:SSL routines::sslv3 alert bad 
certificate:../ssl/record/rec_layer_s3.c:1586:SSL alert number 42:


That's an indication that the client does not like your certificate.

As for why, see 
https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/


TL;DR: you need to fix the chain of trust for your certificate. You 
should remove any reference to the 'DST Root CA X3' certificate. You may 
also need to change how you maintain your certificate.




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] New Validity policy for paid FBL (ARF)

[Bill Cole via mailop]

On 2023-09-11 at 07:24:55 UTC-0400 (Mon, 11 Sep 2023 13:24:55 +0200)
Support 3Hound via mailop 
is rumored to have said:


Dear list,
I would like to understand what the community think about the new 
Validity universal feedback loop service that is switching to a paid 
service starting 21 September 2023.


We (SMB mailbox outsourcer/MSP/bespoke hoster) Are only subscribed to 
FBLs because we need to know if spam starts coming from our network. As 
we are not in the business of helping anyone send spam, ever, of any 
sort, we have never received anything useful from any FBL. The events 
where our clients have tried to send spam ignorantly or have had 
machines compromised to send spam have not managed to generate any FBL 
reports.


So, no, there's not even the slightest chance that my primary employer 
will pay Validity for anything. They've never been valuable for us 
before, why expect them to start now?


As Validity worked in the the last years to achieve the management of 
the FBL service from all the "main" country-level and international 
mailbox providers (as the "universal" word suggest), I think that this 
new policy is unfair and a very bad news for the mail operators 
community.


It must suck for ESPs, especially ones with shoddy list hygiene. It 
would certainly hurt to have to pay for the privilege of shrinking 
lists.


During years the FBL became a kind of "safe feature" for users that 
prefer to click "junk" or "spam" and be sure they will not receive 
anymore.


As if that ever worked, from the recipient's POV.

As I understand it, Validity is a for-profit corporation whose purpose 
is to return value to its investors commensurate with  their invested 
capital. They don't owe anyone any FBL. If you want their service, they 
will extract value from you one way or another to get it.


I should probably add that I would be entirely willing to experience an 
Internet without B2C ESPs. It's nothing personal, it's just that I've 
never been convinced that their existence isn't an attractive nuisance.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] hotmail.com SPF forgot IPv6

[Bill Cole via mailop]

On 2023-08-21 at 16:33:07 UTC-0400 (21 Aug 2023 16:33:07 -0400)
John Levine via mailop 
is rumored to have said:

It appears that Gellner, Oliver via mailop  
said:



On 19.08.2023 at 19:01 Jarland Donnell via mailop wrote:

Is "-all" not indeed a policy in SPF, directed by the domain 
owner? I would argue that it is. Especially given that there are 
options there, each one defining how the domain
owner wishes SPF failure to be treated. I would find it odd to say 
that should ignore domain owners when they say "-all" since that's a 
direct and clear request by them.


SPF contains information about which IP addresses are authorized or 
unauthorized to send messages for a given domain. It does not contain 
a policy on what to do with this information.


What's the difference among -all ~all ?all if it's not policy?


There's a semantic disconnect here around the word "policy"

The default attribute does not advise anyone what to do, it simply 
expresses a vague judgment by the domain owner of how complete & 
reliable the SPF record is.


(I'm not saying one should pay a lot of attention to the policy, but 
it's a policy.)


It's policy-esque. Policy-adjacent.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] AOL/Yahoo requiring SOA record for MAIL FROM domain name?

[Bill Cole via mailop]

On 2023-07-13 at 12:06:45 UTC-0400 (Thu, 13 Jul 2023 11:06:45 -0500)
Grant Taylor via mailop 
is rumored to have said:


On 7/13/23 10:49 AM, Bill Cole via mailop wrote:
It's not at all logically hard to meet that arbitrary requirement, 
you just need a zone cut everywhere you have a MX record. I've run a 
DNS and mail hosting environment that way. Zone files are very small 
and numerous. *Logistically* changing an existing zone with many MXs 
for subdomains to that model could be a  serious chore.


I question the veracity of "need a zone cut everywhere you have an MX 
record".


My current working understanding is "you need a zone cut for domains 
immediately subordinate of the PSL".


Right. I was speaking more directly to the OP's situation where they 
already have a big zone rooted at a PSL-listed domain and a lot of 
subdomains.




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: AOL/Yahoo requiring SOA record for MAIL FROM domain name?

[Bill Cole via mailop]

On 2023-07-13 at 10:15:27 UTC-0400 (Thu, 13 Jul 2023 07:15:27 -0700)
Marcel Becker via mailop 
is rumored to have said:




No. I might as well reveal the actual domain names involved, since 
it's

not particularly secret: it's "westfir.or.us" and "ci.westfir.or.us".


It's actually not that complicated. We want to see an SOA record for 
either

the domain OR the organizational domain.

We use the PSL to determine the organizational domain.


It is worth noting that this is in no way a "standard" or even a 
widely-known "best practice" and that it was entirely the invention of 
the Big Brains at Yahoo, the place that helped give us the ridiculous 
fragility of DKIM...




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] AOL/Yahoo requiring SOA record for MAIL FROM domain name?

[Bill Cole via mailop]

On 2023-07-12 at 18:38:05 UTC-0400 (Wed, 12 Jul 2023 15:38:05 -0700)
Robert L Mathews via mailop 
is rumored to have said:

Today I had a customer complain that mail they send to AOL or Yahoo 
addresses was being returned with:


451 Message temporarily deferred due to unresolvable RFC.5321 from 
domain; see https://postmaster.yahooinc.com/error-codes


According to that page,

"- These errors indicate that the domain used to the right of the @ in 
the MAIL FROM does not appear to be a real domain.
- We determine if the domain name exists by using an SOA query; 
therefore, if multiple subdomains are used in MAIL FROM commands, then 
besides setting up a DNS A or MX record (perhaps using a wildcard), 
then SOA records must be set up as well."


This is surprising!



It's also not the whole story.

Yahoo does not reject mail from valid addresses in subdomains of 
scconsult.com which have MX or A records but no SOA or NS records.


I have done absolutely nothing to achieve that. I only know it to be 
true because someone mentioned this issue on some mailing list a few 
weeks ago and I tested myself.


Supposedly, Yahoo is basing this on the PSL, only requiring domains at 
registry boundaries to have SOAs. This much more subtle than but just as 
stupid as what their error page says.


It's not at all logically hard to meet that arbitrary requirement, you 
just need a zone cut everywhere you have a MX record. I've run a DNS and 
mail hosting environment that way. Zone files are very small and 
numerous. *Logistically* changing an existing zone with many MXs for 
subdomains to that model could be a  serious chore.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Guide for setting up a mail server ?

[Bill Cole via mailop]

On 2023-07-12 at 18:53:31 UTC-0400 (Wed, 12 Jul 2023 15:53:31 -0700)
Michael Peddemors via mailop 
is rumored to have said:


On 2023-07-12 12:53, Jaroslaw Rafa via mailop wrote:
Most of regular consumer email users don't have any reason for this. 
As Bill
Cole, whom I was replying to, wrote - nobody would try to impersonate 
you or
me in a phishing campaign for financial gain, because there won't be 
any.


hehehe.. they do it all the time.. It's your contacts that will fall 
for it, and it will probably be to place a trojan.. and clean out 
THEIR data, and banking information..


I've been having waves of both random and targeted email forgeries for 
25+ years. I've had my personal mailserver knocked offline by the 
bounces of a spam run that used entirely invented scconsult.com 
addresses. The price of using Usenet for over a decade with a real email 
address.


I've never had a personal or professional contact tell me that they've 
received mail forged to appear to be from me. Not using my personal nor 
professional email addresses. I have no secondary evidence of that 
either. Maybe that's because all of my contacts know that I don't send 
anyone random message or anything in HTML so they just ignore it, but I 
doubt that. It just does not happen. I don't believe that I am special.


I am not saying that random people don't hit the bad luck lottery like 
this every day, just that most people will never have it happen to them 
while some people will see a lot of it.




Trust me, fought the whole SPF for a long while, it was 1/2 baked.. 
but when a bank or a large instition publicizes a clean SPF record.. 
honour it.. they will be forged more..


Yes. That's what SPF is good for: protecting senders of high-value mail 
from forgery.


I don't ignore SPF/DKIM/DMARC entirely, but they are very low-value 
tests in differentiating between legitimate and illegitimate email 
relative to their processing cost. They only provide usable in formation 
for those domains that one already is familiar with.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Guide for setting up a mail server ?

[Bill Cole via mailop]

On 2023-07-12 at 05:46:47 UTC-0400 (Wed, 12 Jul 2023 11:46:47 +0200)
Jaroslaw Rafa via mailop 
is rumored to have said:

Exactly, because from my experience SPF, DKIM and DMARC bring very 
little

(if anything at all) to security. I


TRUTH.

For the overwhelming majority of sending systems, the only internal 
security benefit to implementing SPF/DKIM/DMARC is to make impersonation 
of local users by outsiders for the purpose of fraud (so-called "BEC") 
much harder.


For most sending domains, targeted forgery to the world at large is a 
non-problem. No one is out there impersonating you or me in email to 
random strangers for financial gain. Most businesses do not have 
widespread 'brand value' that can be stolen by random broadcast forgery. 
Mechanisms for general public authentication of email from strangers 
exist for the primary benefit of big senders, their customers, and their 
prospective customers who need to know that their spam is authentic.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Guide for setting up a mail server ?

[Bill Cole via mailop]

On 2023-07-11 at 20:58:19 UTC-0400 (11 Jul 2023 20:58:19 -0400)
John Levine via mailop 
is rumored to have said:

It appears that Grant Taylor via mailop  
said:

On 7/11/23 2:48 PM, John Levine via mailop wrote:

If your From: domain has neither an A nor an MX, I don't think
you're going to get much mail of any sort delivered.

I believe it's possible for two entities to configure their email
servers to exchange email with each other without the use of DNS.


Well, sure, you can do anything by private arrangement.

But if you want to exchance mail with other mail servers over the
public Internet, an A will do but you really want an MX.


Primarily because if you don't, it may confuse and distract people who 
should know better, and generate LONG mailing list threads.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SPF +all considered harmful

[Bill Cole via mailop]

On 2023-07-11 at 13:49:32 UTC-0400 (Tue, 11 Jul 2023 19:49:32 +0200)
Benny Pedersen via mailop 
is rumored to have said:

> Bill Cole via mailop skrev den 2023-07-11 19:01:
>> On 2023-07-11 at 11:08:23 UTC-0400 (Tue, 11 Jul 2023 17:08:23 +0200)
>> Benny Pedersen via mailop 
>> is rumored to have said:
>>
>>> direct to mx will have spf pass without +all, on next hub envelope sender 
>>> changes, so new spf problem when next hub forwards mails,
>>
>> You keep repeating this (and equivalent statements) as if it is true.
>>
>> ***IT IS FALSE***
>>
>> Unless a MTA implements something like SRS specifically to accommodate
>> SPF, the envelope sender a mail arrives with is the same one it is
>> relayed with, if it is being forwarded by the traditional "aliases"
>> and ".forward" mechanisms of Sendmail and Postfix. This practice,
>> *without SRS*, is still the most widespread form of forwarding
>> individual addresses to other individual addresses.
>
> i keep what postfix does, not what any other forwarding service does, its 
> false aswell to not know how postfix works, period

If that were anything close to grammatically correct I might understand it.

Postfix does not modify the envelope sender when using aliases or .forward 
files to forward mail.
>
> https://mx.junc.eu/dmarc/junc.eu/all.txt prove my incorrect now ?

I am not about to review whatever that flood of text means, and it appears to 
be likely not evidence of anything...

> if you are right i would see more spf pass

Non sequitur. If your assumptions are incorrect, as they clearly are, I doubt 
that your data analysis and logic are sound.

Go ahead, sniff the packets or make the MTA log everything. Prove me wrong.

-- 
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SPF +all considered harmful

[Bill Cole via mailop]

On 2023-07-11 at 11:08:23 UTC-0400 (Tue, 11 Jul 2023 17:08:23 +0200)
Benny Pedersen via mailop 
is rumored to have said:

> direct to mx will have spf pass without +all, on next hub envelope sender 
> changes, so new spf problem when next hub forwards mails,

You keep repeating this (and equivalent statements) as if it is true.

***IT IS FALSE***

Unless a MTA implements something like SRS specifically to accommodate SPF, the 
envelope sender a mail arrives with is the same one it is relayed with, if it 
is being forwarded by the traditional "aliases" and ".forward" mechanisms of 
Sendmail and Postfix. This practice, *without SRS*, is still the most 
widespread form of forwarding individual addresses to other individual 
addresses.


-- 
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Guide for setting up a mail server ?

[Bill Cole via mailop]

On 2023-07-11 at 06:28:47 UTC-0400 (Tue, 11 Jul 2023 12:28:47 +0200)
Jaroslaw Rafa via mailop 
is rumored to have said:

And if mail *is* E2E encrypted, transport level encryption is 
basically

redundant...


Not really.

It is worthwhile to protect the details of a SMTP session on the wire, 
beyond simply protecting the contents of email.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Guide for setting up a mail server ?

[Bill Cole via mailop]

On 2023-07-11 at 05:26:25 UTC-0400 (Tue, 11 Jul 2023 11:26:25 +0200)
Jaroslaw Rafa via mailop 
is rumored to have said:

These are Google requirements, not SMTP protocol requirements. We 
should not

confuse one with the other.


Right, and that may be why Laura specifically referred to B2B mail.

Hobbyists can live with not delivering to GMail or MS, companies that 
need to work with other businesses via email cannot.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Guide for setting up a mail server ?

[Bill Cole via mailop]

On 2023-07-11 at 04:05:42 UTC-0400 (Tue, 11 Jul 2023 09:05:42 +0100)
Laura Atkins via mailop 
is rumored to have said:

B2B email requires a MX (like, if you don’t have an MX do you even 
email?)


Surprisingly, A-record fallback works just fine for B2B email. No one 
notices. Or at least no one appears to reject mail solely for that 
reason and inbound mail works perfectly.  It is, after all, the way 
email was originally designed to work.


However, I admit my evidence for that is ~2y old. I wouldn't 
*intentionally* allow an actively mailing domain to rely on A 
fallback...



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Cannot talk to Sharedband

[Bill Cole via mailop]

On 2023-06-24 at 05:49:30 UTC-0400 (Sat, 24 Jun 2023 11:49:30 +0200)
Alessandro Vesely via mailop 
is rumored to have said:


I had a bounce:

Reporting-MTA: dns;PR3PR05MB7547.eurprd05.prod.outlook.com
Received-From-MTA: dns;wmail.tana.it
Arrival-Date: Sat, 24 Jun 2023 03:03:07 +

Original-Recipient: rfc822;redac...@sharedband.com
Final-Recipient: rfc822;redac...@sharedband.com
Action: failed
Status: 5.7.520
Diagnostic-Code: smtp;550 5.7.520 Access denied, Your organization 
does not allow external forwarding. Please contact your administrator 
for further assistance. AS(7555)



I'm using 94.198.96.72/29 since April, and I'm trying to remove IP 
blocks as I find them.


That's not clearly an IP-based block. It looks like that is a 
consequence of tana.it having -all in its SPF record. That is explicitly 
a prohibition on forwarding, whether the SPF specs say so or not. It is 
certainly comprehensible that a mail system which does a lot of 
forwarding does not want to handle your unforwardable mail.




Since they block my server,


Not your server, your sender domain.


I wrote them from Gmail.  Surprise:


Reporting-MTA: dns; googlemail.com
Arrival-Date: Sat, 24 Jun 2023 02:35:23 -0700 (PDT)
X-Original-Message-ID: 



Final-Recipient: rfc822; postmas...@sharedband.com
Action: failed
Status: 5.4.1
Remote-MTA: dns; sharedband-com.mail.protection.outlook.com. 
(104.47.2.36, the

 server for the domain sharedband.com.)
Diagnostic-Code: smtp; 550 5.4.1 Recipient address rejected: Access 
denied. AS(201806281) 
[DB5EUR01FT100.eop-EUR01.prod.protection.outlook.com 
2023-06-24T09:36:26.242Z 08DB746591C0DBB7]

Last-Attempt-Date: Sat, 24 Jun 2023 02:36:26 -0700 (PDT)


How was that joke about TBTB?



Again, this does not look like a rejection due to the SMTP client 
machine's network circumstances. IOW: I don't think it's a case of MS 
blocking Google or any Google network per se.


But that's just a hunch...

--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] greylisting, SendGrid is deleting your mail

[Bill Cole via mailop]

On 2023-06-24 at 00:49:46 UTC-0400 (24 Jun 2023 00:49:46 -0400)
John Levine via mailop 
is rumored to have said:


It appears that Al Iverson via mailop  said:

What if we just got to the heart of the matter and admitted that
greylisting is useless 2023?


Because it's still quite useful if you do it sensibly.  Here's what my
logs say for the past two years, by number of IPs

 greylist but never retried: 13573
 greylist and did retry: 9299

 whitelisted or previously retried: 6519

More than half of the addresses I greylist never retry, and spot
checks of the logs show that's overwhelmingly bots.


Do you have any idea how many of those would be tripped up by a 
Postfix-style banner delay?




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SendGrid is deleting your mail

[Bill Cole via mailop]

On 2023-06-24 at 00:13:56 UTC-0400 (Fri, 23 Jun 2023 23:13:56 -0500)
Al Iverson via mailop 
is rumored to have said:


What if we just got to the heart of the matter and admitted that
greylisting is useless 2023?


+1

It was always a cute trick that just happened to mostly work but unlike 
harmless cute tricks like banner weirdness, it is intentional shotgun 
breakage that requires constant tuning.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SendGrid is deleting your mail

[Bill Cole via mailop]

[NOTE: There's absolutely never any need to CC me individually when 
posting to this or any other list I'm on. Or not on.]


On 2023-06-23 at 12:46:58 UTC-0400 (Fri, 23 Jun 2023 09:46:58 -0700)
Luke via mailop 
is rumored to have said:

That's right, Bill. It's so simple. All the ESPs and MTAs out there 
have

tools built in to create and customize response handling rules for
absolutely no reason.


In 30 years of administering mail systems, including a wide variety of 
MTAs and a couple of MLMs, I've never found it useful to significantly 
modify the basic error codes or qualitatively vary reactions to them. 
Not sure how I'd even do that in Postfix, I'm pretty sure it would 
require hacking the code in ways that it is not designed for.  Yes, it's 
easy to just never retry any 4xx, no, you can't adjust reaction to a 4xx 
code based on the text part or retry after a 5xx.



We actually just do it for fun. We know that every
single 4xx should be retried and every single 5xx should not be 
retried.
But we thought it would be neat to have a table with hundreds of 
custom

rules just to make it sound more complicated than it is.


Sounds wild, but people do crazy stuff based on unsupportable hunches 
unencumbered by real data, particularly when it involves the mixing of 
computer and human behaviors. It would hardly be novel for an ESP to 
engage in self-deception about what they need to be the essentially 
arcane and complex lore of how to send bulk email.


I've seen a few robust attempts to comprehensively violate the rules on 
not interpreting the text part of SMTP replies which, under careful 
analysis, were on-balance net negatives. The very meager discernible 
benefits could never justify the concrete cost of building and 
maintaining a system of dozens or hundreds of custom rules. Maybe you do 
it differently or better, but I'm a skeptic.


So, you're right, it's just because we are big and we don't think the 
rules

apply to us. Super productive take you have there.


If I ever thought that I was being 'productive' for Twilio I would bill 
for it.



I can tell you've really
given this some thought.


More than you can imagine...

Nothing in the past 25 years has persuaded me that the "ESP" industry is 
anything but parasitic and harmful, as it is built on fundamental 
falsehoods. Your sneering is neither original, surprising, nor 
persuasive. It is clear that you believe you are exempt from the basic 
rules of SMTP interoperability and I've seen that before, often. My 
assertion of *why* you believe that is of course just a guess, but in my 
experience it has always boiled down to scale and a refusal to accept 
some fundamental truths of email. If you have evidence that it is 
actually worthwhile for you, you could just say that. My experience 
includes evidence that it is not. Maybe that has changed in 2023, but I 
doubt it.




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SendGrid is deleting your mail

[Bill Cole via mailop]

On 2023-06-22 at 19:14:15 UTC-0400 (Thu, 22 Jun 2023 16:14:15 -0700)
Luke via mailop 
is rumored to have said:


Unfortunately we cant make a rule that retries all 4xx and doesn't 
retry
all 5xx. Despite very smart, well intended people writing RFCs and 
other

specs that make this feel super clean cut in an acedemic or lab
environment, it's just not how it works in the wild.


And yet somehow it is how the overwhelming majority of mail systems have 
dealt with SMTP reply codes, for decades, successfully.


SendGrid's deliverability problems are precisely because you and your 
coworkers think that you are so big that the rules can't apply to you. 
That you are somehow different and special.


You are wrong. You're nothing special. You're just big. Get over 
yourselves.




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [EXTERNAL] Re: Strange mail delivery from microsoft

[Bill Cole via mailop]

On 2023-06-20 at 02:45:04 UTC-0400 (Tue, 20 Jun 2023 07:45:04 +0100)
Klaus Ethgen via mailop 
is rumored to have said:


Am Mo den 19. Jun 2023 um 21:55 schrieb Michael Wise via mailop:
If you're using GreyListing, know that a given email will not be 
coming from the same IP address twice.


The outgoing IP address is randomized for ... reasons.


I substitute "no".

That is absolutely ignorant to tell the people that you do mail in a
broken way and tell them it is for a reason, you don't want to tell.


Sharing an outbound queue amongst many different machines is not 
"broken" in any way. There may or may not be rock-solid simple 
explanations for *WHY* that approach was chosen, but it is entirely a 
local issue of purely local concern. There is no RFC asserting that 
retries after a transient rejection should come from the same cliuent 
IP.


Greylisting, in contrast, is designed as breakage. It is breakage that 
is handled well by the most common behaviors of small to medium sized 
sending systems, but those behaviors are purely a matter of convenience. 
Greylisting is an intrinsically heuristic practice, because you need to 
adapt it to what works rather than having some standard spec that you 
can count on interoperating.



On the same time being one of the biggest spam provider.


Which is a direct consequence of what they've done to become the biggest 
commercial mailbox provider.


Microsoft has no history of doing what non-paying non-customers think 
they should do, especially if it possible for them to perceive such 
deadbeats to be competitors. If you run a mail server, Microsoft will at 
some point treat you as a competitor rather than as a partner. Do not 
expect anything else.




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Port 25 Pingback?

[Bill Cole via mailop]

On 2023-06-16 at 13:37:19 UTC-0400 (Fri, 16 Jun 2023 13:37:19 -0400)
John Possidente via mailop 
is rumored to have said:

> A sender of legally mandated bulk mail who are very conscious of making
> sure they're dotting every i and crossing every t (because they're required
> to) asked me today whether port 25 pingback is still necessary. I
> immediately thought, "Of course not," but on second thought (before
> speaking, yay) realized that maybe I'm wrong.
>
> Does anyplace still reject mail from sources that don't answer on port 25?

Do you mean this literally in a technical sense, i.e. that the SMTP client IP 
must accept a port 25 connection back to it? I'm not aware of that EVER being a 
usable tactic that would be worth adapting to. Those people do not want their 
mail.

In the logical sense of "does the domain part of the SMTP sender address have 
appropriate A//MX records in DNS that could make a bounce feasible?" there 
are very many places enforcing that, as they should. If the envelope sender 
address is not even theoretically mailable (i.e. hard app-layerfailure from 
DNS) one can expect the mail to be rejected or in some cases intentionally 
blackholed after acceptance.

In between would be full SMTP callback verification, testing whether the sender 
will accept mail from '<>' in real time, synchronously with the original offer 
of mail. This has been MOSTLY abandoned because it predictably results in false 
positives and has become increasingly risky to the checker's reputation and 
error-prone over the years. A "legally mandated" sender should probably expect 
some of that to still be in use, because the long tail of mail admin 
incompetence is a thing...

-- 
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DMARC check case sensitive domains

[Bill Cole via mailop]

On 2023-06-13 at 12:40:57 UTC-0400 (Tue, 13 Jun 2023 18:40:57 +0200)
Sander Smeenk via mailop 
is rumored to have said:


The header from address doesn't matter. So long as the domain used in
the envelope sender is capitalized it fails DMARC check.

This still perplexes me a bit.
The mail tested OK at mail-tester.com with the envelope from address
lowercased.


As one self-appointed victim* of their chronic incompetence, I feel 
compelled to beg you: don't waste your time trying to figure out what 
mail-tester.com is doing wrong.



*: SpamAssassin committer/PMC member

--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DMARC check case sensitive domains

[Bill Cole via mailop]

On 2023-06-13 at 08:03:20 UTC-0400 (Tue, 13 Jun 2023 14:03:20 +0200)
Sander Smeenk via mailop 
is rumored to have said:


Hi list,

Long time lurker here. Ran into an issue where one of my customers is
sending mail with the sender- and header-from domain capitalized:
foou...@example.tld.
This seems to break DMARC checks on certain receivers.

The domain has all the bells and whistles, SPF, DKIM, DMARC...

Everything is looking good, but (at least) the Proofpoint (UK)
mailservers reject messages sent by this user stating "5.7.0 Local
Policy Violation - DMARC Permerror".

The sender domain DMARC record has 'p=none', for what it's worth.

I've been playing around a bit and found out that the Proofpoint DMARC
validator, as well as the one used at mail-tester.com fwiw, choke on 
the

capitalization of the Return-Path / Envelope Sender address.

Mail-tester.com states "The DMARC test failed but we didn't find any
obvious reason why."

The header from address doesn't matter. So long as the domain used in
the envelope sender is capitalized it fails DMARC check.


That's odd, since DMARC *always* validates the From header domain with 
either the DKIM signature or SPF, and the envelope sender domain is only 
relevant to SPF.


I always thought e-mail addresses weren't supposed to be case 
sensitive.


That's complicated, but the domain parts absolutely must be compared in 
a case-insensitive manner. There's an obscure reason that actively 
case-squashing domains might not be a great idea.


Local parts can in theory be case-sensitive but if you rely on that 
being honored on mail that transits the Internet you will be 
disappointed.



Am i hitting a weird bug here? Have others seen this behaviour?


Haven't noticed it, haven't looked for it. It does not sound unlikely to 
me, but I am a cynic.



Tests
with my Exim MTA show it passing no matter what capitalization is 
used.

My Exim is compiled against libopendmarc2 1.3.2.

I'm currently rewriting the return path of all emails to lower case in
hopes of working around this thing.


You must do what you must do, your server=your rules, but I can only 
say: "EWWW!"



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Noticed Google now suggests changing envelope sender for forwarding

[Bill Cole via mailop]

On 2023-06-01 at 13:58:22 UTC-0400 (Thu, 01 Jun 2023 19:58:22 +0200)
Benny Pedersen via mailop 
is rumored to have said:

> default in all mta, at least postfix is to use new envelope sender so spf 
> works from new sender domain, why not keep it simple ?

That is simply FALSE.


Sendmail and Postfix DO NOT change the envelope sender for mail forwarded via 
alias or .forward mechanisms. That's the whole reason SRS tools exist.

-- 
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] push and pull, Microsoft Office365 not rejecting emails when instructed so by SPF recored?

[Bill Cole via mailop]

On 2023-05-30 at 21:47:55 UTC-0400 (30 May 2023 21:47:55 -0400)
John R Levine via mailop 
is rumored to have said:
[.]
I am fairly sure that in the U.S. there is generally no obligation on 
the bank to prove that a customer has seen a statement.


Right. And financial institutions handle whatever legal issues they 
might have with liability for uncertain electronic delivery by having 
customers 'agree' to click-thru terms specifically for electronic 
delivery. It's never something they do by default.




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] UCEPROTECT L2 fact

[Bill Cole via mailop]

On 2023-05-22 at 16:03:32 UTC-0400 (Mon, 22 May 2023 21:03:32 +0100)
John Devine via mailop 
is rumored to have said:

Hmmm I started using dnsbl-3.uceprotect.net 
 a few months ago, should I desist?


Only if you want to receive all of your legitimate mail.

If you would prefer to randomly reject legitimate messages from people 
who will have no idea why and no way to fix the problem, you're good to 
go.




JD

On 22 May 2023, at 17:01, Jarland Donnell via mailop 
 wrote:


I have not personally run into anyone using L3 or L2 in my 
experiences thus far. Their L1 list is what most, if anyone, would be 
subscribing to I would think. Their L1 list is actually really, 
really good.




On 2023-05-14 05:47, Slavko via mailop wrote:


Hi,

i read multiple times, from multiple sources about UCEPROTECT
BL, how it is suspicious, etc...

Recently i got notification from ShadowServer, that i am on
blacklist, in particular on UCEPROTECT-L2 BL, which AFAIK
blocks whole networks as anounced by ASN. Thus i was curious,
what happens around me.

Today UCEPROTECT reports 32 incidents for /22 net. We can
discuss if 32 is enough for blocking whole network block or
not, but OK -- 32 incidents is over their policy... But all these
32 incidents was generated by 1 (one) IP! In other words,
one IP is enough for UCEPROTECT to block whole /22 network.

Now i really can know how wrong is this BL (and no, i never
used it, i even removed it from my check script)...

I am not very interested in that list, nor in how bad that RBL
is, but i am curious: is someone (bigger than personal) using
it? Or do you know someone who is using it? What is/can be
the reason to use it?

thanks


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



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



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] UCEPROTECT L2 fact

[Bill Cole via mailop]

On 2023-05-22 at 12:01:52 UTC-0400 (Mon, 22 May 2023 11:01:52 -0500)
Jarland Donnell via mailop 
is rumored to have said:

I have not personally run into anyone using L3 or L2 in my experiences 
thus far. Their L1 list is what most, if anyone, would be subscribing 
to I would think. Their L1 list is actually really, really good.


Do you have any hard numbers on this? E.g. on marginal improvement it 
provides?


My checking of it is very limited, as I only check what makes it to my 
eyeballs,  which is not influenced by UCEPROTECT. So when I check an IP, 
it's because multiple more trustworthy DNSBLs, SpamAssassin, and my own 
bespoke tactics have failed to identify spam. I see almost no matches.




On 2023-05-14 05:47, Slavko via mailop wrote:


Hi,

i read multiple times, from multiple sources about UCEPROTECT
BL, how it is suspicious, etc...

Recently i got notification from ShadowServer, that i am on
blacklist, in particular on UCEPROTECT-L2 BL, which AFAIK
blocks whole networks as anounced by ASN. Thus i was curious,
what happens around me.

Today UCEPROTECT reports 32 incidents for /22 net. We can
discuss if 32 is enough for blocking whole network block or
not, but OK -- 32 incidents is over their policy... But all these
32 incidents was generated by 1 (one) IP! In other words,
one IP is enough for UCEPROTECT to block whole /22 network.

Now i really can know how wrong is this BL (and no, i never
used it, i even removed it from my check script)...

I am not very interested in that list, nor in how bad that RBL
is, but i am curious: is someone (bigger than personal) using
it? Or do you know someone who is using it? What is/can be
the reason to use it?

thanks



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



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Massive botnet going off today?

[Bill Cole via mailop]

On 2023-05-15 at 13:31:47 UTC-0400 (Mon, 15 May 2023 17:31:47 +)
Slavko via mailop 
is rumored to have said:

Dňa 15. mája 2023 15:42:14 UTC používateľ "Taavi Eomäe via 
mailop"  napísal:
Here's a complete list of the IPs we've seen exhibit behavior 
specific to this botnet. If anyone's interested.


Don't worry, you are not alone, ~3000 of them is already in my
MSA's firewall due AUTH attempts.


This explains why I didn't see it: I have a passel of handcrafted tools 
looking at honeypot traffic with escalations to blocking  by route 
prefix... Most of these IPs are in ranges where I've seen suspect 
traffic from many sources recently and deemed them generally disposable. 
e.g. I'll likely never have a legit packet from any random nameless 
ChinaNet IP, so why waste TCP on any of them?


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Massive botnet going off today?

[Bill Cole via mailop]

On 2023-05-13 at 15:09:50 UTC-0400 (Sat, 13 May 2023 14:09:50 -0500)
Jarland Donnell via mailop 
is rumored to have said:


Curious if anyone else is seeing an event similar to this.


Inbound SMTP traffic is the median of the past 5 Saturdays through 20:00 
UTC on the largest system I wrangle. So: nope.



Here's the logs of 1 hour on one of our servers, for what I propose to 
be a botnet: https://clbin.com/4khRA


I'm leaving the recipient domains in it because they're not actually 
customer domains. Either they used to be, or they've had their MX 
pointed to us maliciously. I can't accurately say at the moment. 
Whatever is happening in these logs, it looks fairly consistent, and 
quite distributed. What I can't figure out yet, and I'm hoping 
responses or lack thereof from others will shed light on, is whether 
or not this is a targeted attack against our infrastructure or simply 
a large scale event that we're all seeing.



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



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Thoughts on envelope address local-part length limits

[Bill Cole via mailop]

On 2023-05-12 at 16:52:38 UTC-0400 (Fri, 12 May 2023 13:52:38 -0700)
Brandon Long via mailop 
is rumored to have said:

On Fri, May 12, 2023 at 8:54 AM Bill Cole via mailop 


wrote:


On 2023-05-12 at 09:40:14 UTC-0400 (Fri, 12 May 2023 13:40:14 +)
Paul Gregg via mailop 
is rumored to have said:


I suspect with verp/bounce addressing widely in use now, 64 octets
just
isn't enough these days.


Hogwash. 64 mail-safe octets is adequate for every domain to give a
unique printable(!) deliverable local-part to every elementary 
particle

in the universe. It's a namespace adequate for ANYTHING



And yet IP6 went with 128 for some reason...


Are you conflating bits with mail-safe octets (~6 bits each)? There are 
about 400 bits of information available in the 512-bit container of a 
64-character local-part.


Each domain has a namespace for sender local parts that is 3 times as 
large (bitwise) as the whole human race has for IPv6 addresses.



as if there are other concerns
than being able to compress
the information into as few bits as possible.


No need to programmatically compress data to use the space efficiently, 
just be good at naming.




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Thoughts on envelope address local-part length limits

[Bill Cole via mailop]

On 2023-05-12 at 09:40:14 UTC-0400 (Fri, 12 May 2023 13:40:14 +)
Paul Gregg via mailop 
is rumored to have said:

I suspect with verp/bounce addressing widely in use now, 64 octets 
just

isn't enough these days.


Hogwash. 64 mail-safe octets is adequate for every domain to give a 
unique printable(!) deliverable local-part to every elementary particle 
in the universe. It's a namespace adequate for ANYTHING


Bulk mailers are just lazy and their median cluefullness is remarkably 
low.


So, my question(s) to mailop - Is the 'local-part' definition no 
longer

fit for purpose? Has that horse already bolted?


It's fine. The bozos ignoring it will have the low-grade background of 
corner-case failures they richly deserve. Competitive pressures on  
basic technical competence issues are GOOD.



Do you impose any limit


Yes.


and if so, what?


It varies. This is one of those cases where obscurity is good. I will 
say that anyone using longer envelope senders knows (OR SHOULD KNOW) 
that they are evading bounces. By operating outside of the formal rules, 
they invite hostile reactions outside of the formal rules.


Senders should not construct local-parts longer than 63 characters for 
use in SMTP. The fact that it often works at some sites should not be 
taken as evidence that it can or should work everywhere all the time. 
OTOH, what you do in headers is mostly your own business, except when it 
starts to correlate to spamminess. Of course, if you want replies to 
work, you won't put out-of-spec addresses where they might be replied 
to.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] United Airlines / mileageplus DNS/rDNS mismatch issue

[Bill Cole via mailop]

On 2023-05-09 at 16:17:57 UTC-0400 (Tue, 9 May 2023 20:17:57 +)
Gellner, Oliver via mailop 
is rumored to have said:

I’d be surprised if there are many members on this list whose 
systems do not penalize connections from IP addresses without a fully 
confirmed reverse DNS entry one way or the other. Maybe I‘m wrong, 
but then I‘d like to hear from them.


I do not penalize such connections, in part because the systems I manage 
are hypersensitive to rejecting MS365 mail.


Also because it isn't useful. It IS useful to reject clients with no PTR 
and to match some name patterns in PTR results that are "generic."



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] AT has eliminated their DNSBL team?

[Bill Cole via mailop]

Just to close this loop:

I resent my report this evening and got an autoreply as normal, so I 
guess AT hasn't gone Twitter on us...



On 2023-05-06 at 16:53:58 UTC-0400 (Sat, 06 May 2023 16:53:58 -0400)
Bill Cole via mailop 
is rumored to have said:

For unknown reasons, I got one of these tossed at me by a customer who 
inexplicably wants to send mail to an @att.net address


Action: failed
Status: 5.3.0
Remote-MTA: dns; al-ip4-mx-vip1.prodigy.net
	Diagnostic-Code: smtp; 553 5.3.0 alph774 DNSBL:RBL 521< 
74.115.114.190
	_is_blocked.For assistance forward this error to 
abuse_...@abuse-att.net


Having seen those a half-dozen times in as many years, I pulled up my 
last removal request, replaced the different bits, and sent it off to 
the address specified by AT in their error message: 
abuse_...@abuse-att.net


A few seconds later, I get this gem:

The original message was received at Sat, 6 May 2023 16:04:31 -0400
from m0288871.ppops.net [127.0.0.1]

   - The following addresses had permanent fatal errors -

	(reason: 550 5.1.1 : Recipient address 
rejected: User unknown in local recipient table)


   - Transcript of session follows -
... while talking to [144.160.237.58]:
>>> DATA
	<<< 550 5.1.1 : Recipient address rejected: 
User unknown in local recipient table

550 5.1.1 ... User unknown
<<< 421 4.7.0 zlp11043.enaf.vci.att.com Error: too many errors

--346K4VsL001258.1683403471/m0288871.ppops.net-00191d01.
Content-Type: message/delivery-status

Reporting-MTA: dns; m0288871.ppops.net-00191d01.
Received-From-MTA: DNS; m0288871.ppops.net
Arrival-Date: Sat, 6 May 2023 16:04:31 -0400

Final-Recipient: RFC822; abuse_...@abuse-att.net
X-Actual-Recipient: rfc822; abuse_...@abuse-att.net
Action: failed
Status: 5.1.1
Remote-MTA: DNS; [144.160.237.58]
	Diagnostic-Code: SMTP; 550 5.1.1 : Recipient 
address rejected: User unknown in local recipient table

Last-Attempt-Date: Sat, 6 May 2023 16:04:31 -0400

That's their Proofpoint inbound filter being told by an actual AT 
machine that the address they tell people to mail does not exist.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] PSL: SOA record per subdomain required?

[Bill Cole via mailop]

On 2023-05-07 at 16:53:51 UTC-0400 (Sun, 7 May 2023 22:53:51 +0200)
Carsten Schiefner via mailop 
is rumored to have said:


Hi John,

Am 07.05.2023 um 20:02 schrieb John Levine via mailop 
:




[…]



The same thing applies to all of these names, all in the PSL:



dyn-berlin.de
in-berlin.de
in-brb.de
in-butter.de
in-dsl.de
in-dsl.net
in-dsl.org
in-vpn.de
in-vpn.net
in-vpn.org



I haven’t checked all the TLDs mentioned, but just .de.


And I might have turned to the wrong list - but:

Textdokument · 238 KB

public_suffix_list

clearly does not list any public suffices for .de.


You're doing something wrong.

I see 74 domains listed there ending in .de. The specific ones in 
question start at line 12026.



Which precisely matches my current state of knowledge.


`grep '^\S*\.de$' public_suffix_list.txt` is enlightening.

--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Yahoo: SOA record per subdomain required?!

[Bill Cole via mailop]

On 2023-05-07 at 15:12:54 UTC-0400 (Sun, 7 May 2023 19:12:54 +)
Gellner, Oliver via mailop 
is rumored to have said:

While I’m not affiliated with Yahoo, I see no reason to bash them in 
this regard. To reduce spam they don’t want to accept emails from 
made-up / non-existing domains, which is a legit concern. They query 
for SOA records to verify whether a given domain exists, which is 
unusual but actually less strict than requiring additional A or MX 
records.


How so?

A SOA is unrelated to email operationally. A name MUST have either an MX 
record or an A record (does anyone do  fallback?) to work as the 
domain part of an email address. Without one of those, an address is by 
definition undeliverable. The SOA record is all administrative detail; 
the only truly critical content is the serial number and that is only 
critical to caching resolvers.


If they are limiting this to domain tails on the PSL, that at least 
limits the damage and makes some sense. People possibly harmed in that 
case can at least address the problem directly themselves.


It would be nice if Yahoo clarified what they are actually doing.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Yahoo: SOA record per subdomain required?!

[Bill Cole via mailop]

On 2023-05-06 at 12:44:26 UTC-0400 (Sat, 6 May 2023 18:44:26 +0200)
Christian Seitz via mailop 
is rumored to have said:


Hello,

we are a small not-for-profit ISP in Germany and having some issues 
with Yahoo since April. All emails from subdomains are no longer being 
accepted by the Yahoo email servers.

[...]
I already tried to contact Yahoo before sending this email to the list 
and they acknowledged the issue "You are correct, we are indeed 
looking for an SOA for each individual subdomain if you're going to 
use it in the SMTP (RFC5321) MAIL FROM." and promised to forward the 
email headers to an engineer, but that was more than a week ago and we 
are having some users who complained about the issue.


That's very odd, because I send a fair bit of mail with addresses in 
domain names that have no SOA and I have had no such problems. I have 
just now confirmed with a fresh address in billmail.scconsult.com that 
Yahoo accepts and delivers (some) mail from domains that are not at a 
zone cut.


This is despite what their postmaster page says and their support 
confirmed to you. Maybe someone with a clue has reversed the extremely 
bad policy?



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] AT has eliminated their DNSBL team?

[Bill Cole via mailop]

For unknown reasons, I got one of these tossed at me by a customer who 
inexplicably wants to send mail to an @att.net address


Action: failed
Status: 5.3.0
Remote-MTA: dns; al-ip4-mx-vip1.prodigy.net
Diagnostic-Code: smtp; 553 5.3.0 alph774 DNSBL:RBL 521< 74.115.114.190
	_is_blocked.For assistance forward this error to 
abuse_...@abuse-att.net


Having seen those a half-dozen times in as many years, I pulled up my 
last removal request, replaced the different bits, and sent it off to 
the address specified by AT in their error message: 
abuse_...@abuse-att.net


A few seconds later, I get this gem:

The original message was received at Sat, 6 May 2023 16:04:31 -0400
from m0288871.ppops.net [127.0.0.1]

   - The following addresses had permanent fatal errors -

	(reason: 550 5.1.1 : Recipient address 
rejected: User unknown in local recipient table)


   - Transcript of session follows -
... while talking to [144.160.237.58]:
>>> DATA
	<<< 550 5.1.1 : Recipient address rejected: 
User unknown in local recipient table

550 5.1.1 ... User unknown
<<< 421 4.7.0 zlp11043.enaf.vci.att.com Error: too many errors

--346K4VsL001258.1683403471/m0288871.ppops.net-00191d01.
Content-Type: message/delivery-status

Reporting-MTA: dns; m0288871.ppops.net-00191d01.
Received-From-MTA: DNS; m0288871.ppops.net
Arrival-Date: Sat, 6 May 2023 16:04:31 -0400

Final-Recipient: RFC822; abuse_...@abuse-att.net
X-Actual-Recipient: rfc822; abuse_...@abuse-att.net
Action: failed
Status: 5.1.1
Remote-MTA: DNS; [144.160.237.58]
	Diagnostic-Code: SMTP; 550 5.1.1 : Recipient 
address rejected: User unknown in local recipient table

Last-Attempt-Date: Sat, 6 May 2023 16:04:31 -0400

That's their Proofpoint inbound filter being told by an actual AT 
machine that the address they tell people to mail does not exist.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Receivers behavior when seeing a new header

[Bill Cole via mailop]

On 2023-05-04 at 09:35:44 UTC-0400 (Thu, 4 May 2023 13:35:44 +)
Benjamin BILLON via mailop 
is rumored to have said:

For the receivers out here, how would _you_ react upon seeing a new 
header, and this header in particular?


I work with SMB mail (it's a thing for companies who haven't been 
convinced to switch to MS365 or Google...) and help keep SpamAssassin 
useful. I would do absolutely nothing unless and until the header 
correlated demonstrably and usefully with messages being spam or 
non-spam.


I cannot conceive of a circumstance where I would try to work with an 
Expires header in any way that tried to interpret its meaning beyond 
correlating existence and basic validity with spamminess. The semantic 
content of that header is strictly MUA-fodder.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DKIM with 3072-bit or 4096-bit RSA signatures

[Bill Cole via mailop]

On 2023-04-26 at 19:59:08 UTC-0400 (Thu, 27 Apr 2023 09:59:08 +1000)
Matt Palmer via mailop 
is rumored to have said:

[...]
I can see how what I said *could* be misinterpreted as being in 
support of

using DKIM for non-repudiability, but I can assure you that wasn't my
intent.  It was an acknowledgement of what DKIM *is* being used for, 
in the
wild, and an assertion that as a result the two reasonable(ish) 
choices that

a mail operator has are:

1. Support DKIM for non-repudiability, and use keys which are 
reasonably
   secure for the useful lifetime of the data being secured (which, 
given
   that non-repudiation is potentially useful decades after the 
fact[1],

   means *very* long RSA keys); or

2. Use shorter keys, and explicitly deny the ability of someone to 
perform
   non-repudiation by the simple expedient of publishing the keys once 
their
   use for the purpose which they were intended is finished -- just as 
you,

   John, have done.


You don't even need to actually publish the keys. Just have this 
colloquy a dozen times spread over multiple public tech fora and a 
decade. Establish as conventional wisdom that DKIM keys of inadequate 
complexity *will* eventually be leaked, stolen, or cracked, and thus 
DKIM signatures are WORTHLESS for non-repudiation past a few months.


Seriously, it is hard for me to imagine a *plausible* threat model that 
would make 2048-bit DKIM keys a risk worth mitigating in this decade.


For the avoidance of any future confusion, my personal preference is 
for
everyone to adopt option 2.  Further, I believe that people who want 
to try
and boil the ocean by convincing every mail operator to support huge 
RSA
keys aren't helping Internet security as much as they might think they 
are.


The third option, which is what most mail operators are doing (because 
it is
the path of least resistance), "use keys which aren't strong enough 
for
long-term non-repudiation, but don't publish them" just means that 
sooner or

later someone with plenty of computing power (or some drugs and a $5
wrench[2]) is going to get their hands on an old DKIM selector key, 
and use

it to cause mayhem.


Not much mayhem if everyone knows that DKIM with 'short' keys is highly 
perishable in regards to non-repudiation. Or, more simply: no one can 
cryptographically verify old email that the original author didn't 
intend to be non-repudiable.



---
Footnotes:

1. Lest anyone think that being able to verify a document decades -- 
or

   even centuries -- after its creation isn't useful, consider how our
   understanding of history is shaped, and the repercussions it has on
   society today, by the re-discovery of long-lost documents.  Now 
consider
   what could be done by a bad actor who can use forged DKIM 
signatures in
   the future to give even a patina of legitimacy to their 
disinformation.


If one believes that their email will need to be verifiable and 
non-repudiable after their death for the sake of history and that anyone 
will have a motivation to forge "their" email, one has a problem that is 
out of scope for DKIM.


2. https://xkcd.com/538/ just in case there's someone who doesn't get 
the

   reference.


Non-repudiation has a similar external vulnerability: it breaks if the 
putative signer has poor key management. If the putative signer uses 
512-bit keys rotated hourly, they might as well be publishing the keys.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SPF behavior on email forwarding

[Bill Cole via mailop]

On 2023-04-14 at 11:20:22 UTC-0400 (14 Apr 2023 11:20:22 -0400)
John Levine via mailop 
is rumored to have said:


It appears that Jaroslaw Rafa via mailop  said:

Dnia 14.04.2023 o godz. 14:11:49 Slavko via mailop pisze:

In other words, SPF check is not something what helps with SPAM
here, seems that spammers adapted to it...


As far as I know, SPF was never meant as an anti-spam measure.


It was most definitely touted as an anti-spam measure.  Some of us 
were there.


Indeed, it is within the living memory of involved parties.
The naïveté of those who pushed it as an anti-spam measure seems 
quaint in retrospect but it is important to understand that at the time, 
there was MUCH more friction in the process of standing up a new domain 
or moving it between DNS providers. They didn't anticipate a thousand 
gTLDs and uncountable "cloud"  providers willing to onboard customers in 
5 minutes if they have a valid credit card number.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SPF behavior on email forwarding

[Bill Cole via mailop]

On 2023-04-14 at 08:45:20 UTC-0400 (Fri, 14 Apr 2023 14:45:20 +0200)
Jaroslaw Rafa via mailop 
is rumored to have said:


It's a well-known fact since SPF appeared, that SPF breaks forwarding.
People say nowadays "forwarding breaks SPF", but I prefer to say it 
the

other way, because forwarding was there before SPF, so the people who
designed SPF should have taken forwarding into consideration when 
designing

it. They didn't, so they did their job wrong.


They DID take it into consideration and they deemed it acceptable 
collateral damage. That's why SRS was invented by the same folks at the 
same time. There were basically 3 POVs expressed then:


1. SPF breaks traditional transparent forwarding, so SPF is wrong and 
should be abandoned.
2. Traditional transparent forwarding breaks SPF, so traditional 
transparent forwarding is wrong and should be abandoned.
3. Everyone should deploy SRS so there's no problem. Can't we all get 
along?


I was and remain in Camp #2, although I knew it would be trouble and 
wandered off mumbling to myself rather than pressing the point. If I 
recall correctly, John Levine was firmly on Team  #1. Group #3 were the 
people who drove the process of standardizing SPF.



Traditional transparent forwarding across administrative boundaries is a 
practice that was doomed to become a problem once the Internet got big 
enough to break the old behavioral consensus. As soon as it was obvious 
that people could and would spoof sender addresses to facilitate 
spamming, traditional transparent forwarding had to go. SPF is a tool 
for killing it off.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[Bill Cole via mailop]

On 2023-03-27 at 06:46:04 UTC-0400 (Mon, 27 Mar 2023 13:46:04 +0300)
Lena--- via mailop 
is rumored to have said:

[...]
For NS I currently use the registrar. Its web-interface allowed me to 
create

the TXT record for a selector. The parent _domainkey - NXDOMAIN.


So this isn't what you're referring to?

# dig _domainkey.lena.kiev.ua

; <<>> DiG 9.18.12 <<>> _domainkey.lena.kiev.ua
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11967
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[Bill Cole via mailop]

On 2023-03-24 at 18:01:50 UTC-0400 (Fri, 24 Mar 2023 23:01:50 +0100)
Heiko Schlittermann via mailop 
is rumored to have said:


What does this change? From senders PoV it is a temporary error. The
sender will retry.


The point of greylisting and "NoListing" is to eliminate the spammers 
who do not retry. They are harmless (aside from delay) for mail being 
haqndlked by a proper MTA that implements a MX fallback and retry 
strategy.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Hotmail will start rejecting messages that fail DMARC

[Bill Cole via mailop]

On 2023-03-23 at 16:18:24 UTC-0400 (Thu, 23 Mar 2023 15:18:24 -0500)
Jarland Donnell via mailop 
is rumored to have said:

I'd like to add a +1 to this for clarification, but in my case I'm 
focused solely on SRS. Will Hotmail reject DMARC failures based on 
From headers or envelope senders?


DMARC does not refer to envelope senders. SPF operates on the envelope 
sender, but unless the From header address is aligned with the envelope 
sender domain, SPF is not relevant to DMARC. DKIM also must align with 
the From header, for it to be relevant to DMARC.



I mean, Gmail already rejects a lot of DMARC failures based on From 
headers (I assume, since rewriting envelope sender doesn't seem to 
consistently change the result), so there's plenty of precedent for it 
and most people aren't really going to blame anyone for doing what 
Gmail does. But it sure is nice if our users can see the same behavior 
when forwarding as they have until now.


I would not interpret a rejection as being due to DMARC unless the error 
message specifically cited it and the From header address has a p=reject 
DMARC record. However, if the From header address domain does have 
p=reject and you're forwarding the message, nothing you do to the 
envelope sender can (or should) save it.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] sender domain reputation

[Bill Cole via mailop]

On 2023-03-22 at 15:44:10 UTC-0400 (Thu, 23 Mar 2023 03:44:10 +0800)
fh--- via mailop 
is rumored to have said:


May I know why you block PW TLD entirety?
Not all of them are spams IMO.


100% of the messages arriving at the mail systems I manage claiming to 
be from a *.pw domain were spam, prior to my outright banning them. In 
the years since, I've never had any indication that any of the messages 
rejected as a result have not also been spam.


It may be worth noting that pw has a particularly notable position, as 
it was one of the earliest demonstrators of how a registry can sabotage 
a TLD. They decided to market their "Pro Web" domains by making them 
free and returnable for a while when first introduced. This was jumped 
on by a few spamming operations who basically drenched the TLD in a vat 
of reputational sewage that will likely NEVER wash off, all in about a 
week almost exactly 10 years ago. Even worse, the event apparently gave 
other TLD hucksters the idea of launching in the same way, dooming a 
handful of other gTLDs (and pimped-out ccTLDs like pw) to a lifetime of 
crap deliverability.


If I ever have reason to believe that any user of any system I handle 
will ever receive a wanted message from a *@*.pw address (or any address 
in any of the other TLDs with similar blocks,) I will exempt the domain 
in question. It has happened for some .online domains and more domains 
in2 TLDs that I no longer block. Not for pw.





On 2023-03-22 23:53, John Levine via mailop wrote:

It appears that fh--- via mailop  said:

On 2023-03-22 12:19, Scott Undercofler wrote:

Like .tk and .ml that are free?



He means the .pw TLD he was using.


Oh, no wonder.  I block it too.

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

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



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop