On 22/07/2016 13:24, ned+ietf@xxxxxxxxxxxxxxxxx wrote: > >> On Jul 21, 2016, at 12:43 PM, ned+ietf@xxxxxxxxxxxxxxxxx wrote: > >>>> On 7/21/2016 7:35 AM, Brian E Carpenter wrote: >>>>> Yes. So I repeat the question: Since the most pragmatic, non-purity-based >>>>> solution is to rewrite the sender field for mail from p=reject (or p=quarantine) >>>>> domains, when will we change the IETF and IRTF mailmen to do so? >>> >>> >>>> I'm sure you really meant this, but just to be careful, what with this >>>> being a technical point in a technical forum, it's worth clarifying that >>>> the rewriting is for the rfc5322.from field and not the rfc5322.sender >>>> field. >>> >>> I have an additional suggestion. >>> >>> If we're going to do this - and I'm not going to offer an opinion on whether or >>> not it should be done - I'd like to see it done in a fashion that's both >>> detectable and reversible. That way people using sieve or procmail or whatever >>> will be able to undo the damage. >>> >>> The most straightforward way to accomplish this would be to make copies of the >>> original fields with different names, but of course many other approaches are >>> possible. > >> I do not see MailMan settings to make that happen. Maybe I missed something... > > That's most unfortunate, and I have to say moves my position from neutral > to "don't do it". > > Reversible damage is one thing, irreversible damage another. That's the dilemma. An agent that obeys p=reject does irreversible damage too. I can figure out how to live with p=reject being treated as p=quarantine, but not with "reject means reject". And it isn't just me, it's every IETFer using a certain mail operator that has threatened to obey p=reject Real Soon Now. Brian Brian