Re: [mailop] TLS inbound to comcast.net

[Benny Pedersen via mailop]

Suresh Ramasubramanian via mailop skrev den 2024-05-21 15:18:

Yeah Benny – if you’re running 16 year old code and certificates
that you’re still on TLS v1 or 1.1,  it is time to upgrade, asap.
What you have is not much better or worse than sending it en clair
anyway.


tls is self adaptive, so no need to do more then have latest version of 
openssl installed


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

Re: [mailop] TLS inbound to comcast.net

[Benny Pedersen via mailop]

Serhii via mailop skrev den 2024-05-21 14:59:

https://datatracker.ietf.org/doc/rfc8996/


yet its still possible to enable sslv2, sslv3 on openssl :)

i dont think openssl will remove support for any tls versions yet



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

Re: [mailop] TLS inbound to comcast.net

[Benny Pedersen via mailop]

Brotman, Alex via mailop skrev den 2024-05-20 15:09:

Hey folks,

Over the next few weeks, we're going to be disabling TLSv1/v1.1 inbound 
to our platform.  Most senders are already using TLSv1.2/v1.3, so I 
don't think this will be an issue.  However, keep in mind that if 
you're not already using those newer versions, you'll now revert to 
clear-text. Around the same time, we'll also begin negatively impacting 
reputation for clear-text senders (those without TLSv1.2/v1.3).  It 
won't be a huge impact, but many senders are extremely cautious in 
these areas.  If you have questions, please let me know.


i say disabling tls versions is plain stupid to make plain text a bigger 
problem, simply don't make that kind of security


if comcast.net have found a bug in openssl, please make a ticket for 
this, so it will be fixed in openssl


i don't like your wording on "hey something"


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

Re: [mailop] (Mis)use of DKIMs length tag and its impact on DMARC and BIMI

[Benny Pedersen via mailop]

Sebastian Nielsen via mailop skrev den 2024-05-18 20:14:

Yeah, for mailing lists the rewrite + resign method is better, like
this mailing list does, rewrites everything to mailop@mailop.org
And then resigns the mail with their own SPF and DKIM.


with this maillist does not do

Authentication-Results	mx.junc.eu (amavisd-new); dkim=fail (1024-bit 
key) reason="fail (message has been altered)" header.d=sebbe.eu


if maaillist did ARC first on base of dkim pass from you it would help 
to keep the ARC change in stable, this means we would all could verify 
you did it right in the first place, but if maillist screew dkim before 
arc-sign and arc-seal it, then there is only one way back to trascan :(


order of things matter

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

Re: [mailop] eu tld have one ipv6 addr not listen to udp

[Benny Pedersen via mailop]

Marco Moock via mailop skrev den 2024-05-07 20:24:

Am 07.05.2024 um 20:12:24 Uhr schrieb Benny Pedersen via mailop:


eu zone: The server(s) were not responsive to queries over UDP.
(2001:978:2:1::93:2)

why is it not resolved ?


Works for me, via TCP and UDP.
Maybe was a temporary issue.


ah now i remember it, its just dnswiz that see that problem, as i 
remember its a route problem, but outside of dnswiz its works


i just hope dnswiz solve there own problems


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

[mailop] eu tld have one ipv6 addr not listen to udp

[Benny Pedersen via mailop]

eu zone: The server(s) were not responsive to queries over UDP. 
(2001:978:2:1::93:2)


why is it not resolved ?

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

Re: [mailop] Doesn't ARC substitute DKIM at Gmail inbound?

[Benny Pedersen via mailop]

Dave Crocker via mailop skrev den 2024-05-05 19:21:


But that certainly is a common misconception about DKIM.


not even if users have there own dkim selector ?





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

Re: [mailop] Doesn't ARC substitute DKIM at Gmail inbound?

[Benny Pedersen via mailop]

Andrew C Aitchison via mailop skrev den 2024-05-05 18:49:

On Sat, 4 May 2024, Alessandro Vesely via mailop wrote:


The last URL in the response says something about ARC:

   ARC checks the previous authentication status of forwarded 
messages.

   If a forwarded message passes SPF or DKIM authentication, but ARC
   shows it previously failed authentication, Gmail treats the message 
as

   unauthenticated.

Isn't it overkill to put both DKIM /and/ ARC if you know the receiver 
implements both?


I don't think so.

DKIM proves that you did send it.
ARC proves that you forwarded what you received ?


without trustness ?

ARC-signer/ARC-Sealers have to be trusted, to make any different

is arc btw ensure tested in dmarc ?, trustness or ?


In this case GMail can see that you forwarded the mail,
but cannot prove that it really came from the original sender.
I think that this way GMail can reject the email,
or put it in the spam folder, but without blaming you.


gmail users should stop using gmail, problem solved


I am not sure that ARC is supposed to do what we think it is.


if you run all without trustness nothing works
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail has a thing about dots

[Benny Pedersen via mailop]

John Levine via mailop skrev den 2024-05-02 21:02:


Return-Path: <"a..b"@m.jl.ly>


less spammy without "

rfc or not

but imho < and > is required

in spamassassin From:addr "..." is spammy, while From:Name needs "

i noted you use rblsmtpd. with does imho not support tls

okay for testing :)



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

Re: [mailop] Problems with invoices.premierinn.de and postmas...@premierinn.de

[Benny Pedersen via mailop]

Jaroslaw Rafa via mailop skrev den 2024-04-26 11:25:

Dnia 25.04.2024 o godz. 19:12:34 John Levine via mailop pisze:

No, really it's not, and I should know.  In any event, I can see how
people might reject mail from a domain that has a TXT record but no
A or MX, but it seems pretty marginal.


I'm not sure if you understand you well. Marginal? It's a pretty common
MTA configuration to reject mail from domains that have neither A nor 
MX

record. From mail point of view, such domain does not exist.


MX is optional not required if A/ exists with same domain, many 
admins say if MX does not exists. then domain does not want email, this 
is fails also, hope more mta admins know this



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

Re: [mailop] Problems with invoices.premierinn.de and postmas...@premierinn.de

[Benny Pedersen via mailop]

John Levine via mailop skrev den 2024-04-25 18:33:
It appears that Andrew C Aitchison via mailop  
said:

because the return path would not work.

   $ host invoices.premierinn.de


It has an SPF record.  What's the problem?


spf have no rules to be enforced, while rfc 7505 is in all mta, spf 
policy is in many places ignored


if "v=spf1 -all" then replace with rfc 7505

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

Re: [mailop] [External] Re: Off-Topic - VMWare ESXI 7.0

[Benny Pedersen via mailop]

Kevin A. McGrail via mailop skrev den 2024-04-16 16:06:
As the original poster, I wanted to say thanks.  Based on the dozen or 
so replies so far, I clearly struck a nerve.  I'm reading all the 
replies with great interest.


you are welcome to use linode.com for wm like i do, do dns not serve 
well with them ? :)


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

Re: [mailop] Are there other comparable services like spamcop.net / spamhaus.org?

[Benny Pedersen via mailop]

Aban Dokht via mailop skrev den 2024-04-03 10:41:

Hi list,

are there other comparable services like spamcop.net or spamhaus.org 
worth submitting SPAM samples to?
Currently we are reporting SPAM samples semi automated to those to 
services and would like to know, if the are other ones worth to 
contribute so.


https://www.abuseipdb.com/

tip see fail2ban rules and where it is

i have added postscreen to be reported, this is safe to report :)



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

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

[Benny Pedersen via mailop]

Odhiambo Washington via mailop skrev den 2024-03-31 21:16:


Not sure I understand you. but 41.212.32.14 is a static IP.
I don't thing the /24 has any dynamic segment.


https://hetrixtools.com/blacklist-check/41.212.32.14
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

[Benny Pedersen via mailop]

Julian Bradfield via mailop skrev den 2024-03-31 17:35:


It also thinks 41.212.32.14 has been very spammy in recent
months.


oh https://multirbl.valli.org/lookup/41.212.32.14.html dont send email 
from pbl listed ips


OP should ask isp for a static ip

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

Re: [mailop] 172.245.92.88 (HostPapa / Colocrossing) phishing source - not correctly registered @ ARIN ?

[Benny Pedersen via mailop]

