Re: [mailop] [Admin] Changes to list behaviour, members spam filters etc

[Slavko via mailop]

Dňa 22. novembra 2022 22:27:13 UTC používateľ Sebastian Nielsen via mailop 
 napísal:
>
>>>that trigger take over domain in from: header so its basicly not origin 
>>>poster any more, but it pass dmarc, lol :)
>
>Yes it pass DMARC because the MIME From: domain is rewritten to 
>mailop@mailop.org
>Having spurious signatures that don't validate fully, is OK (and some DKIM 
>tools may report a "dkim=fail" if one signature is not good) but from DMARC's 
>point of view, its enough with 1 valid DKIM signature, that is aligned to the 
>MIME From: domain, to pass DMARC.

One success DKIM signature have to be enough to DKIM pass.

Success SPF is enough to DMARC pass, and that mailop.org had
SPF pass...

regards


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

Re: [mailop] [Admin] Changes to list behaviour, members spam filters etc

[Sebastian Nielsen via mailop]

>>that trigger take over domain in from: header so its basicly not origin 
>>poster any more, but it pass dmarc, lol :)

Yes it pass DMARC because the MIME From: domain is rewritten to 
mailop@mailop.org
Having spurious signatures that don't validate fully, is OK (and some DKIM 
tools may report a "dkim=fail" if one signature is not good) but from DMARC's 
point of view, its enough with 1 valid DKIM signature, that is aligned to the 
MIME From: domain, to pass DMARC.


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

Re: [mailop] [Admin] Changes to list behaviour, members spam filters etc

[Benny Pedersen via mailop]

Alessandro Vesely via mailop skrev den 2022-11-22 10:54:

On Tue 22/Nov/2022 09:55:17 +0100 Sebastian Nielsen via mailop wrote:



The message you wrote had:

Return-Path: 
Authentication-Results: wmail.tana.it;
  spf=pass smtp.mailfrom=mailop.org;
  dkim=fail (signature verification failed) header.d=sebbe.eu;
  dmarc=pass header.from=mailop.org


v=DMARC1; p=reject; sp=reject; ri=604800; rf=afrf; aspf=s; adkim=s; 
rua=mailto:ab...@sebbe.eu; ruf=mailto:ab...@sebbe.eu; pct=100; fo=1;


that trigger take over domain in from: header so its basicly not origin 
poster any more, but it pass dmarc, lol :)


what mailman should have done is either to reject senders with policy 
reject, and only accept maillist members from policy none or quarantine


if we all did that there would be more fair problem to solve, eg make 
sure maillists ips is never rejected on mta stage


in postfix there is support for smtpd_milter_maps this map can disabled 
all milters if the client ip is listed 127.0.0.2 DISABLE


i use just fuglu in prequeue setup so i can reject with std smtp

i give up on specs, but dont break dkim, if mailman cant do arc-seal and 
arc-sign before breaking dkim we are lost


on dmarc policy none pleas dont take over, i can turn dkim into test 
mode to help :)

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

Re: [mailop] [Admin] Changes to list behaviour, members spam filters etc

[Graeme Fowler via mailop]

All

soft_bounce is now set to 'no'.

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

Re: [mailop] [Admin] Changes to list behaviour, members spam filters etc

[Graeme Fowler via mailop]

Morning

Just to be clear: we will only be changing the soft_bounce setting at this time.

Even if all the suggestions being made were implemented, some list subscribers 
would *still* have problems receiving list mail and would reject it. It is 
incumbent on all members of the list to ensure that messages can be delivered, 
and if they can’t - then they’ll be unsubscribed by mailman’s automated bounce 
management.

Cheers all, happy Tuesday (or Monday, or Wednesday in whichever TZ you are)!

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

Re: [mailop] [Admin] Changes to list behaviour, members spam filters etc

[Alessandro Vesely via mailop]

On Tue 22/Nov/2022 09:55:17 +0100 Sebastian Nielsen via mailop wrote:

I think its not technically possible due to the way mailman works with mass 
emails. What I know, mailman will consolidate emails going to the same domain, 
so if you have like 500 receivers at a@gmail.com --- 
z...@gmail.com mailman will just fire off multiple RCPT TO and then 
send the very identical email (DATA) stage to this.



When enabling VERP, each message must be to a single RCPT.  However, it's true 
that message content is prepared for all subscribers alike.  Until Mailman 
doesn't develop such an option, one would have to set up two twin lists (one 
rewriting and one not) and convey them under a common "umbrella" list.




