Re: [mailop] tls certificates

[Tobias Fiebig via mailop]

Heho,
I looked at that recently; See the SMTP paper recently published [1], and 
enforcing TLS certainly is indeed on the rise, and at least one of the privacy 
mail providers at least allowed their users to opt-in to TLS-Only sending for 
their mails.

We are currently also setting up a website to run our tests against one's own 
ESP/Setup (without me having to dig results out of the logs ;-)), which I'll 
hopefully be able to share soonish.

With best regards,
Tobias

[1] https://www.usenix.org/system/files/atc22-holzbauer.pdf

-Original Message-
From: mailop  On Behalf Of Slavko via mailop
Sent: Wednesday, 23 November 2022 00:13
To: mailop@mailop.org
Subject: Re: [mailop] tls certificates

Dňa 22. novembra 2022 21:00:36 UTC používateľ "Gellner, Oliver via mailop" 
 napísal:

>Also the number of MTAs that require STARTTLS is not increasing based on my 
>experIence. I haven’t seen a large ESP which enforced TLS for all incoming and 
>outgoing connections yet.

Are you aware that even change from 1 to 2 means grow?

I didn't write if requiring TLS is in most of servers, nor that is required by 
a lot of servers, but i see grow in logs (over time), where host try STARTTLS 
and when it fails, they go away without fallback to plain.

I inspect them mostly only by checking its hostname, and as they are not 
"important" for me, i mostly ignore them. But i remember one from DE, which was 
"important" and required exception from my side.

regards


--
Slavko
https://www.slavino.sk/
___
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] tls certificates

[Slavko via mailop]

Dňa 22. novembra 2022 21:00:36 UTC používateľ "Gellner, Oliver via mailop" 
 napísal:

>Also the number of MTAs that require STARTTLS is not increasing based on my 
>experIence. I haven’t seen a large ESP which enforced TLS for all incoming and 
>outgoing connections yet.

Are you aware that even change from 1 to 2 means grow?

I didn't write if requiring TLS is in most of servers, nor that is required by
a lot of servers, but i see grow in logs (over time), where host try STARTTLS
and when it fails, they go away without fallback to plain.

I inspect them mostly only by checking its hostname, and as they are not
"important" for me, i mostly ignore them. But i remember one from DE, which
was "important" and required exception from my side.

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

[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] tls certificates

[Gellner, Oliver via mailop]

> On 21.11.2022 at 15:05 Slavko via mailop  wrote:
>
> To make **everyone** happy with your certificate/TLS, you have to ensure
> all possible combinations:
>
> + valid certificate chain (for those requiring it)
> + valid SAN name (for those requiring it)
> + valid DANE TLSA record  (for those requiring it)
> + valid MTA-STS settings  (for those requiring it)
> + accept plain connections (for those doing fallback)
>
> IMO nobody know how many servers require particular TLS settings,
> but AFAIK the number of these requiring at least some of that grows, thus
> providing valid certificate can be required minimum in near future.

Setting up DANE and MTA-STS for your domains together with valid certificates 
is always a good idea, but I don’t know a single sender who requires that - 
outside of closed environments and bilateral setups.

Also the number of MTAs that require STARTTLS is not increasing based on my 
experIence. I haven’t seen a large ESP which enforced TLS for all incoming and 
outgoing connections yet.

Maybe Julian cares to share which banks server he suspects to have problems 
with unencrypted connections, so the other list members can check their logs 
for this domain.

—
BR Oliver



dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
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] Massive bounce report campaign

[Jarland Donnell via mailop]

I would block the recipient domains at the MTA level and cut out the IP 
rate limiting for a while. An MTA should be able to handle the rejection 
for the domain fine. I do the same with exim when a user tries to give 
me the job of mass forwarding bounces, I just won't do it. In my mind a 
flood of bounces means bad behavior and I justiy the block by refusal to 
participate in whatever it is they're doing.


I don't think you're crazy here at all, if half of your job suddenly 
becomes forwarding bounce emails that's just not a good look.


On 2022-11-22 04:54, Cyril - ImprovMX via mailop wrote:

Hi!

I would appreciate your help on a bad issue we are having.

We are facing a very large amount of connections from Outlook, in the
order of 50k connections per minute (whereas the second "most active"
server is at 100).

