On Saturday, April 20, 2019 05:04:24 PM Peter wrote: > On 20/04/19 4:46 PM, Scott Kitterman wrote: > > RFC 6376 suggests signing the sender field if present. It says nothing > > about adding it. For that you want RFC 5322, Section 3.6.2. (Originator > > Fields). > > > > Unless a third party is transmitting mails to a mailing list on your > > behalf, it shouldn't be there. > ...and I never said anything about adding it either. We're talking > about what fields to sign, not whether they should be added or exist in > the message prior to signing. RFC 6376 does go on to say that headers > can be signed that are not present to enforce that they not be added later. > > Granted in this particular case, and given what Sender is for, it > probably shouldn't be signed if it's not present, but the RFC does not > make that explicitly clear, and I would not hold someone at fault for > signing the Sender header based on what that RFC says. > > But this is just one example of where a header might be signed and then > is later added or altered by the mailing list, thereby invalidating the > signature. I'm sure there have been others as I regularly see mail from > this list end up in Spam and my point remains that this seems to be an > issue that will only get worse in the future, not better. > > At the end of the day, messages from this list are ending up in people's > Spam folder, or are not being delivered at all. We can go on all day > pointing the finger at the sender but that really won't solve the issue > in general, because there will always be another sender who breaks the > rules or doesn't get it, or can't actually control this stuff for their > email.
If you signed a non-existent sender field and send mail to a mailing list that (not atypically adds it) and your signature is broken, look in the mirror for the source of the problem. It's neither the mailing list nor the RFCs. I'm done. Scott K
