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