It COULD be workable to have a setting per-domain, that is only accessible 
after having validated ownership of that domain.
For large domains, it would need to be consensus of the list instead, if gmail 
has a known SPF or filter problem, a different setting profile needs to be used 
for subscribers *@gmail.com



Sending a test message which fails DMARC could ensure that the non-rewriting 
option is bearable by that subscriber.




Also, you don’t "accept list messages based on SPF", since the SPF will be the 
pristine sender. Thus it will be invalid when the email comes from the list server.



The message you wrote had:

Return-Path: 
Authentication-Results: wmail.tana.it;
  spf=pass smtp.mailfrom=mailop.org;
  dkim=fail (signature verification failed) header.d=sebbe.eu;
  dmarc=pass header.from=mailop.org



You need a IP exception (SPF="pass" if IP = 2a03:4000:37:599:d8ce:dff:fee1:81c2 
or 91.132.147.157, regardless of real result), but that also risks accepting spoofed 
email if mx.mailop.org doesn't do SPF or DKIM checking on incoming email to the list.



Yes, you need whitelisting.  Even if SPF passed, since sebbe.eu has p=reject, 
without rewriting it wouldn't have sufficed.  Some hold that an ARC seal by 
mailop.org would override DMARC failure.  I agree that ARC would be better than 
SPF (in case of forwarding from an old subscription address), but I'd still 
require mailop.org to be whitelisted in that case.


Whitelisting could be done by end users, concurrently with opting for 
non-rewriting.  Per user white lists are possible.




So I think just keeping the from adress rewrite is the best and most 
"fail-safe" option, as it then means all SPF and DKIM validations will be made 
against mailop.org's server, meaning all validations will pass, regardless of where the 
email originally came from.



I agree.  Yet, this practice precludes some functionalities.  Moreover, getting 
used to spoofed From:'s downplays DMARC.



Best
Ale



-Ursprungligt meddelande-
Från: Alessandro Vesely via mailop 
Skickat: den 22 november 2022 09:46
Till: mailop@mailop.org
Ämne: Re: [mailop] [Admin] Changes to list behaviour, members spam filters etc

On Mon 21/Nov/2022 16:22:28 +0100 Sebastian Nielsen via mailop wrote:

Very important that you keep the MIME From: and MAIL FROM: rewrite to 
mailop@mailop.org if you are going to implement this change, so you don't trip 
sender domain, antispoofing, TLD banlists, DKIM, SPF or DMARC filters.



It would be innovative to have that rewriting enabled or disabled according to 
settings in options/mailop.  Subscribers who can setup their MX to accept list 
messages based on SPF could disable rewriting and receive pristine From:'s.


Best
Ale

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

Re: [mailop] [Admin] Changes to list behaviour, members spam filters etc

[Sebastian Nielsen via mailop]

I think its not technically possible due to the way mailman works with mass 
emails. What I know, mailman will consolidate emails going to the same domain, 
so if you have like 500 receivers at a@gmail.com --- 
z...@gmail.com mailman will just fire off multiple RCPT TO and then 
send the very identical email (DATA) stage to this.

It COULD be workable to have a setting per-domain, that is only accessible 
after having validated ownership of that domain.
For large domains, it would need to be consensus of the list instead, if gmail 
has a known SPF or filter problem, a different setting profile needs to be used 
for subscribers *@gmail.com

Also, you don’t "accept list messages based on SPF", since the SPF will be the 
pristine sender. Thus it will be invalid when the email comes from the list 
server.
You need a IP exception (SPF="pass" if IP = 2a03:4000:37:599:d8ce:dff:fee1:81c2 
or 91.132.147.157, regardless of real result), but that also risks accepting 
spoofed email if mx.mailop.org doesn't do SPF or DKIM checking on incoming 
email to the list.

So I think just keeping the from adress rewrite is the best and most 
"fail-safe" option, as it then means all SPF and DKIM validations will be made 
against mailop.org's server, meaning all validations will pass, regardless of 
where the email originally came from.

-Ursprungligt meddelande-
Från: Alessandro Vesely via mailop  
Skickat: den 22 november 2022 09:46
Till: mailop@mailop.org
Ämne: Re: [mailop] [Admin] Changes to list behaviour, members spam filters etc

On Mon 21/Nov/2022 16:22:28 +0100 Sebastian Nielsen via mailop wrote:
> Very important that you keep the MIME From: and MAIL FROM: rewrite to 
> mailop@mailop.org if you are going to implement this change, so you don't 
> trip sender domain, antispoofing, TLD banlists, DKIM, SPF or DMARC filters.


It would be innovative to have that rewriting enabled or disabled according to 
settings in options/mailop.  Subscribers who can setup their MX to accept list 
messages based on SPF could disable rewriting and receive pristine From:'s.