Benoit Panizzon via mailop skrev den 2024-03-19 09:03:


In the meantime, it scores a decent number of spam points due to being
in various blacklists:

 [172.245.92.88 listed in dnsrbl.swinog.ch]
 [172.245.92.88 
]
 [Blocked - see 
]

 [172.245.92.88 listed in dnsbl.sorbs.net]
 [172.245.92.88 listed in bl.score.senderscore.com]



https://multirbl.valli.org/lookup/172.245.92.88.html
https://www.abuseipdb.com/check/172.245.92.88

why keep accepting in mta stage ?


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

Re: [mailop] Google unsolicited mail rejected with 421

[Benny Pedersen via mailop]

Jaroslaw Rafa via mailop skrev den 2024-03-17 13:38:

Dnia 16.03.2024 o godz. 13:08:52 Benny Pedersen via mailop pisze:


bingo its why its tempfailed, gmail should redesign how to handle
maillists where message-id can come to inbound on gmail, should not
count on message-id abuse counts


Well... from Google's point of view, it seems like a pretty effective
mechanism to force people to move to *their* mailing list service, 
instead

of running mailing list themselves...

A monopoly wants to be a monopoly.


sure any stupid user can forward mails that is received on maillist to 
there own private gmail account, more or less its this


stop forwarding mails as maillist subscriber is better, in generic world 
is lots better when no mail is forwarded


srs would not fix anything anyway

setup forwarder with sasl client in mta to delivery to freemail provider 
solves it




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

Re: [mailop] Google unsolicited mail rejected with 421

[Benny Pedersen via mailop]

Marco Moock via mailop skrev den 2024-03-16 12:46:

Am 14.03.2024 um 10:28:13 Uhr schrieb Julian Bradfield via mailop:


Their latest daftness (latest in my noticing it, anyway) is
rate-limiting on the basis of too many recipients for a single
message-id, where "too many" varies from 6 to 30. You'd think they'd
never heard of organization mailing lists.


That seems to be the case here too.
If I reply to somebody a gmail directly (not to the list) it gets
through.


bingo its why its tempfailed, gmail should redesign how to handle 
maillists where message-id can come to inbound on gmail, should not 
count on message-id abuse counts



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

Re: [mailop] Love how people use SPF records.. Just for a chuckle..

[Benny Pedersen via mailop]

Michael Peddemors via mailop skrev den 2024-03-11 23:54:

host -t TXT save.ca



... so.. basically hard block everything except 1/2 the internet..


the other half is "v=spf1 +all" ? :)

if one likes no maintained ranges

225 netblocks are authorized
2,583,457 individual IPv4 addresses

i did not count ipv6

34 / 10
DNS-querying mechanisms / modifiers to resolve the record

Duplicate netblock authorization

The following netblocks have been authorized more than once. Duplicates 
usually indicate inefficient records or redundant "include" mechanisms, 
and should be removed.

NetblockOccurrences
170.10.146.242/32   4
170.10.144.242/32   4
40.92.0.0/154
40.107.0.0/16   4
52.100.0.0/14   4
104.47.0.0/17   4
199.255.192.0/223
199.127.232.0/223
69.169.224.0/20 3
23.249.208.0/20 3
23.251.224.0/19 3
76.223.176.0/20 3
52.82.172.0/22  3
76.223.128.0/19 3
216.221.160.0/193
142.250.141.27/32   2
192.206.144.0/212
74.205.174.24/322
76.74.201.32/27 2
54.240.0.0/18   2
54.240.64.0/19  2
54.240.96.0/19  2
205.139.104.0/222
216.235.196.0/222
216.235.200.0/212

oh well :)

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

Re: [mailop] PTR check mechanism / gmail

[Benny Pedersen via mailop]

Gareth Evans via mailop skrev den 2024-03-04 01:17:


Received: from atlas.bondproducts.com (unknown [23.24.6.165])
by mx6.messagingengine.com (Postfix) with ESMTP id ...


https://multirbl.valli.org/fcrdns-test/23.24.6.165.html one red means 
fails



[...]
Received: from users.shellworld.net (users.shellworld.net 
[50.116.47.71])

by atlas.bondproducts.com (Postfix) with ESMTP id ...


https://multirbl.valli.org/fcrdns-test/50.116.47.71.html all green means 
all ok

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

Re: [mailop] tiscali.it/tiscalinet.it reject RFC821 FROM domain as a CNAME because "domain does not have neither a valid MX or A record"

[Benny Pedersen via mailop]

Stefano Bagnara via mailop skrev den 2024-02-29 11:09:


I think I wrote here too early: from further investigation seems like
the issue has gone and now those emails are not refused anymore.


https://totaluptime.com/kb/cname-and-mx-for-the-same-host-name/

dont use cname for email or even mx

and lastly cname breaks dnssec, dont do this, is tlsa not something you 
care about ?


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

Re: [mailop] Gmail.com SPF false negatives?

[Benny Pedersen via mailop]

Kai Bojens via mailop skrev den 2024-02-28 08:35:

Am 27.02.24 um 23:30 schrieb Rob Nagler via mailop:


$ dig +short txt nagler.me 
"v=spf1 a mx ip4:139.177.203.52 include:_spf.google.com 
 -all"


A TTL of just 300 seconds is way too short IMHO. If anything happens to 
your DNS you just have five minutes to fix the problem. Set the TTL to 
at least 3600 seconds.


more or less static data should be ttl of minimal 12h or 43200 seconds


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

Re: [mailop] Gmail.com SPF false negatives?

[Benny Pedersen via mailop]

Matt Palmer via mailop skrev den 2024-02-27 23:59:


Any chance of a transient/intermittent DNS failure on nagler.me?  On
occasion I've seen spurious SPF/DKIM failures when there's been a flaky 
DNS

server in the mix.


first fix spf to be valid for the sender domain in question, as it is 
now its not possible to test if nagler.me is sent from gmail webmail or 
not, dont make this mistakes


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

Re: [mailop] Gmail.com SPF false negatives?

[Benny Pedersen via mailop]

Jarland Donnell via mailop skrev den 2024-02-27 23:54:
Is it plausible that Google had a temporary issue reaching your DNS 
servers?


impossible is possible ?

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

Re: [mailop] Gmail.com SPF false negatives?

[Benny Pedersen via mailop]

L. Mark Stone via mailop skrev den 2024-02-27 23:52:

I believe you need a DMARC record...


does this fix spf fails ?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail.com SPF false negatives?

[Benny Pedersen via mailop]

Rob Nagler via mailop skrev den 2024-02-27 23:30:

gmail.com [1] started failing messages from domains which are
correctly setup for SPF (and have been for some years):

550-5.7.26 Gmail requires all senders to authenticate with
either SPF or DKIM. 550-5.7.26  550-5.7.26  Authentication
results:
550-5.7.26  DKIM = did not pass 550-5.7.26  SPF [nagler.me [2]]
with ip:
[139.177.203.52] = did not pass 550-5.7.26  550-5.7.26

$ dig +short txt nagler.me [2]

"v=spf1 a mx ip4:139.177.203.52 include:_spf.google.com [3] -all"

Sending to (paid) Google Workspace domains works fine. Nothing has
changed on our end, and failures only started this morning.

Any ideas?


remove the include part :)

 6 nagler.me
v=spf1 a mx ip4:139.177.203.52 include:_spf.google.com -all

1 +a:nagler.me:139.177.203.52/32

1 +mx:nagler.me:139.177.203.52/32

+ip4:139.177.203.52/32

redudendance does not help there

https://dmarcian.com/spf-survey/?domain=nagler.me

dont include anything you dont control, unless you own a google server 
at all


30
netblocks are authorized
328,963 individual IPv4 addresses

Authorized netblocks produce SPF "pass" results (as opposed to 
"neutral", "fail", or "softfail").


and its fails still :=)

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

Re: [mailop] One click unsubscribe in mailing list messages

[Benny Pedersen via mailop]

Ken O'Driscoll via mailop skrev den 2024-02-25 21:38:

Outlook has supported list-unsubscribe for at least a year, if not
longer. But, it's an add-on you need to proactively install so...


waiting for roundcube, since squirrelmail have had this as a plugin, 
just not roundcube, hmp :=)


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