Upon investigation, we discovered that one of our users is a
mass-sending email service (such as Mailgun; it seems legit in
itself), and they created one domain per client to handle bounce
reports, such as sp-bounce.{client's domain}.

Since the MX of these domains points to our server, any bounce report
sent is sent to our server. (Our service is a forwarding email, so
once we get the email, we forward it to the above user). (I'll add a
comment on this right after)

The problem is that I don't see how we can stop Outlook from sending
all these bounce reports to us. I thought about updating the SPF to
block that sender from including us, but we don't manage their DNS.

Right now, what we've done is to stop accepting connections from a
sender (in this case, Outlook) after an abnormal amount of connections
per a given period, but this doesn't avoid the fact that Outlook still
tries to connect to us massively, and also impact our regular users
that receive emails from Outlook sender legitimately.

What I'm hoping by reaching out to you is to hope someone has already
faced something similar and has some suggestions on how to mitigate -
or ideally block - this.

This could be a pretty well DDoS attack done by mail servers.

On the comment above regarding the bounce report being sent: That is
my suspicion, by looking at the domain names (sp-bounce), the email it
receives, and the sender activity. But maybe there is another logical
explanation I'm missing!
I mean, to have 50k connections per minute to deliver bounce reports
means that the running campaign must be in the order of millions of
emails just for Outlook!

All help is deeply appreciated!!!

Thank you all in advance.

Best regards,
Cyril
___
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] Massive bounce report campaign

[Michael Peddemors via mailop]

Delayed bounce.. hehehe.. It's called 'backscatter', no matter what the 
source is..


And Outlook should not be doing that, but it does in very specific 
cases.  Of course, the problem is you customer ultimately, but 
backscatter is bad, and that issue you can and should bring up with Outlook.


But you will have to provide more information to the list, eg exactly 
what do those 'backscatter' messages look like, before you can get any 
valuable hints from members on this list.


-- Michael --

On 2022-11-22 08:17, Bill Cole via mailop wrote:

On 2022-11-22 at 05:54:21 UTC-0500 (Tue, 22 Nov 2022 11:54:21 +0100)
Cyril - ImprovMX via mailop 
is rumored to have said:


Hi!

I would appreciate your help on a bad issue we are having.

We are facing a very large amount of connections from Outlook, in the 
order

of 50k connections per minute (whereas the second "most active" server is
at 100).

Upon investigation, we discovered that one of our users is a mass-sending
email service (such as Mailgun; it seems legit in itself),


LOL.

Mailgun sends a LOT of spam. I reject their traffic by default. No 
complaints.


"Seems legit" is obviously in the eye of the beholder...


and they created
one domain per client to handle bounce reports, such as 
sp-bounce.{client's

domain}.


Is that within the bounds of your service terms for that customer?

If not, and/or if you're not able to deliver all of those bounces to 
them (AS YOU SHOULD) then you need to talk to them about changing their 
behavior or finding a provider willing and able to abet their behavior.


Since the MX of these domains points to our server, any bounce report 
sent

is sent to our server. (Our service is a forwarding email, so once we get
the email, we forward it to the above user). (I'll add a comment on this
right after)

The problem is that I don't see how we can stop Outlook from sending all
these bounce reports to us. I thought about updating the SPF to block 
that

sender from including us, but we don't manage their DNS.

Right now, what we've done is to stop accepting connections from a sender
(in this case, Outlook) after an abnormal amount of connections per a 
given
period, but this doesn't avoid the fact that Outlook still tries to 
connect
to us massively, and also impact our regular users that receive emails 
from

Outlook sender legitimately.


That's very bad.

Your customer should be accepting and dealing with every single one of 
those  bounces. If part of that is your job, you are preventing them 
from the most basic good practice for senders. If you can't handle it, 
you shopuld tyell your customer that honestly. What you are doing now is 
harming their reputation as a sender, and they may (or may not) care a 
lot about that.


What I'm hoping by reaching out to you is to hope someone has already 
faced
something similar and has some suggestions on how to mitigate - or 
ideally

block - this.


Firing customers is sometimes necessary. It is better for everyopne 
involvedf than quietly providing shoddy service, as you are now.




This could be a pretty well DDoS attack done by mail servers.


Yes. It may even be intentional. Or just ignorant. Talk to your customer.



On the comment above regarding the bounce report being sent: That is my
suspicion, by looking at the domain names (sp-bounce), the email it
receives, and the sender activity. But maybe there is another logical
explanation I'm missing!
I mean, to have 50k connections per minute to deliver bounce reports 
means

that the running campaign must be in the order of millions of emails just
for Outlook!