Best
Ale
-- 





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

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

Re: [mailop] [Admin] Changes to list behaviour, members spam filters etc

[Alessandro Vesely via mailop]

On Mon 21/Nov/2022 16:22:28 +0100 Sebastian Nielsen via mailop wrote:

Very important that you keep the MIME From: and MAIL FROM: rewrite to 
mailop@mailop.org if you are going to implement this change, so you don't trip 
sender domain, antispoofing, TLD banlists, DKIM, SPF or DMARC filters.



It would be innovative to have that rewriting enabled or disabled according to 
settings in options/mailop.  Subscribers who can setup their MX to accept list 
messages based on SPF could disable rewriting and receive pristine From:'s.



Best
Ale
--





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

Re: [mailop] [Admin] Changes to list behaviour, members spam filters etc

[Sebastian Nielsen via mailop]

Very important that you keep the MIME From: and MAIL FROM: rewrite to 
mailop@mailop.org if you are going to implement this change, so you don't trip 
sender domain, antispoofing, TLD banlists, DKIM, SPF or DMARC filters.

Also local permanent errors that indicates NS cannot be found, should IMHO be 
ignored. This because many here privately host their email servers at home... 
And if theres a power outage or similar, the NS will be down too, and that will 
in some causes trip a permanent error tough the condition is actually temporary.
Only if the domain is nonexistent at the parent (which indicates unpaid domain) 
or nonexistent at subscribe time (misspelled domain) it should be handled 
accordingly.

-Ursprungligt meddelande-
Från: Graeme Fowler via mailop  
Skickat: den 21 november 2022 13:09
Till: mailop 
Ämne: [mailop] [Admin] Changes to list behaviour, members' spam filters etc

Hello folks

A list member contacted us this morning to say that they'd observed a large 
number of messages from mx.mailop.org <http://mx.mailop.org/> being rejected by 
their anti-spam/malware system. This has raised a couple of points that I need 
to make:

1. The list frequently discusses spam, malware, scams and such like; as a 
result, a significant number of messages can and will continue to contain 
domains, hostnames, email addresses, technicques used by scammers/spammers and 
all manner of key words or terms that are only too likely to trip filters.
Whilst not demanding that list members add the list and/or server to any form 
of pass-list they may be running, it's possibly a good idea especially if you 
have the ability do this per-recipient.

2. I've spotted this morning that we still have postfix's 'soft_bounce' option 
set to 'yes'. This is an option which is used when testing and even has the 
comment:

# NOTE: This is good for test runs, but bad in production

just above it in the default config. It means that 5xx responses are treated 
'softly', so messages retry. As a result of this, I will be changing that 
option to 'no' in the near future.

THIS WILL CHANGE AUTOMATED SUBSCRIBER MANAGEMENT <--- note well!

mailman *will* disable, and subsequently unsubscribe, users with too many 
permanent errors. It will take time, as it's setup fairly leniently, and you'll 
receive automatic warnings if this happens once a week for 3 weeks before being 
automatically unsubscribed.

I will let everyone know when I've committed this change, probably later this 
week.

Regards

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

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

[mailop] [Admin] Changes to list behaviour, members' spam filters etc

[Graeme Fowler via mailop]

Hello folks

A list member contacted us this morning to say that they'd observed a large 
number of messages from mx.mailop.org  being rejected by 
their anti-spam/malware system. This has raised a couple of points that I need 
to make:

1. The list frequently discusses spam, malware, scams and such like; as a 
result, a significant number of messages can and will continue to contain 
domains, hostnames, email addresses, technicques used by scammers/spammers and 
all manner of key words or terms that are only too likely to trip filters.
Whilst not demanding that list members add the list and/or server to any form 
of pass-list they may be running, it's possibly a good idea especially if you 
have the ability do this per-recipient.

2. I've spotted this morning that we still have postfix's 'soft_bounce' option 
set to 'yes'. This is an option which is used when testing and even has the 
comment:

# NOTE: This is good for test runs, but bad in production

just above it in the default config. It means that 5xx responses are treated 
'softly', so messages retry. As a result of this, I will be changing that 
option to 'no' in the near future.

THIS WILL CHANGE AUTOMATED SUBSCRIBER MANAGEMENT <--- note well!

mailman *will* disable, and subsequently unsubscribe, users with too many 
permanent errors. It will take time, as it's setup fairly leniently, and you'll 
receive automatic warnings if this happens once a week for 3 weeks before being 
automatically unsubscribed.

I will let everyone know when I've committed this change, probably later this 
week.

Regards

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