Re: [mailop] Anybody having trouble with gmail not recognizing valid SPF records?

[Benny Pedersen via mailop]

Eric J Esslinger via mailop skrev den 2024-02-15 19:17:
My SPF records have been valid for... oh 10 years or so, and haven't 
changed, but the last two days I'm getting intermittent bounces sending 
to gmail.com addresses from our customer domain.
I've sent a couple of emails to postmas...@gmail.com but I'm not sure 
it's monitored. Anyone else seeing such issues?


https://dmarcian.com/spf-survey/?domain=fpunet.com

fpunet.com. 900 IN  TXT "v=spf1 +mx 
a:mail.fpunet.com ip4:104.171.208.42 ip6:2602:FD43:0:2::42 -all"


NetblockOccurrences
104.171.208.42/32   3

sugest to remove +mx a:

i don't know if google barfs on this for 10 years :)



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

Re: [mailop] Is forwarding to Gmail basically dead?

[Benny Pedersen via mailop]

Byunghee HWANG  via mailop skrev den 2024-02-14 05:45:


spf is not designed for forwarding, stop forwarding, problem solved

Yes, you are right!


good then :=)


And if Google stops email service, i will also stop forwarding.


https://wiki.debian.org/PostfixAndSASL

see section SASL authentication in the Postfix SMTP client

optional try this https://github.com/roundcube/roundcubemail/issues/7610

please be open minded, you already is using opensource
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Is forwarding to Gmail basically dead?

[Benny Pedersen via mailop]

Byunghee HWANG  via mailop skrev den 2024-02-14 01:00:


I really strongly agree with this opinion. That's why I wish people in
the world didn't use SPF. SPF is a serious obstacle when forwarding.


spf is not designed for forwarding, stop forwarding, problem solved

dmarc need spf to find aligned mails

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

Re: [mailop] DMARC on srs forwarding domains?

[Benny Pedersen via mailop]

Matus UHLAR - fantomas via mailop skrev den 2024-02-13 16:00:


I still think implementing SPF and SRS gives more value than ARC.


oh dear, if you really need both spf and srs, your problem is more deep 
then linux


begin trust maillists domains in arc, get better stable results on spf 
dkim arc dmarc


for non maillist, dont trust arc

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

Re: [mailop] Is forwarding to Gmail basically dead?

[Benny Pedersen via mailop]

Jaroslaw Rafa via mailop skrev den 2024-02-12 11:34:

Dnia 12.02.2024 o godz. 01:36:09 Benny Pedersen via mailop pisze:

if spf should be pr email addresses, thay could add ipv6 pr sender
email :=)

and have ipv4 with nullMX or simply remove ipv4 in mx, will it ever
happen ?


Yeah, use only IPv6 for sending mail and cut off deliverability to half 
of

the Internet.


gives less problems, not more problems to solve


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

Re: [mailop] Is forwarding to Gmail basically dead?

[Benny Pedersen via mailop]

Sebastian Nielsen via mailop skrev den 2024-02-11 18:33:


It’s a matter of a simple configuration.


checked spf for big domains:

gmail.com 328,960 individual IPv4 addresses
outlook.com 506,999 individual IPv4 addresses (65.55.238.128/26 listed 
twice in spf)
hotmail.com 148,087 individual IPv4 addresses (65.55.238.128/26 listed 
twice in spf)

facebook.com 1,792 individual IPv4 addresses no ipv6 in spf

if spf should be pr email addresses, thay could add ipv6 pr sender email 
:=)


and have ipv4 with nullMX or simply remove ipv4 in mx, will it ever 
happen ?


if anything is free it will be abused, it have being so like internet 
was born, today solutions are many but none will do the hard work on 
progress


f...@userid.gmail.com single spf ip with ipv4 and ipv6
b...@o365user.morefun.long.domain.names.outlook.com single spf ip with 
ipv4 and ipv6


that first step to not share ips pr user

when this are mapped, then spf is more useful then it is now with easily 
forged spf as now


a very pro one here https://dmarcian.com/spf-survey/?domain=yahoo.com

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

Re: [mailop] Is forwarding to Gmail basically dead?

[Benny Pedersen via mailop]

John Levine via mailop skrev den 2024-02-10 05:25:

PS: Perhaps  this list needs a FAQ of Well Known Bad Ideas so we can 
stop having this

argument over and over.


or make mailman patch that stops mailman from breaking dkim

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

Re: [mailop] Is forwarding to Gmail basically dead?

[Benny Pedersen via mailop]

John Levine via mailop skrev den 2024-02-10 05:22:

It appears that Sebastian Nielsen via mailop  said:
just because SPF and DMARC are so badly designed that they can't 
handle it doesnt make it "forging" anything.


It isn't badly designed.
Forwarding a email, is the equvalient of, when you receive a signed 
envelope from me containing a letter, you forge my

signature on the new envelope.


Sorry, but repeating this doesn't make this any less wrong.


+1


I don't know what you imagine "signed envelope" means in this context
and I'm not sure I want to know.


means dkim signed envelope, that breaks if not using srs ?


The postal equivalent of forwarding
is forwarding, you write the person's new address on the envelope and
drop it back in the mail. It has the same return address because it's
the same letter.


+1


People have been making this victim-blaming argument for 20 years,
ever since SPF was designed in a way that failed to handle normal
forwarding.


when envelope sender domain changes, its a new spf domain to take 
responsible of spf, but this will forever be unaligned results on dmarc



It was silly then, and it's no less silly now.


lets make more books on it :=)


This is my last comment on the topic, at least for this round.


we could join another maillist that does not break dkim, in 2024 its 
gone more sadly :/


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

Re: [mailop] Is forwarding to Gmail basically dead?

[Benny Pedersen via mailop]

Sebastian Nielsen via mailop skrev den 2024-02-10 05:11:
And also as a side note, this list server (mailop) also does sender 
rewriting to From: mailop@mailop.org to prevent SPF and DMARC from 
tripping on list mail.

So its obvious it’s the right way to do it.
Same have the list "Exim-Users" begun to do.


stop breaking dkim, stop just stop say spf is a problem for unaligned 
mails, its not right gun to take


you writed dmarc, so i reply on it, i just hope on a better world



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

Re: [mailop] Is forwarding to Gmail basically dead?

[Benny Pedersen via mailop]

Philip Paeps via mailop skrev den 2024-02-09 10:56:


You are not wrong.


+1, maybe #metoo

But you should treat ARC signatures in exactly the same way you treat 
DKIM signatures


no not at all unless world like to step on own foots


: as one signal.


what ever this means


Blindly trusting ARC signatures is not going to go well for you.


there is 2 ways to see it:

1: aligned mails
2: unaligned mails

for this 2 there is 2 catagories for trustness that is important:

a: maillists with List-ID header and arc signed/arc sealed should not 
seen as unaligned, becurse origin sender is aligned
b: mails that is sent to another non maillist with then is forwarded 
should be handled like a: imho


the rest is imho aligned and untrusted dkim untrusted arc, if dmarc says 
reject plese do


sadly opendmarc does not yet use openarc results, i dont know if rspamd 
does all well here, but i think what i write above is the way to go, or 
atleast debate


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

Re: [mailop] DMARC on srs forwarding domains?

[Benny Pedersen via mailop]

Bill Cole via mailop skrev den 2024-02-03 02:01:

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.


there is nothing to tell, its trustness or not

maillist arc trustness: yes
direct to mx trustness: no

in dmarc this trustness missing support

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


spf will fail, so true, but reallity is that next hop changes envelope 
sender, with you clame is a spf bug ?


sites should not reject on base of dkim, spf, or even arc, only reject 
on base of dmarc results, but many brokken software is not ready for 
dmarc yet, sadly, so in pratice only rspamd does something that works, 
but i hope for spamassassin does it well aswell


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

Re: [mailop] Spamhaus contact?

[Benny Pedersen via mailop]

Atro Tossavainen via mailop skrev den 2024-01-19 10:48:

Since most RBLs exchange data,


Source?


sign up to dnswl.org, in that stage blacklists are checked, if accepted, 
blacklists is then ignored :)


i dont know if others doing this, i really dont care

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

Re: [mailop] BIMI and multiple hops

[Benny Pedersen via mailop]