No. It could well mean that they have terribly dirty lists and have 
convinced MS that none of their mail should be delivered because they 
are spamming. In some cases, MS365 rejections for spamminess happen 
after MS accepts the message at their boundary but reject when 
attempting final delivery due top customer-specfiic filters. You may be 
seeing a broad judgement from  the people youyr customer is spamming.







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

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

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

Re: [mailop] Massive bounce report campaign

[Bill Cole via mailop]

On 2022-11-22 at 05:54:21 UTC-0500 (Tue, 22 Nov 2022 11:54:21 +0100)
Cyril - ImprovMX via mailop 
is rumored to have said:


Hi!

I would appreciate your help on a bad issue we are having.

We are facing a very large amount of connections from Outlook, in the 
order
of 50k connections per minute (whereas the second "most active" server 
is

at 100).

Upon investigation, we discovered that one of our users is a 
mass-sending

email service (such as Mailgun; it seems legit in itself),


LOL.

Mailgun sends a LOT of spam. I reject their traffic by default. No 
complaints.


"Seems legit" is obviously in the eye of the beholder...


and they created
one domain per client to handle bounce reports, such as 
sp-bounce.{client's

domain}.


Is that within the bounds of your service terms for that customer?

If not, and/or if you're not able to deliver all of those bounces to 
them (AS YOU SHOULD) then you need to talk to them about changing their 
behavior or finding a provider willing and able to abet their behavior.


Since the MX of these domains points to our server, any bounce report 
sent
is sent to our server. (Our service is a forwarding email, so once we 
get
the email, we forward it to the above user). (I'll add a comment on 
this

right after)

The problem is that I don't see how we can stop Outlook from sending 
all
these bounce reports to us. I thought about updating the SPF to block 
that

sender from including us, but we don't manage their DNS.

Right now, what we've done is to stop accepting connections from a 
sender
(in this case, Outlook) after an abnormal amount of connections per a 
given
period, but this doesn't avoid the fact that Outlook still tries to 
connect
to us massively, and also impact our regular users that receive emails 
from

Outlook sender legitimately.


That's very bad.

Your customer should be accepting and dealing with every single one of 
those  bounces. If part of that is your job, you are preventing them 
from the most basic good practice for senders. If you can't handle it, 
you shopuld tyell your customer that honestly. What you are doing now is 
harming their reputation as a sender, and they may (or may not) care a 
lot about that.


What I'm hoping by reaching out to you is to hope someone has already 
faced
something similar and has some suggestions on how to mitigate - or 
ideally

block - this.


Firing customers is sometimes necessary. It is better for everyopne 
involvedf than quietly providing shoddy service, as you are now.




This could be a pretty well DDoS attack done by mail servers.


Yes. It may even be intentional. Or just ignorant. Talk to your 
customer.




On the comment above regarding the bounce report being sent: That is 
my

suspicion, by looking at the domain names (sp-bounce), the email it
receives, and the sender activity. But maybe there is another logical
explanation I'm missing!
I mean, to have 50k connections per minute to deliver bounce reports 
means
that the running campaign must be in the order of millions of emails 
just

for Outlook!


No. It could well mean that they have terribly dirty lists and have 
convinced MS that none of their mail should be delivered because they 
are spamming. In some cases, MS365 rejections for spamminess happen 
after MS accepts the message at their boundary but reject when 
attempting final delivery due top customer-specfiic filters. You may be 
seeing a broad judgement from  the people youyr customer is spamming.




--
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 (and other email security protocols) Survey

[Todd Herr via mailop]

On Mon, Nov 21, 2022 at 2:00 PM Taejoong (tijay) Chung via mailop <
mailop@mailop.org> wrote:

> Greetings,
>
> The Sender Policy Framework (SPF) is an easy way to check whether the
> sender is authorized to send emails – however, it may cause some security
> holes if it causes too many DNS lookups.
>
> Together with researchers from Virginia Tech and Max-Planck-Institut für
> Informatik, we would like to understand which challenges operators face
> when configuring the proper limit of DNS queries for SPF lookups and when
> deploying other email security protocols.
>
>
>
I'm not quite sure I understand the premise behind the survey, and since I
don't manage email for any domain, I can't realistically take part in the
survey to learn the premise, so I'll try here.

The proper limit of DNS queries for SPF lookups is ten, per RFC 7208, and
*should* be baked into any code library used by an operator that is doing
SPF validation on inbound mail, so I don't see them facing challenges here.

