Re: New "Old-" headers emerging from the horizon

Bernd Wurst writes:

> Am 27.01.24 um 15:00 schrieb Sam Varshavchik:
>> The problem I see here is this part:
>> # If the original email message had a DKIM signature, it has already been
>> # evaluated. Removing the BIMI-Location header at this point should not
>> # invalidate the signature since it should not be included within it per this
>> # spec.
>>
>> It's fairly simple to adjust the headers upon receipt, in submit.C, where  
>> all the other headers are renamed to Old-.
>>
>> But then that's what the mail filter will see.
>
> According to the spec, those two headers, BIMI-Location and BIMI-Indicator  
> are not supposed to come from the sender but are set by the (last) receiving  
> MTA to tell "its MUA" which logo to display. This is done by checking the  
> validity of the other BIMI-headers.

Correct, and the receiver is supposed to rename any existing headers of that  
name, like Authentication-Results get renamed to Old-Authentication-Results.

But that will break the DKIM Signature.

> As long as a server does not have BIMI validation functionalty or has no MUA  
> that trusts it, it seems to be completely irrelevant if those headers are  
> removed or not.

Well, I'm not well versed in the intricacies of DKIM but the spec explicitly  
states that any existing headers need to be renamed but only after  
validating the DKIM signature.

I guess what that means is that Courier will leave this alone and leave it  
up to the DKIM filter to munge the headers.

> Maybe the MTA should just leave those headers alone and if someone  
> implements a BIMI validation filter, this filter should take care to remove  
> those old headers and just put his new ones in place.

I can easily see this unfold like this:

• The MUAs will start automatically assuming that these headers, if present,  
are validated by the mail server and automatically display branded logos.

• Most existing mail servers – except the ones maintained by the big mail  
providers – don't care about this nonsense, and they ignore everything and  
are unaware of any of this silliness. But the MUAs that fetch mail from  
the servers will automatically display branded logos if they find these  
headers on downloaded mail.

• Spambags will manually inject forged headers and MUAs will obediently  
display branded logos on forged mail.

• Fingers will be pointed at the ISPs – it's their fault that their mail  
servers accept forged headers and don't delete them.

• Everyone will get harassed into supporting this junk.

What will be interesting to see is what happens with second-tier mail  
providers, not the big ones, but the handful of paid, security-oriented mail  
services like Protonmail. What are they going to do about it.

I think they have a good argument for not playing along, stripping off any  
existing headers (this practice will be consistent with their mission  
statement) but do NOT put validated headers on their clients' mail, from a  
privacy-oriented point of view. I can see how this feature can be abused to  
track individual mail users who are using services like Protonmail as a  
privacy shield. This "feature" pierces their anonymity and exposes their IP  
address to the mail sender!

So, I think Protonmail will flip this one the finger. If they're smart,  
instead of putting the certified brand's headers, they'll put one pointing  
to THEIR logo, a generic "validated sender" logo, and the dumb MUAs will  
happily put it up next to the email!

_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQRupkKLJP96aW75pIOKYPgoojZS4gUCZbWXXQAKCRCKYPgoojZS
4n71AQDeFhdLkedlNqhFEUeU/ncn6uAvt0Qr3vsVP80vCHuwfQEA3S/OB57gl4pg
Gr2BgoFaPrLygaKG29qWqBR1p7JPdA8=
=MS/7
-----END PGP SIGNATURE-----