On 7/3/2014 8:32 PM, Pete Resnick wrote:
On 7/3/14 12:20 PM, Pete Resnick wrote:
On 7/3/14 at 11:26 AM, Andrew Sullivan wrote:
On Thu, Jul 03, 2014 at 11:22:18AM -0500, Pete Resnick wrote:
Oh, I forgot one thing:
The working group will seek to maintain
the viability of stable domain-level identifiers in mail, and will
document existing mail streams that do not conform to the DMARC
model.
I'm not sure what this means. Can someone explain?
I still don't understand. Can we just strike this text?
I'll bet a pretty good lunch that it's the way of saying, "Rewriting
localp...@example.tld to localp...@example.tld.invalid is not
allowed." That's something that people have started doing for mailing
lists. But I can't say for sure that's what it means.
Oh. If so, perhaps we could come up with a slightly less obscure way
of saying it?
Well, nobody has stepped up to the plate to help, so I'm going to go
with the following:
"As the working group develops solutions to deal with indirect mail
flows, it will seek to maintain the end-to-end nature of existing
identifier fields in mail, in particular avoiding solutions that
require rewriting of originator fields."
If you've got concerns with that, we'll take them up as "comments to
the IESG on the proposed charter."
I know this is just being all being ignored. Maybe you are reading it.
But it has to go on the record.
There should not be any advocation for any form of 5322.From
tampering, ever, especially as a justification for bypassing a
security protocol, EVER. I have a hard time that I even have to
bother to highlight it. Like you, I've been doing mail systems for
30+ years, predating 822. This is a shop stopper (ignore this work)
and also put pressures on IETF appeals.
This already highlights the need to add new rewrite filtering checks
in the security section. Its worst than the multiple 5322.From
theoretical potential exploit. Its more realistic that it can happen
with folks with an negative affinity towards author domain policies.
It puts ethical engineering pressure on list developers that we really
should not be confronted with. We don't want to encourage this type
of mail tampering practice. Please lets not crack up this door,
Pandora Box, can of worms, etc, etc. As a core mail principle, it
MUST NEVER be valid to tamper with 5322.From, especially as a way to
bypass a security protocol.
The entire idea needs to be out of scope.
--
HLS
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
