On 2022-01-01 09:14, Peter wrote:> 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:
its basicly just statistik you say above
>
> 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
> 2. Other anti-spam measures to try to absolutely minimize the amount
> of SPAM that you end up forwarding.
its possible to unsubscribe
> 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.
makes things worse
> 4. Rewrite the From: header to your domain name, add a Reply-To
> header with the original From: header's content.
makes things worse
> 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
> 6. DKIM sign the message from the domain you rewrote the From: header
> to.
perfect forged mail can be tested in dkim adsp
> 7. Rewrite the envelope sender to your domain name.
normal for maillists, does not break spf specs
> 8. Send out the message.
and hope for no spf helo, spf pass if its spam :)
> The above assumes properly implemented SPF, DKIM and DMARC records for
> your domain.
define 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
we are OFF Topic, take debate offline from maillist