Andrew C Aitchison via mailop skrev den 2024-01-13 07:16:

[ Wearing an MTA developer's hat. ]


+1

I see that an MTA is supposed to remove existing Authentication-Results 
and BIMI-Indicator headers, and that generally an MUA may use these 
headers if present.


where is this dokumented ?

I presume that most MTAs only add these headers on delivery, but if a 
non-compliant MTA received a message with these headers there is a risk 
that the MUA would trust them.


it is tested on incomming mails, not on outgoing

Would it help if MUAs that don't actively support BIMI at least removed 
these headers when delivering to local mailboxes ?


mua must trust LAST MTA, not all MTA on transit, is this a big hint ?

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

Re: [mailop] BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Benny Pedersen via mailop]

Randolf Richardson, Postmaster via mailop skrev den 2024-01-11 19:52:
I might have missed something, but wouldn't that be a phisher's wet 
dream?


Indeed, and because the BIMI record references a URI to load the
logo from, so the scammers (spammers, phishers, malware/virus
distributors, etc.) could simply specify a different logo file with a
recognized brand to make their bad eMail appear legitimate.


lets hope this is resolved to be same domain as sasl sender, where dkim 
is pass, bimi have no rule if its just random other domains is valid


hopefully no mistakes there

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

Re: [mailop] ECDSA DKIM validation?

[Benny Pedersen via mailop]

John R Levine via mailop skrev den 2023-12-21 11:44:

As I've said several times, unless there is a cryptographic problem 
with RSA, there is no reason to *use* any other kind of signature.


analogy to no need to have ipv6 when ipv4 works :)

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

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

[Benny Pedersen via mailop]

Michael Peddemors via mailop skrev den 2023-12-18 23:54:


Maybe my original posting wasn't clear..


+1

You would see these in your inbound logs, coming from o365 via port 
25/TLS...


i have no logs of this here, so it can be differing on diff servers

Just real strange widespread occurrence that you would not expect to 
make it through o365 rules.


yes spammers is smart sometimes
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

[Benny Pedersen via mailop]

Michael Peddemors via mailop skrev den 2023-12-18 22:45:

Strange rewriting mechanism, but this kind of volume should be 
restricted from the o365 side, no? What about the usage of non-existant 
FQDN name in the MAIL FROM?


what mta ?

what port is used ?

i use postfix with postscreen on port 25, in port 465, 587 is dnsbl from 
spamrats, before sasl auth


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

Re: [mailop] Merry Christmas from Google?

[Benny Pedersen via mailop]

Marco Moock via mailop skrev den 2023-12-17 09:00:

Am 16.12.2023 um 16:07:19 Uhr schrieb Jarland Donnell via mailop:


Obligatory: We don't intend to send any email their way that could be
perceived as unsolicited, but our users do use forwarders and we'll
never completely match their filters.


If they use forwarders, SPF will fail in the case the envelope sender
isn't rewritten. Check your logs for that.


false, every forwarder changes envelope sender, so if spf should keep 
pass, its the new forwarding host job to ensure this new envelope sender 
have spf working


problem is that it breaks dmarc aligment, but non aligned mails is still 
fine for maillists


hopefully mailman will ARC-Sign / ARC-seal before it breaks dkim

let the experts do there work

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

Re: [mailop] Hotmail complains about their own mail

[Benny Pedersen via mailop]

Thomas Walter via mailop skrev den 2023-12-16 19:56:

Dec 15 20:46:06 speedy postfix/smtpd[64567]: ACC2D1FF9B: 
client=mail-westus2azolkn19012032.outbound.protection.outlook.com[52.103.10.32]
Dec 15 20:46:06 speedy postfix/cleanup[64616]: ACC2D1FF9B: 
message-id=
Dec 15 20:46:08 speedy postfix/qmgr[6907]: ACC2D1FF9B: 
from=, size=9557, nrcpt=1 (queue active)


https://multirbl.valli.org/lookup/52.103.10.32.html


Backscatter spam *will* get you on blocklists.


+1

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

Re: [mailop] Orange ISP - New outbound IP ranges

[Benny Pedersen via mailop]

Jeremy Jarry via mailop skrev den 2023-12-01 09:48:

Hello all,

Just to inform that we will warm up these new outbound IP ranges
starting next Monday:


where nothing works :=)


80.12.242.64/27,  193.252.23.208, 193.252.23.209, 193.252.23.216,
193.252.23.217, 193.252.23.218, 193.252.23.219, 193.252.22.64/28.


please add them to https://www.dnswl.org/?page_id=72

this is not a blocklist, but a welcomelist

note dnswl only accept /32 for ipv4, but no limit on number of /32 
https://www.dnswl.org/?page_id=21


same apply on ipv6



If you have any question or if you detect any issue, please let us
know : ab...@orange.fr . Thanks !


reduce mail signature on public maillist please

its weekend, and 1 december, 23 days left to xmax

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

Re: [mailop] Reaching out to GMAIL

[Benny Pedersen via mailop]

Ralf Hildebrandt via mailop skrev den 2023-11-21 12:44:


And since it's the postfix-users mailinglist, we're dead sure it's not
spam we're sending!


only one From: header now, so sure its sys4.de now

back to cloud9 solves it, where dkim was not breaked

/me hiddes



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

Re: [mailop] fastmail and sender score snafu

[Benny Pedersen via mailop]

Bill Cole via mailop skrev den 2023-10-09 14:45:

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


backup-mx ? :)

should at that time have being 6 to 60 days, more or less, else it would 
not be a backup-mx, but yes sendmail do have most core settings same as 
todays postfix core

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

Re: [mailop] Noticeable increase of spam emanating from Colocrossing?

[Benny Pedersen via mailop]

Jarosław Rafa via mailop skrev den 2023-10-02 11:38:


Nobody takes UCEProtect seriously. Actually, it takes only a few
spamming IPs in a wide IP range to get listed there. Many ISPs that are
absolutely OK are listed in UCEProtect level 3.


just use dnswl and abusic welcome-list before block-list, it should not 
make any rejects to welcome-listed ips


order in mta stage matters

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

Re: [mailop] Can someone at ptd.net and rcn.com please contact me

[Benny Pedersen via mailop]

Ken Robinson via mailop skrev den 2023-09-09 19:37:


There is no spam content in the messages. MxToolbox shows that my mail
server is not on any blacklists.


to be unfair, dnsbl is not content :)

proff of content checks is after-data test

/me hiddes

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

Re: [mailop] hotmail.com SPF forgot IPv6

[Benny Pedersen via mailop]

Taavi Eomäe via mailop skrev den 2023-08-19 19:13:

On 19/08/2023 13:16, Benny Pedersen via mailop wrote:

if it was hardfails, lets not ignore domain owners, ever
An SPF hardfail isn't sufficient for a reject or mark as spam either 
though.

As previously mentioned, DKIM can be and should be sufficient.


not if dmarc will have aligment pass

spf have policy, dkim have only pass and fails, maillist wants 
recipients to always see aligment in dmarc, so most maillists do take 
ownerships, it should really just have done arc, or atps


But there's also the use-case where a trusted ARC forwarder is forced 
to

cause a SPF fail,


eq arc signer have self spf fails on there own ?


but the recipient can still accept it. Without the
original letter having a DKIM signature.


imho opendmarc have not yet arc test in there source code, its planned, 
but its raining here in danmark right now, lets hope it will be better 
olso in clima changes


openarc is not stable yet, i lost fuglu, and amavisd-new missing 
arc-sign/arc-verify, just like it does with dkim, hope it all will be 
better


i am sure if amavisd did the arc, all maillists problems would be gone 
like a candle light


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

Re: [mailop] hotmail.com SPF forgot IPv6

[Benny Pedersen via mailop]

John Levine via mailop skrev den 2023-08-18 23:37:


Ah! Even better. We are pretty much on the same page then I expect.

There's a whole lot of perfectly normal sending situations that SPF
can't describe. (They mostly incude the words "relay" or "forward".)
So if you reject on -all you'll aways lose a fair amount of real mail.


prove it, it just loose dmarc aligment, if it was hardfails, lets not 
ignore domain owners, ever


spf softfails can still pass dkim, hopefully you know this