On the other hand, staying under the limit of ten for domains publishing
SPF records can be quite a challenge for complex organizations using
multiple services to send their email, and while there are known ways to
skin that cat, there isn't a universally adopted method for doing so.

Is the survey investigating problems faced by operators doing SPF
validation or operators publishing SPF records or both?

-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Massive bounce report campaign

[Laura Atkins via mailop]

> On 22 Nov 2022, at 11:39, Peter N. M. Hansteen via mailop  
> wrote:
> 
> On Tue, Nov 22, 2022 at 11:54:21AM +0100, Cyril - ImprovMX via mailop wrote:
>> I mean, to have 50k connections per minute to deliver bounce reports means
>> that the running campaign must be in the order of millions of emails just
>> for Outlook!
> 
> 50k bounces per minute is abnormal, that's for sure.

Agreed. I have clients who send tens of millions of emails a day and don’t get 
50K delayed bounces. Most well configured systems don’t send delayed bounces, 
they reject inline. I’m not even sure how they’re getting the bounces from 
Outlook, as most are handled inline. 

> This sounds to me like your customer is using a really bottom of the 
> barrel spamto: list (on par with our bait list, to be found at 
> https://www.bsdly.net/~peter/traplist.shtml, which serves a 
> slightly different purpose).

Yeah, the customer is a problem and needs to go away. 

> I would attack the problem at its source (your customer) and find out
> what they thought they were doing.

Or just tell them that their contract doesn’t allow for this type of mail 
handling. But, really, this isn’t a customer worth keeping. This is not 
accidental.

laura 

> 
> - Peter
> 
> -- 
> Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/
> "Remember to set the evil bit on all malicious network traffic"
> delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog  






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

Re: [mailop] Massive bounce report campaign

[Peter N. M. Hansteen via mailop]

On Tue, Nov 22, 2022 at 11:54:21AM +0100, Cyril - ImprovMX via mailop wrote:
> I mean, to have 50k connections per minute to deliver bounce reports means
> that the running campaign must be in the order of millions of emails just
> for Outlook!

50k bounces per minute is abnormal, that's for sure.

This sounds to me like your customer is using a really bottom of the 
barrel spamto: list (on par with our bait list, to be found at 
https://www.bsdly.net/~peter/traplist.shtml, which serves a 
slightly different purpose).

I would attack the problem at its source (your customer) and find out
what they thought they were doing.

- Peter

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Massive bounce report campaign

[Cyril - ImprovMX via mailop]

Hi!

I would appreciate your help on a bad issue we are having.

We are facing a very large amount of connections from Outlook, in the order
of 50k connections per minute (whereas the second "most active" server is
at 100).

Upon investigation, we discovered that one of our users is a mass-sending
email service (such as Mailgun; it seems legit in itself), and they created
one domain per client to handle bounce reports, such as sp-bounce.{client's
domain}.

Since the MX of these domains points to our server, any bounce report sent
is sent to our server. (Our service is a forwarding email, so once we get
the email, we forward it to the above user). (I'll add a comment on this
right after)

The problem is that I don't see how we can stop Outlook from sending all
these bounce reports to us. I thought about updating the SPF to block that
sender from including us, but we don't manage their DNS.

Right now, what we've done is to stop accepting connections from a sender
(in this case, Outlook) after an abnormal amount of connections per a given
period, but this doesn't avoid the fact that Outlook still tries to connect
to us massively, and also impact our regular users that receive emails from
Outlook sender legitimately.

What I'm hoping by reaching out to you is to hope someone has already faced
something similar and has some suggestions on how to mitigate - or ideally
block - this.

This could be a pretty well DDoS attack done by mail servers.

On the comment above regarding the bounce report being sent: That is my
suspicion, by looking at the domain names (sp-bounce), the email it
receives, and the sender activity. But maybe there is another logical
explanation I'm missing!
I mean, to have 50k connections per minute to deliver bounce reports means
that the running campaign must be in the order of millions of emails just
for Outlook!

All help is deeply appreciated!!!

Thank you all in advance.

Best regards,
Cyril
___
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] SPF (and other email security protocols) Survey

[Alessandro Vesely via mailop]

On Tue 22/Nov/2022 02:17:14 +0100 L. Mark Stone via mailop wrote:

IMHO, asking me to grant rights before I know to what it is that I am granting 
rights is, at best, not nice.


What right(s) did you (omit to) grant?

The first page questions were about consent to participate and understanding 
the nature of the survey.



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