On 12-30-2021 10:11 am, Benny Pedersen wrote: On 2021-12-30 12:58, Aki Tuomi wrote:

...

...

On 30/12/2021 06:38 Benny Pedersen me@junc.eu wrote: would be nice to see added :=) talvi.dovecot.org txt "spfv1 a -all" Why?

dkim fails here spf is more stable results from current msg

DMARC breaks on dovecot mailing list. DMARC does not break on postfix mailing list. Having a mailing list that doesn't break DMARC is possible.

Maybe ask Wietse how he does it :)

On 2021-12-30 16:35, Felix Zielcke wrote:

But dovecot mailing list uses ARC Headers. And they seem to verify for me (using rspamd)

arc does not need spf or dkim on the forwarding host

problem i report is that spf helo pass is missing, and this is not an issue for arc at all

Am Donnerstag, dem 30.12.2021 um 17:07 -0500 schrieb dovecot@ptld.com:

...

On 12-30-2021 10:35 am, Felix Zielcke wrote:

But dovecot mailing list uses ARC Headers. And they seem to verify for me (using rspamd)

I have not fully studied ARC, but from briefly looking isn't ARC just a way for the sending server to attest to the email it is relaying as being legit? So if the sending server is a spam server couldn't it lie and claim the mail is legit? If that is the case I'm not sure what the point of ARC is, how does it prevent fraud? Its like asking a liar if they are lying and taking their word for it. And i assumed this is why ARC never really took off.

Spam senders can setup valid SPF + DKIM too. The only difference is a malicous relay could make ARC headers for e.g. microsoft.com even though DKIM didn't pass. So yeah you need more trust with ARC. But I think you can trust the dovecot mailing list server.

On 1/01/22 12:56 am, Benny Pedersen wrote:

if maillist all did the arc seal/ arc sign, before thay break dkim, then its still possible to verify orginal sender trust, bingo

its just sad nearly all make it worse by dkim sign all forwarded mails, thay miss the dkim private key mostly to do this, no ? :=)

The problem is there is a not insignificant number of recipient MTAs that check SPF/DKIM/DMARC but do not recognize ARC yet. If you rely on ARC signing then these MTAs will likely reject your mail. This means that the only reliable way to pass SPF, DKIM and DMARC if you're forwarding mail is:

1. Check the inbound SPF, DKIM and DMARC and reject the mail if it doesn't pass.

2. Other anti-spam measures to try to absolutely minimize the amount of SPAM that you end up forwarding.

3. Remove any existing DKIM signature that includes the From: or Reply-To: headers or any other header or content that you will be modifying in the message.

4. Rewrite the From: header to your domain name, add a Reply-To header with the original From: header's content.

5. Do any other alterations, such as adding list-* headers modifying the Subject: header, etc.

6. DKIM sign the message from the domain you rewrote the From: header to.

7. Rewrite the envelope sender to your domain name.

8. Send out the message.

The above assumes properly implemented SPF, DKIM and DMARC records for your domain.

That is the *only* way you can be fully certain that the forwarded message will pass SPF, DKIM and DMARC checks and therefore have the best chances of being received by the recipient. Anything else relies on implementation specifics of the sender and/or the recipient MTAs which may or may not make that possible.

Peter

On 1/01/22 9:57 pm, Benny Pedersen wrote:

its basicly just statistik you say above

You seem to think you can just ARC sign the message and everything will be rosy. This is not the case, ARC needs to be implemented on the receiver side or it will be completely ignored. It will takes yeras for it to be widely adopted.

...

1.  Check the inbound SPF, DKIM and DMARC and reject the mail if it doesn't pass.

check spf helo, spf mfrom, check dkim, check arc in that order, but do not reject, current its only meta data collected to dmarc policy with can reject if sender wants it rejected, but this should relly not be rejected if its arc-signed / arc-sealed, this indicate a maillist where reject is not best way to solve spamming

Sure check for ARC as well. The point is to reject anything that might be SPAM because you are going to be DKIM signing it yourself and you don't want to be forwarding SPAM.

...

2.  Other anti-spam measures to try to absolutely minimize the amount of SPAM that you end up forwarding.

its possible to unsubscribe

So you expect a spammer to unsubscribe?

makes things worse makes things worse

And yet as I said, it's the only way to guarantee that the message will pass on the recipient side. ARC won't do that. I didn't say it was a great solution, I said it's the *only* solution.

...

5.  Do any other alterations, such as adding list-* headers modifying the Subject: header, etc.

does not break dkim when adding new headers, but change signed headers does

Wrong. Adding headers *can* break dkim. This is because the lack of headers or NULL headers can be signed.

...

6.  DKIM sign the message from the domain you rewrote the From: header to.

perfect forged mail can be tested in dkim adsp

Which is why you check the original signature and reject if it doesn't pass.

...

7.  Rewrite the envelope sender to your domain name.

normal for maillists, does not break spf specs

It's something that you have to explicitly tell your MTA to do, and it certainly wasn't "normal" before SPF was a thing.

...

8.  Send out the message.

and hope for no spf helo, spf pass if its spam :)

Again, why you try to reject SPAM to begin with.

...

The above assumes properly implemented SPF, DKIM and DMARC records for your domain.

define properly

I'm not going to go into that level of detail here. There are many many resources on the internet which can tell you how to set up these thigns properly.

...

That is the *only* way you can be fully certain that the forwarded message will pass SPF, DKIM and DMARC checks and therefore have the best chances of being received by the recipient.  Anything else relies on implementation specifics of the sender and/or the recipient MTAs which may or may not make that possible.

you need more meta data on diffrent maillists if you write this above

Nope, this has nothing to do with the mail list. This has to do with different practices of the sending MTA and recipient MTA. The mail list sits in-between the two and must reconcile with various different policies of the sender (which can be determined) and how the recipient will check those policies (which generally cannot be determined).

we are OFF Topic, take debate offline from maillist

By all means. Just stop trying to claim that ARC will solve all the problems, it won't. I realize that mailing lists likely do not want to implement all of the above steps, but ARC is not a magic bullet that can fix the issues shown, there is no magic bullet and so you either accept that a number of messages will, depending on circumstances, not make it to the recipient, or you take drastic measures to resign everything so that the recipient MTA is happy.

Peter

On 31/12/21 4:32 am, dovecot@ptld.com wrote:

DMARC breaks on dovecot mailing list.

That is not always the case. Indeed your message explicitly passes DMARC.

DMARC does not break on postfix mailing list.

This is not true either. I have had several messages fail DMARC from the postfix list.

Having a mailing list that doesn't break DMARC is possible.

Yes, but it requires rewriting the From: header (among other things).

Having an SPF entry for the HELO domain, while it wouldn't hurt, will not help with DMARC. DMARC will only look at it if the domain matches the domain in the From: header, and so unless the message has a From: header with a dovecot.org domain then no amount of SPF records under dovecot.org will help here.

The reason that the postfix list (and indeed this list) often times passes DMARC is because the messages are forwarded un-altered, and as such the DKIM signature passes. As long as teh message is originally DKIM signed by the same domain as that in the From: header then it will pass DMARC regardless of SPF. This, of course, is heavily dependent on the proper usage of DKIM by the original sender.

Peter