It's between you and your users how they feel about losing mail they
want vs. getting more spam. In my experience, they mind the missing
mail a lot more.


its mostly goverment that goverments most for no reason, sadly

btw thanks for reading maillogs and solve tls :)

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

Re: [mailop] authentication hacks, I Need someone from AOL and/or Yahoo to contact me

[Benny Pedersen via mailop]

John Levine via mailop skrev den 2023-07-26 06:44:

This is a very old idea.  See 
https://en.wikipedia.org/wiki/POP_before_SMTP

It's not clear who originally invented it.  It may have been me.


maybe before ipv4 nat was implemented where a single ipv4 could have 
millions of users in just one timeframe limit, it worked well for no 
auth :)


lets see if taugh.com can fix tls in port 25

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

Re: [mailop] SPF +all considered harmful

[Benny Pedersen via mailop]

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


https://mx.junc.eu/dmarc/junc.eu/all.txt prove my incorrect now ?

if you are right i would see more spf pass

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

Re: [mailop] SPF +all considered harmful

[Benny Pedersen via mailop]

Brandon Long via mailop skrev den 2023-07-11 18:50:

I assumed most people had already tuned their systems to ignore +all
or overly broad IP ranges, spammers abused that like a decade ago.


so why did gmail.com add 30+ ipv4 when it could be simple as +all ? 
:)


i did not count ipv6 on gmail.com


I feel like we even discussed it here, including having to exempt
Apple who had their entire class A listed at one point (they no longer
do).


we could hope for less ip space allowed in spf with is imho the real 
thing to solve, sadly +all and losts of valid ips is also valid, eg 
ip4:0.0.0.0/0 -all is complete nonsens, but valid in spf


if spf should solve this nonsense its needs to calc how many ips is 
listed in total, i would if over 256 ips consider domain as +all and in 
spamassassin untrust it as a spamming domain



Saying anyone can send mail as your domain is saying you don't care
about who abuses your domain... or you're protesting against
modern email and pining for the old days.


we could start using uucp and usenet again :)


And agreed, it doesn't solve the mailing list DMARC problem because
the spf is done against the envelope sender which will be the bounce
address for the mailing list, and that won't align with the from
header domain.


there is no dmarc problem if we ask maillist owners, mailman solve it 
all :)



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

Re: [mailop] SPF +all considered harmful

[Benny Pedersen via mailop]

Alessandro Vesely via mailop skrev den 2023-07-11 11:12:


You need +all if you're after dmarc=pass.


no not at all, direct to mx will have spf pass without +all, on next hub 
envelope sender changes, so new spf problem when next hub forwards 
mails, it does not need to be a maillist btw


if dmarc is configure to align to be aligned to make dmarc pass, then it 
will fail for maillists, hmm ?


aligned is to make sure its not forwarded and thus can be trusted not 
travel malicious servers on transit


i just don't care :)



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

Re: [mailop] Listed on Polspam.pl - how to delist?

[Benny Pedersen via mailop]

Sebastian Nielsen via mailop skrev den 2023-06-26 10:39:

It seems I have got listed on polspam.pl for some reason. I cannot
find why, if there is some email that I sent that triggered something,
or if someone accidentially pressed "Spam" instead of "Delete" which
happens regularly.

Theres no contact details on their website, and they have disabled
their contact form. And delisting mentions using this contact form.

Any idea how to get in contact with polspam.pl and have details of
what for spam that have been listed?


incorrect questions leeds to incorrect answers, sorry

https://polspam.pl/ see contact us

so in praktise you need to send mail from there blacklists listnings to 
get delisted, clever ? :)


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

Re: [mailop] [EXT] - Dkim fails, success on same email?

[Benny Pedersen via mailop]

Mark Alley via mailop skrev den 2023-06-20 19:05:

You'll need to add the DKIM selector (and key) Sophos generated for
you to your external DNS provider so that other receivers can resolve
the key, which enables them to validate messages signed by your email
filter.


if sophos like to change custommers dns, then sophos is loosing

all that is required for another forward host is to ARC-Sign/ARC-Seal 
before breaking dkim if valid dkim cant be preserved otherwize


or start another way, do ATPS signing, if sophos is pro that should not 
be a problem


proff is this maillist here breaks dkim, so mailop also fails



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

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

[Benny Pedersen via mailop]

Jay Hennigan via mailop skrev den 2023-06-20 17:46:

On 6/19/23 13:55, Michael Wise via mailop wrote:
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.


Because if you reuse the same IP address, your legs will sink through
the snow past your knees?


later users will create a iglo :)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Strange mail delivery from microsoft

[Benny Pedersen via mailop]

Klaus Ethgen via mailop skrev den 2023-06-18 18:53:

I have tighten my firewall a bit and seen many attacks from Microsoft
(40.92.0.0/16). They contact once from a IP and then never again. If I
greylist them, the will try to deliver from a different address which
gets greylisted again and so on.


use greylist /32 for ipv4, and /64 for ipv6, with microsoft there is no 
ipv6 senders


maybe change greylist time to one single hour aswell, so urls is listed 
at accept time



Could you please tell me how to handle that broken mail delivery? It
triggers all, my mailserver attack filter as well as greylisting.


change greylist to /32 for ipv4, i cant think of a better way to help 
microsoft servers :)



Unfortunately I have some contacts on hotmail. Otherwise I would not
care about.


not news for me

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

Re: [mailop] Port 25 Pingback?

[Benny Pedersen via mailop]

Mike Hillyer via mailop skrev den 2023-06-16 19:48:

Sources or hosts?

I don’t expect a given host to answer on port 25 just because it
sends, but the domain in the return path should be accepting mail
properly. If they can’t be bothered to receive their DSNs then they
are not likely a good-faith sender.


DSN is not sent, its generated by there own closed port 25 still, so DSN 
works without port 25 listners


maybe accept and bounce should really be stopped ?

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

Re: [mailop] When Will Outlook Rollout SRS for All of Their Email Servers? (For the sake of bimi)

[Benny Pedersen via mailop]

John Levine via mailop skrev den 2023-06-06 11:45:

It appears that Al Iverson via mailop  said:

How long until Google, Yahoo, others stop accepting that forwarded
mail from Microsoft, is another way to frame that.


The problem is that you can't tell it's forwarded, since it comes
from the same servers that sent real mail for the forged domains.


dkim is not your friend ? :=)

if not dkim signed and freemail ?, whats next ?

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

Re: [mailop] When Will Outlook Rollout SRS for All of Their Email Servers? (For the sake of bimi)

[Benny Pedersen via mailop]

Mark Alley via mailop skrev den 2023-06-06 02:17:

Last time it was reported to Microsoft, IIRC the individual got the
response, "it's working as expected" as to the vulnerability that
allows aligned SPF mail to be forwarded without SRS from any tenant.

Realistically, DMARC and BIMI are working as expected in this
scenario. Email was (re)sent from an (at the time) authorized IP
address and an aligned RFC5321.mailfrom header for ups.com. The fault
lies partly with UPS for keeping the include for Exchange Online in
their Hosted SPF macro (unnecessary because they don't send directly
from O365), and partly with Microsoft for allowing and enabling this
forwarding vulnerability to exist.


if recipients starts make results from spf untrusted if more then 256 
uniq ipv4 is valid sender ips, then host have to listen and reduce 
includes: in spf, over accepted ipv4 spf listed ips is basicly same as 
v=spf1 +all


we all loose with this, but in spf its perfektly valid aswell

sorry for not counting ipv6 in that calculate


O365 customers can mitigate this by ensuring they sign DKIM and remove
the O365 include where feasible (only possible if O365 is not a
domain's last hop), or by signing DKIM and making the O365 include a
SPF neutral disposition.


this is more or less not needed if dmarc is strict, or if sender wants 
aligned emails, and reject the rest, also adsp is usefull



The former is the easiest and least impactful, assuming one meets that
criteria; The latter - it's a dirty fix - but current reality is
anyone that uses O365 relying on their SPF include will be vulnerable
to this until Microsoft fixes the root cause.


maillist next genration is more or less just imap shared access where no 
mail is sent at all, or ?, usenet still works :=)


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

Re: [mailop] Google Toolbox broken?

[Benny Pedersen via mailop]

