>>just because SPF and DMARC are so badly designed that they can't handle it >>doesnt make it "forging" anything.
It isn't badly designed. Forwarding a email, is the equvalient of, when you receive a signed envelope from me containing a letter, you forge my signature on the new envelope. That people have doing it for 40 years, doesn't make it right today. We had open relay servers for 30-40 years too, but times have changed. Now every public facing SMTP that offers relay is password protected for obvious reasons. So its time to change our views of whats the "correct" way to forward an email. We need a new standard, that does work with SPF, even when DMARC is set to strict identity alignment which means also "MIME From:" must be rewritten. Of course, lets go back to that signed envelope again. For obvious reasons, you can't forward the envelope, as you needed to open it and destroy the seal, to know where it should go. What you do then, is write YOUR signature on the envelope with a statement that you verified my signature on the previous envelope. That’s what the "new era" forwarding is, where you encapsulate the new email in a new message/rfc822 object. If you don't want the receivers of your forwardings to have to click an message attachment, you can also forward in the following fashion: From: Replace with <old-To> (ergo the account email was originally sent to, which has a forward configured) To: Replace with <configured-forward-account-for-old-To> Reply-To: If non-existent or empty, Replace with <old-From> X-Original-From: <old-From> Subject: Add "Fwd: " to <old-Subject>. Delete any DKIM (as they are now invalid) and resign the email with your DKIM and DMARC. This however, destroys the integrity of the original email, but that gives the most transparent behaviour. So it’s a give or take there, either forward it as a encapsulation (message/rfc822 object in a new container), but then receiver has to click an attachment. Advantages --> Preserves the original email in its original format, unmodified in a new container with the rewritten headers. Disadvantages --> Every email will look like an empty email containing a attachment that you have to click to open. Or you could rewrite headers in-place, but then you lose integrity: Advantages --> Receiver does not need to click an attachment. Disadvantages --> The integrity of the original email is lost. Also, that’s how forwarding ALWAYS have work when you press the "Forward" button (and "Forward as attachment" is the message/rfc822 way) in your MUA and have always worked with SPF and DKIM for decades. So why shouldn't we adopt it also for server-configured forwarding? Best regards, Sebastian Nielsen _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