John Levine via mailop skrev den 2023-06-03 00:34:


If you mean the DKIM record, which one?  It has quite a few.


Authentication-Results	mx.junc.eu (amavisd-new); dkim=fail (2048-bit 
key) reason="fail (message has been altered)" header.d=iecc.com 
header.b="paysHkcv"; dkim=fail (2048-bit key) reason="fail (message has 
been altered)" header.d=taugh.com header.b="TfuOOSbe"


when maillists does not support ARC it ends in limbo land if dkim signed 
processs is not done AFTER mailman but before, generic dkim signers 
should not dkim sign emails not originating FROM a maillist, but should 
do ARC BEFORE mailman breaks it all


is there  a hope for a fix ? :)

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

Re: [mailop] Google Toolbox broken?

[Benny Pedersen via mailop]

Taavi Eomäe via mailop skrev den 2023-06-02 10:23:

Your DKIM TXT record seems valid, but does not specify the key type,
looking at the length it should probably contain "k=rsa". Or they
might not like you specifying acceptable hash algorithms.


this is only needed if defaults is not ok, so it follows what is with 
dmarc where all is optional


incase of unsure check dmarcian.com
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Google Toolbox broken?

[Benny Pedersen via mailop]

Gellner, Oliver via mailop skrev den 2023-06-02 09:45:

Hello,

the Google admin toolbox claims our DKIM keys and MTA-STS entries are
invalid. Example:
https://toolbox.googleapps.com/apps/checkmx/check?domain=dm.de_selector=dmglobal4
reports "Invalid format of DKIM record"


what errors 
https://dmarcian.com/dkim-inspector/?domain=dm.de=dmglobal4 ?



and "MTA STS is malformed".


i can recommend https://app.easydmarc.com/mta-sts-generator, i just use 
them to verify my dns data is ok



I
cannot find out what is invalid about them, can someone shed some
light on this?


is your plan to use google mx ?

or keep it all on dm.de ? :)

google blame you need spf mx server includes, you dont need to follow 
them there, its only valid for when dm.de is on google mx



Or is the Google admin toolbox broken, or is it only
designed for Gsuite domains and expects some Google specific entries
like it does for the SPF check?


its not brokken, but its only help to make google mx server setup valid, 
if you dont use google mx, then you should not use that toolbox


to get more neutral help use dmarcian.com for advise on dns setups and 
checks

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

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

[Benny Pedersen via mailop]

Robert L Mathews via mailop skrev den 2023-06-01 17:45:

Maybe other people have noticed and discussed this and I'm just behind
the times, but for more than a decade, Google specifically said:

"Avoid changing the envelope sender when forwarding email to Gmail."


lets use forged original sender, works much better :)


(You can see this as recently as last November at
.)


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 ?


note there google will see this non aligned in dmarc since its a forward


Because of that, we didn't do it. But I noticed that the current page
at  now says the exact
opposite:

"Change the envelope sender to reference your forwarding domain."

So I guess it's time to add SRS rewriting for Gmail addresses...!


no

SRS just hide all fails, it does not solve all fails, don't use SRS

google is right, use local adresses on the forward host that can bounce 
back to original sender local, if this is complicated, don't use 
forwards


Life is good, use linux

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

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

[Benny Pedersen via mailop]

John Levine via mailop skrev den 2023-05-24 19:50:


same thing


I checked with the guy who wrote the Null MX RFC and he is quite
sure they're not the same thing.


xpoint@tux ~ $ dig example.org txt

;; ANSWER SECTION:
example.org.86400   IN  TXT 
"6r4wtj10lt2hw0zhyhk7cgzzffhjp7fl"
example.org.86400   IN  TXT "v=spf1 -all"

xpoint@tux ~ $ dig example.org mx

;; ANSWER SECTION:
example.org.86400   IN  MX  0 .


test it please, do you see spf rejects or nullmx rejects ?

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

check your logs :)

in my test example.org does not enforce spf rejects



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

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

[Benny Pedersen via mailop]

Laura Atkins via mailop skrev den 2023-05-24 10:03:


nullMX means the domain doesn’t receive mail. v=spf1 -all means the
domain doesn’t send mail. When I’m working with clients who are
setting up domains for not-email I recommend both as they address the
issue from different directions.


end results should be the same, i can argue that nullmx and SPF is doing 
different things, but end outcome would imho be same result, more or 
less



It’s also perfectly legit for a
domain to receive email while never sending email.


correct


I have domains set
up to receive client mail, for instance. They never send mail,
they’re collection addresses.


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

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

[Benny Pedersen via mailop]

John Levine via mailop skrev den 2023-05-24 01:58:


domains with this spf would possible know that spf is more weak then
then rfc 7505 (nullMX) ?


No, not at all.

SPF -all says a domain doesn't sent mail.


+1

if recipient check sender domain, its imho same thing

if recipent do not check sender domain its a diffrent

i just mention this since not all checks spf and enforce it, while if 
nullmx is used its enforced



Null MX says a domain doesn't receive mail.


same thing


They often apply to the same domains, but they're not the same thing.


spf -all is not needed if its a nullmx domain

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

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

[Benny Pedersen via mailop]

Todd Herr via mailop skrev den 2023-05-23 20:54:


Indeed, an email will only be rejected if it has DMARC setup as
reject.


There should be one exception to the rule of waiting till after DATA
to check for a DMARC policy, and that's in the case of the following
SPF record:


"v=spf1 -all"


It seems wholly appropriate to reject at MAIL FROM if the RFC5321.From
domain publishes an SPF policy that says "This domain is not used to
send mail, ever."


domains with this spf would possible know that spf is more weak then 
then rfc 7505 (nullMX) ?


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

Re: [mailop] Mailing lists, Apple and failing DKIM signatures

[Benny Pedersen via mailop]

Jim Popovitch via mailop skrev den 2023-05-22 23:12:


You are the sole carrier of that "debate", and, despite many many
previous attempts at correcting you, your assertions that the way
Mailman replaces the From address somehow breaks *your* DKIM setup,
is a hill that we all know you will die on, and 99% of us no longer
care if that occurs. :)


Authentication-Results	mx.junc.eu; dmarc=fail (p=quarantine dis=none) 
header.from=mailop.org
Authentication-Results	mx.junc.eu; dkim=fail reason="signature 
verification failed" (2048-bit key) header.d=domainmail.org 
header.i=@domainmail.org header.b=DuwMJ/dZ; dkim-atps=neutral

Authentication-Results  mx.junc.eu; arc=none smtp.remote-ip=127.0.0.1

i hope ATPS would help


Also, please install a spell-checker in your environment.  Thanks!


i have, but more or less don't use it to spell right to a maillist that 
breaks dkim on purpose, sorry being lacy



-Jim P. (one of the many "bastards from hell", as Benny puts it)


if there is room for one more passanger the boat might not sink yet :)


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

Re: [mailop] Mailing lists, Apple and failing DKIM signatures

[Benny Pedersen via mailop]

Simon Arlott via mailop skrev den 2023-05-22 20:20:

If you're running a mailing list that retains the original DKIM
signatures [that will fail because the message subject and body have
been modified] you might want to strip/hide them because it can cause
Apple iCloud Mail to increment the spam score by 1 which can cause it 
to
be delivered to Junk (despite "I've pretty religiously been marking 
each

email as not spam but it's not keen at all").


...

we can always wish no maillist do not break dkim, sadly we are not 
living in 1970 anymore :/


i give up, all would have being good if dkim was not breaked, but no, 
maillists owners is sometimes, bastads from hell to say it :)


i have no suggestion do break dkim, removing headers, bah it does not 
help at all

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

Re: [mailop] Mailing lists, Apple and failing DKIM signatures

[Benny Pedersen via mailop]

Jim Popovitch via mailop skrev den 2023-05-22 20:49:


DO use Mailman's built-in DMARC mitigations for re-writing From for
DMARC identified domains, including p=none.


fine tool to break dkim, it would not help repeat why not break dkim, 
there would be endless debate why keep the problem, old software from 
1970 does not break new standard


only fix i have is to turn all maillist over to digest mode, this will 
solve downstream testers that still belive maillist is spam and needs 
dmarc pass to not be spam, sadly :/

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

Re: [mailop] emailage.com ?

[Benny Pedersen via mailop]

Jasper Spaans via mailop skrev den 2023-04-24 10:44:

Hello,

We're seeing quite some postfix PREGREET errors in incoming smtp
traffic from hosts claiming to be emailage.com (by lexisnexis). Does
anyone know whether this is just a dressed up list washing service, or
would it be worthwhile for our customers if we start whitelisting
them?


postscreen is done before smtp, so there is no email to whitelist

just ignore it, bots is bots
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] gmail have missing ipv6 in spf

[Benny Pedersen via mailop]

Benny Pedersen via mailop skrev den 2023-04-01 12:15:
are google staff here ?, in case 2a00:1450:4864:20:0:0:0:52a is giveing 
spf fail


how to contact google with this ?


note to self, remmember to check spamassassin is using Mail::SPF not 
just forged header results, ups


gmail is ok

mx /etc/postfix # postmap -q 2a00:1450:4864:20:0:0:0:52a 
cidr:/etc/postfix/google_spf_ip6.cidr

ok

sorry for noice on it
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] gmail have missing ipv6 in spf

[Benny Pedersen via mailop]

are google staff here ?, in case 2a00:1450:4864:20:0:0:0:52a is giveing 
spf fail


how to contact google with this ?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Unbound configuration for DNSBL ?

[Benny Pedersen via mailop]

Slavko via mailop skrev den 2023-03-30 12:52:

Dňa 30. marca 2023 10:11:32 UTC používateľ Benny Pedersen via mailop
 napísal:

Cyril - ImprovMX via mailop skrev den 2023-03-30 09:30:
I removed the usage of OpenDNS, and let Spamhaus know about this. 
I've

also enabled qname-minimisation, we'll see if that helps.


rbldnsd have no support for qname


It will not be problem with unbound default config (no strict
enabled), as when it meets NXDOMAIN it will skip other name
parts and will try once with full query name.


qname-minimization disabled;

in my own bind9, until its solved

work around is to rbldnsd dump data to bind zone file, and load the zone 
file directly in bind, but this needs lots of ram, unless one use dlz 
datastorages, and this slow down latency that solution, not easy to 
solve

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

Re: [mailop] Unbound configuration for DNSBL ?

[Benny Pedersen via mailop]

Raymond Dijkxhoorn via mailop skrev den 2023-03-30 12:30:

Benny,

I removed the usage of OpenDNS, and let Spamhaus know about this. 
I've

also enabled qname-minimisation, we'll see if that helps.



rbldnsd have no support for qname

no one like to solve it


Its not even that.


+1


Most DNSBL's have multi level listing support. How on earth would your
nameserver know about where to cut the lookups off?


dbl in same zone where the zone itself miss _dbl
ipv4 rbl in a dbl zone where the zone miss _dbl
ipv6 rbl in a dbl zone where the zone miss _rbl in the zone it self

spamassassin does not care there, or is it spamhaus ?

rspamd have atleast more control of this with each test can be defined 
what data dns have of intrest



Eg would it then ask for

myhuaweicloud[.]com[.]multi[.]surbl[.]org

where it would actually be needed to ask


here multi should have _multi


somebadcustomer[.]smn[.]cn-north-1[.]myhuaweicloud[.]com[.]multi[.]surbl[.]org

The listings itself are wildcarded -when it fits purpose- but
definately not all listings/records apply to that.


samme miss of _


I dont think it would work when it comes to DNSBL's lookup types.

But enlighten me if you feel i am wrong. Happy to rethink...


try enable it in bind9 with strict policy, and then see querylog

so it only works if spamassassin have datafeeds and tests is done 
without real dns servers in the middle

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

Re: [mailop] Unbound configuration for DNSBL ?

[Benny Pedersen via mailop]

Cyril - ImprovMX via mailop skrev den 2023-03-30 09:30:

I removed the usage of OpenDNS, and let Spamhaus know about this. I've
also enabled qname-minimisation, we'll see if that helps.


rbldnsd have no support for qname

no one like to solve it
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] sender domain reputation

[Benny Pedersen via mailop]

John Levine via mailop skrev den 2023-03-22 16:53:


He means the .pw TLD he was using.


Oh, no wonder.  I block it too.


so you have none ham mail now from pw tld ? :)

with is funny so you can still say pw is spam only !
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Not out of the office yet, quick heads up... High Russian Traffic..

[Benny Pedersen via mailop]

Michael Peddemors via mailop skrev den 2023-03-17 17:25:


Oh, and a little blip from Linode ;)

66.228.47.53  1   
66-228-47-53.ip.linodeusercontent.com
   66.228.47.240  1 
66-228-47-240.ip.linodeusercontent.com
143.42.167.1111 
143-42-167-111.ip.linodeusercontent.com
   143.42.167.138 1 
143-42-167-138.ip.linodeusercontent.com
   143.42.167.182 1 
143-42-167-182.ip.linodeusercontent.com
   143.42.167.196 1 
143-42-167-196.ip.linodeusercontent.com
172.105.138.501 
172-105-138-50.ip.linodeusercontent.com
   172.105.138.1221 
172-105-138-122.ip.linodeusercontent.com
   172.105.138.1411 
172-105-138-141.ip.linodeusercontent.com
   172.105.138.1781 
172-105-138-178.ip.linodeusercontent.com
   172.105.138.1851 
172-105-138-185.ip.linodeusercontent.com
   172.105.138.2481 
172-105-138-248.ip.linodeusercontent.com




reject ptr here, linode member did not set there domain in reverse dns
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Contact Mimecast.com Postmaster - Sending Problems

[Benny Pedersen via mailop]

Nikolas Bauer via mailop skrev den 2023-03-16 11:32:


SMTP error from remote server for RCPT TO command, host:
au-smtp-inbound-2.mimecast.com (124.47.150.26) reason: 550
Administrative prohibition - envelope blocked -
https://community.mimecast.com/docs/DOC-1369#550 [1]
[Xwi6G9SYM7adxsiZUWh3pw.au54]



Anyone got some direct contacts?


550 Administrative prohibition envelope blocked
The sender's email address or domain has triggered a Blocked 
Senders Policy or there's an SPF hard rejection.
Delete or modify the Blocked Senders policy to exclude the 
sender address.


follow the url helps

ensure sender have not shared ip, and is dkim signed, setup dmarc poliy 
none, and feedback to see how it goes


gmail have a spf with 30 + ipv4 and i still see spam mails with spf 
fails


hmm :)




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

Re: [mailop] warming up IPs, Microsoft?

[Benny Pedersen via mailop]

John R Levine via mailop skrev den 2023-03-06 18:55:


Linode has a bunch of different IP address blocks and I would expect
recipients to block the ones that send annoying amounts of spam.
That's what I do.  So as likely as not, you're just lucky that you
don't have annoying neighbors.


linode do pr new vps give a ipv4 range with /24, but still only one 
usable to use, each vps can ask for more ipv4, but this will be another 
/24, doh :)


for ipv6 just ask, unlimited free, free as in /64 only
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] h-email.net

[Benny Pedersen via mailop]

Jaroslaw Rafa via mailop skrev den 2023-03-05 20:45:

It's obvious to check MX for *recipient* domain, but not
for sender...


reject_mumble_sender is very hard ?, you have it as recipient, hmmp :)

tip dont accept mail for unknown domains, rfc 7505 does create this, but 
keeps domain valid for homepages, just not for email


most defailt mta configs does not need custom restricktions for this to 
work

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

Re: [mailop] Intuit directly spaming

[Benny Pedersen via mailop]

John Levine via mailop skrev den 2023-03-05 03:22:


$ host -t txt 1.1.89.167.asn.routeviews.org
1.1.89.167.asn.routeviews.org descriptive text "11377" "167.89.0.0" 
"18"


or free as in free, with ip2location sqlitedb created with a single php 
code loader, then anorher php to find results for asn, ipv4, ipv6 and 
combination of that, i update this sqlitedb 12 times a year :)

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

Re: [mailop] h-email.net

[Benny Pedersen via mailop]

Jaroslaw Rafa via mailop skrev den 2023-03-04 20:00:

Dnia  3.03.2023 o godz. 22:21:28 John Levine via mailop pisze:
Why isn't it just "v=spf1 -all" then? That's the most common way of
indicating that a domain should never send mail...


it would be more weak then rfc 7505 anyway, since not all mta checks and 
enforce spf in mta stage


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

Re: [mailop] h-email.net

[Benny Pedersen via mailop]

Raymond Dijkxhoorn via mailop skrev den 2023-03-04 00:51:


$ host -t txt h-email.net
h-email.net descriptive text "v=spf1 ip6:fd96:1c8a:43ad::/48 -all"


Disposable email services.

10minutemail[.]pro
10minutesmail[.]net

And so on ...


fd96: is bogus aswell, as in i like to see an email from that iprange :)

h-email.net could do better with rfc 7505 (nullMX)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] New member, trying to bring our mail server inline.

[Benny Pedersen via mailop]

Laura Atkins via mailop skrev den 2023-03-03 18:55:

The message he sent to mailop had the selector I used and is also
failing DKIM.


mailop.org domain does not provide any dkim signed msgs, thats on 
propose from them imho, but spamassassin still see my signing an claims 
take over from header dkim fails


dkim works :)

if dkim signing was aswell removed in take over it will fire on adsp 
sign all


mailman 2.1 is now over 2 years old software and possible mailman 3 
fixes all problems with dkim, so takeover can be removed for goods ?


i still dream, but hopefully not
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Does gmail accept unicode character in From domain? I don't think so

[Benny Pedersen via mailop]

Alex Burch via mailop skrev den 2023-03-03 17:22:


If John Jetmore is here, please merge that sucker!


as in posting to public maillist with big html signature ?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Does gmail accept unicode character in From domain? I don't think so

[Benny Pedersen via mailop]

Alex Burch via mailop skrev den 2023-03-03 00:38:

I am using unicode in the From: not the MAIL FROM. Do you have to
specify it SMTPUTF8 in the MAIL FROM to use it in the From header? I
don't see anything about that here:
https://www.rfc-editor.org/rfc/rfc6531

I was under the impression that if the client offered SMTPUTF8
extension then you could go ahead and use unicode in the headers like
From.


SMTPUTF8 is not any mail headers, envelope senders can only imho be idn, 
not utf8 yet, there is no dns servers that handle domains with utf8, so 
it can only be localpart if any


for the mta part and dns, mta have to map both utf8 and idn to same 
result else it would be another domain


my joke is that if computers was 32bit in the old days, we would not 
have seen all trying to make another encoding standard that breaks 
another standard


dont know if i am completly wroung or not, dont need it anyway :)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail blocking of good customer

[Benny Pedersen via mailop]

Luke via mailop skrev den 2023-02-26 04:15:

I can assure you sendgrid retries 4xx. We also don't retry 4xx. We
also retry 5xx. We also don't retry 5xx. How is it 2023 and people
still think 4xx means retry and 5xx means don't retry?


what books do you read ?

maybe rfc 7505 is soon or later for all ?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail blocking of good customer

[Benny Pedersen via mailop]

Matt Palmer via mailop skrev den 2023-02-25 01:01:

[Fixed TOFU]

On Fri, Feb 24, 2023 at 03:57:00PM -0500, Christine Borgia via mailop 
wrote:
On Fri, Feb 24, 2023 at 1:09 PM Benny Pedersen via mailop 


wrote:

> Christine Borgia via mailop skrev den 2023-02-24 17:17:
>
> >>> 421 4.7.0 [149.72.90.158 15] Our system has detected that this
>
> > If someone could reach out to me, I'd greatly appreciate it. I'm not
> > sure what to advise this customer except to say that email may not
> > work for their business model.
>
> note 421 4.7.0 ?
>
> this is softfails not hardfails, so mail in queue will try next 5 days
> to deliver it, if that expire it would be returned to sender

It is transient, but they are blocks and are not retried. Weird, 
right?


That's something to talk to your ESP about.  They're in charge of 
retrying.


in this case esp is sendgrid, with will not as i see it accept msg if 
google tempfails it ? :=)


in postfix its proxy content filter, that is not the problem of 
tempfails for the sender to sendgrid, same will happend if i stop fuglu 
here


or it could simple be sendgrid validate recipients but never succed with 
it on google ?


time to wake up for sendgrid :)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail blocking of good customer

[Benny Pedersen via mailop]

Simon Greenwood via mailop skrev den 2023-02-24 22:09:


This (which I didn't know) adds a whole different aspect to the issue
- much has been said about how email is now centralised and is almost
impractical to run as a small operator level, but if a company like
Shopify and indeed Sendgrid can't assure mail delivery because the
largest mail operators will reject mail sporadically based on
non-specific criteria, and more that someone in Christine's position
doesn't have someone they can call at Google or Microsoft or wherever,
then there's a bigger problem.


sendgrid do mistakes aswell :)

inbound is not outbound, all inbound ips could be recieving mails from 
custommers, thats fine, but question is then:


do sendgrid keep the inbound mail on this ip when sending to google ?, 
does google see mails from all ips at sendmail pr sendgrid custommer ?


who knows why this is failing ? :)

please if sendgrid is reading my silly mails, do not share ips pr 
sendgrid custommer, each custommer can have payed pr ip non shared, make 
more money, to make better service pr custommer, this advice is 100% 
free from me

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

Re: [mailop] Gmail blocking of good customer

[Benny Pedersen via mailop]

Christine Borgia via mailop skrev den 2023-02-24 21:57:

It is transient, but they are blocks and are not retried. Weird,
right?


proff from logs is ?

others say this ip is not google but sendgrid

simple "mailq" will show it


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

Re: [mailop] Gmail blocking of good customer

[Benny Pedersen via mailop]

Christine Borgia via mailop skrev den 2023-02-24 17:17:


421 4.7.0 [149.72.90.158 15] Our system has detected that this



If someone could reach out to me, I'd greatly appreciate it. I'm not
sure what to advise this customer except to say that email may not
work for their business model.


note 421 4.7.0 ?

this is softfails not hardfails, so mail in queue will try next 5 days 
to deliver it, if that expire it would be returned to sender


follow the url in that tempfail to get support is best advise from me

clean up time here

https://multirbl.valli.org/lookup/149.72.90.158.html

that sayed i dont belive google uses outside rbl lists


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

Re: [mailop] Should mailing list messages be DKIM signed? (ARC / DKIM)

[Benny Pedersen via mailop]

Alessandro Vesely via mailop skrev den 2023-02-20 08:47:


The point of ARC is to report authentication results.  A post having
only spf=pass becomes unauthenticated after the first hop.


inccorect, nexthop can use spf aswell, or not


Right.  Ditto for DMARC rejects/ quarantine, which I don't think many
ML receivers honor.


DMARC is greedy, if DKIM is breaked, to avoid DKIM problems if needed to 
post to ml could be to configure dkim to be in test mode, ensureing 
mails are not rejected based just on dkim fails, mailman can do this 
policy to not accept non testing mode in dkim, its design fails that 
dkim should be used as a reject factor :(


back to DMARC, it should imho use ARC results to know if original sender 
did have dkim pass and spf pass, and make results based on it, then its 
no matter if mailman breaks dkim or not, since it would not matter for 
dmarc testing downstream, we can all raise the flag when developpers of 
mailman know this :=)


i use dmarc policy none to protect maillist receivers to not reject 
maillists senders, more or less this is what bad software try to solve, 
hmmp

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

Re: [mailop] Should mailing list messages be DKIM signed? (ARC / DKIM)

[Benny Pedersen via mailop]

Alessandro Vesely via mailop skrev den 2023-02-18 13:49:

Mailman cannot verify SPF.


envelope sender changes on nexthop, no ?

so why is it important ?

if you meant not to accept spf fail posters, this is still in mta stage 
to be enforced if wanted not to accept it

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

Re: [mailop] Should mailing list messages be DKIM signed? (ARC / DKIM)

[Benny Pedersen via mailop]

Tobias Herkula via mailop skrev den 2023-02-17 17:56:


Only adding ARC without your own DKIM will make it harder for a lot of
people, that are not yet ready to process ARC signatures.


in ARC terms it always ORIGINATE on nexthub, but this rule is not for 
nexthub with DKIM


sadly so many maillist still breaks DKIM :/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop