►
From YouTube: IETF108-DMARC-20200728-1300
Description
DMARC meeting session at IETF108
2020/07/28 1300
https://datatracker.ietf.org/meeting/108/proceedings/
A
Good
morning
or
good
afternoon,
good
evening,
everyone,
so
this
is
debug
session.
We
have
50
minutes
today.
A
A
Right
so
hopefully
for
people
who
just
got
presentation
the
these
whole
pointers
to
them.
Where
minutes
are
being
taken,
jabber
room,
if
you're
in
mitako,
you
will
automatically
appear
in
the
jabra
room.
So
that's
fine.
This
session
is
being
recorded
and
we're
using
metacore,
which
is
different
from
webex.
We
use
last
time
people
don't
need
to
fill
in
blue
sheets.
They
are
automatically
being
generated
from
the
techo.
A
Just
a
reminder,
so
we
are
part
of
atf.
We
are
following
itf
notwell,
which
covers
ipr
as
well.
We
have
record
we'll
have
recordings
audio
and
video
recordings
of
this
event
also
be
nice
to
each
other
be
respectful.
A
Hopefully
this
session
is
not
going
to
get
too
heated.
So
please,
please
remember
that,
and
next
slide
has
details
with
all
is
covering
that
next
slide.
A
So
we'll
talk
a
little
bit
about
scope
of
work
and
how
we
want
to
split
documents.
Then
we
have
effectively
two
invited
presentations.
They
are
not
covering
any
of
their
current
or
proposed
dmarc
work,
and
it's
not
even
entirely
clear
whether
they're
in
scope
or
not.
At
this
point,
this
will
be
decided
later
and
if
we
have
time
we'll
get
to
one
to
a
bnf
issue
at
the
end
next
slide,
any
gender
bashing.
B
So
I'll
try
and
keep
this
relatively
concise.
The
dmarc
working
group's
been
chartered
to
go
through
three
phases
of
work.
First,
phase
of
work
was
actually
to
document
interoperability,
issues
caused
by
dmarc
itself.
That
work
was
completed
and
published
as
rfc
7960.
B
The
second
phase
of
work
was
to
address
indirect
mail
flow,
basically
figure
out
a
way
to
handle
what
was
documented
in
rfc
7960
what's
been
published,
is
now
rfc
8617
and
actually
some
of
what
we're
going
to
discuss
today.
The
presentations
from
dave,
crocker
and
murray
are
actually
other
mechanisms
potentially
for
for
handling
indirect
mail
flow,
which
is
a
requirement
for
phase
three,
which
is
to
review
and
refine
the
dmarc
specification
and
get
to
standards
track
and
so
alessandra.
If
you
could
wait
until
we're
done
with
the
scope.
B
And
so
the
the
the
charter
itself
provides
a
pretty
clear
framework
for
what
is
in
scope
for
phase
three
right.
We
want
to
get
to
an
ietf
standards
track
document
again.
Indirect
mail
flow
being
handled
by
dmarc
is
a
must
to
get
the
standards
tracked,
but
primarily
the
updates.
The
document
are
supposed
to
be
based
on
operational
experience
and
with
a
particular
weighting
to
aggregated
data
from
multiple
sources
right.
B
If
a
lot
of
people
are
saying,
this
is
the
impact,
and
that's
really
what
we're
supposed
to
prioritize
as
a
working
group
and
obviously
to
address
any
security
loopholes
that
have
been
uncovered
right
and
then
further
to
preserve
interoperability
with
the
base
dmarc
installed
to
the
greatest
extent
possible
and
to
have
detailed
justification.
B
If
we're
going
to
break
backwards
compatibility,
the
chairs
are
not
looking
to
rewrite
dmark
from
scratch.
We're
not
looking
to
relitigate
why
ydmark
is
important.
The
charter
actually
presupposes
that
dmarc
is
valuable,
and
so
we
can
have
conversations
about
that,
but
it
is
out
of
charter,
and
we
need
to
be
very
careful
here
and
we
need
to
progress
this.
This
work
in
particular
and
finally,
we're
not
looking
to
expand
the
scope
of
dmarc
right.
We
don't
want
to
go
and
address
new
things.
B
B
B
So
we
want
to
talk
about
the
way
the
the
chairs
are
looking
at
splitting
up
dmarc
into
three
proposed
documents.
The
first
document
will
be
the
base
specification,
there's
a
lot
of
nits
and
errata.
We
we
wish
to
review
and
cover,
I
think,
there's
something
in
the
order
of
20
or
30
tickets
related
to
the
base
spec
based
on
operational
experience.
We
want
to
clean
up
or
remove
unused
tags
or
tags
that
have
impact.
That's
not
well
understood,
murray.
Do
you
wanna
jump
in.
C
I
know
I
you
good,
you
can
hear
me
now
it's
where
it
looks
like
it's
sending
yeah
so
you're,
just
saying
on
the
bass
spec,
if
you're
gonna
break
od,
remove
it
from
the
base
back.
Are
we
talking
about
a
possibly
fourth
document,
then.
B
It
potentially,
we
don't
have
consensus
on
what
to
do
with
this
dave.
Crocker
has
a
pretty
extensive
thread
from
when
we
put
psd
through
last
call
about
how
this
should
be
looked
at
and
potentially
removing
od
from
the
base.
Spec
is
actually
part
of
the
charter,
and
so
this
is
deeply
within
scope
and
is
probably
going
to
have
a
very
healthy
discussion
on
lists
when
we
get
there.
C
B
Further
right,
we
really
wanna
now
that
we
better
understand
how
dmarc
is
deployed.
There
were
quite
a
few
assumptions
made
in
the
early
draft
about
who
dmarc
was
relevant
for
and
how
it
worked
in
the
in
the
world
that
we
now
have
operational
experience
that
are
no
longer
correct,
and
so
we
need
to
address
those
deltas
and
then
finally,
we
need
to
incorporate
our
or
something
that
deals
with
indirect
mail
flow
dave
go
ahead.
D
Thank
you,
so
maybe
I
missed
it,
but
has
this
proposal
been
floated
on
the
mailing
list
already.
B
A
Is
because
some
of
this
might
be
revised
quicker
than
others,
so
we
want
to
be
able
to
progress
documents
independently
as
well.
B
Yep-
and
I
actually
want
to
speed
through
this
because
we're
getting
close
to
time-
and
I
want
to
actually
get
dave,
get
your
presentation
so
and
the
the
reason
the
base
spec
is
there
is
we
expect
the
base
set
the
base
spec
to
settle
and
be.
We
want
to
get
that
moving
and
then
for
the
reporting
specs.
B
The
reason
they're
separate
is
we
want
to
make
them
extensible
in
such
a
way
where,
if
we
decide
to
make
changes
to
accurate
reporting
or
failure
reporting
in
the
future,
we
don't
need
to
open
up
the
base
spec
and
make
normative
changes
to
how
dmarc
works.
We're
just
going
to
poke
at
the
reporting
bits,
and
this
will
make
it
not
only
easier
to
progress
documents
today,
but
to
make
changes
in
the
future
in
a
more
targeted
fashion
that
don't
reopen
the
world
and
so
for
for
aggregate
reporting
in
particular
their
nips
and
errata.
B
E
E
Yes,
so
if
policy
and
alignment
right
so
I
I
can
understand
in
the
sort
of
the
what
you're
going
to
align
to
being
in
the
base
spec,
because
that
goes
to
where
you
go
to
try
and
retrieve
a
dmarc
record.
But
this
makes
it
seem
as
though
an
an
implementer
of
aggregate
reporting,
for
example,
is
necessarily
going
to
have
to
have
the
policy
mechanism
as
well
is.
B
E
E
I
I
do
consider
it
to
I.
I
will
we'll
take
it
to
the
list,
because
it's
it's
really
the
policy
part
of
this.
That's
causing
operational
problems,
and
it
would,
I,
I
think,
it's
better
not
to
hold
up
the
the
two
types
of
reporting
mechanisms
to
try
and
get
policy
not
to
not
to
cause
damage
yeah,
but
thanks.
B
B
Yeah
and
then
just
to
wrap
up
the
the
the
final
bit
on
failure
reporting.
There
has
been
discussions
of
stripped-down
failure,
reports
that
just
contain
a
few
pieces
of
information
such
as
to
and
from
headers,
so
people
can
identify
who
mail
is
from
so
they
can
go,
get
it
authenticated
without
going
into
a
the
larger
pii
morass.
That
is
a
full
failure
report
and
then
to
actually
further
document
and
discuss
the
privacy
considerations
inherent
to
failure
reporting,
but
not
the
rest
of
dmarc.
B
And
so
that's
the
proposed
document
structure
and
since
we've
gotten
a
lot
of
questions,
I
think
we're
going
to
move
right
on
to
dave,
and
I
just
want
to
reiterate,
as
alexi
said,
that
we
haven't
decided
as
chairs
whether
or
not
this
document
the
day
is
presenting
will
be
either
document
is,
will
be
part
of
dmarc,
but
we
believe
the
conversation's
essential
to
the
the
requirement
that
dmarc
address
indirect
mail
flow,
and
so
with
that
dave
the
floor
is
yours,
for
I
believe
20
minutes.
D
Good
morning,
oh,
I
guess
I
should
do
this
also
just
or
we're
not
doing
video.
That's
all
right
too,
never
mind
good
morning.
So
the
main
goal
of
working
group
sessions,
the
quote-unquote
face-to-face
ones
like
this-
is
to
actually
have
substantial
discussion
so
I'll
keep
the
summary
super
quick,
because
everybody's
already
read
everything
and
is
completely
familiar.
D
The
the
predicate
to
both
of
my
proposals
is
based
on
the
view
that
dmarc
is
built
on
top
of
a
field
that
has
conflated
semantics.
This
goes
back
to
what
we
did
in
rfc
733
at
the
time.
It
was
perfectly
reasonable
and
worked
okay
for
45
years,
but
it
conflates
the
handling
creator
with
the
content
creator
and
the
the
reality
is.
The
sender
field
was
supposed
to
be
for
the
the
handling
creator.
D
Dmarc
enforces
very,
very
tight
controls
between
the
domain
owner,
the
content
creator
and
the
email
handler.
As
such,
it
really
is
more
about
the
the
sender
type
of
information
than
about
the
author
type
of
information,
but
given
that
dmarc
is
installed
and
heavily
used
in
some
corners
trying
to
go
back
and
make
dmarc,
do
things
completely
differently?
Isn't
going
to
work,
and
so
the
goal
of
these
two
proposals
is
to
add
some
mechanisms
rather
than
replace
mechanisms.
D
The
author
field
simply
creates
a
field
that
is
purely
the
content
creator
and
is
not
subject
to
the
dmarc
mechanisms.
It
can
be
put
there
at
the
time
of
message.
Creation
or
it
could
be
put
there
along
the
path
as
a
mediator
deems
appropriate,
and
I
don't
think
it
needs
any
other
commentary
or,
for
me
at
least.
G
So
quick
question
dave:
do
you
see
the
two
documents
as
completely
independent?
The
working
group
could
choose
to
do
one,
not
the
other,
or
are
they
a
set
they're
completely
independent.
D
I
can
imagine
that
they're
they're
being
complementary
to
each
other,
but
that's
not
required.
I
love
that
answer.
E
E
Dave
question
looking
looking
at
these
somewhat
cursorally,
but
it
it
seems
like
these
are
things
more.
I
I
interpret
these
as
suggestions
for
the
dmarc
based
specification
rather
than
as
independent
documents.
Do
you
do
you
foresee
these
as
surviving,
and
you
know
perhaps
being
published
as
as
independent
rfcs,
or
is
this
kind
of
a
an
interim
step
just
to
get
some
suggestions
out
there.
D
The
author
proposal
is
completely
independent
of
dmarc.
It
may
have
it
actually
made
a
point,
I
think,
of
not
mentioning
dmarc
explicitly.
It
alludes
to
the
issues
that
dmarc
raises.
D
That's
intentional
because
it
it's
a
field
that
can
be
useful
and
operate
completely
independent
of
dmarc
and
in
fact,
I
think
it
ought
to
be
kept
outside
of
dmarc,
we'll
get
into
the
sender
one
when
we
get
into
this
under
one.
D
H
B
And
mike,
if
I
may
and
dave
correct
me
if
I'm
wrong,
but
the
point
here
is:
if
you
actually
have
the
author
field,
then
mailing
lists
sdgs
can
do
whatever
they
want
to
the
message
change
the
from
and
you
could
still
authenticate
against
the
original
handler.
And
that
way
we
don't
need
the
complexity
of
arc,
but
it
would
need
to
be
widely
deployed
to
be
effective.
Is
that
roughly
correct.
D
I
I
I
would
amend
aggressively
to
remove
the
reference
to
arc,
I'm
not
saying
anything
about
arc.
I
I
don't
have
an
opinion.
D
G
G
Oh
okay,
good!
We
won't
get
there
because
that
was
my
only
comment
about
it.
As
far
as
the
author
document,
I
I've
got
real
concerns
about
the
author
document,
because
I
fear
that
what
we
will
have
done
is
created
another
field
which
will
have
information
that
purportedly
can
be
shown
to
the
user
in
a
ui.
G
Some
protocol
will
come
along
and
do
exactly
what
was
done
to
from
which
is
make
it
an
identifier.
That's
going
to
be
used
in
some
way
that
people
are
not
going
that
it's
going
to
have
to
be
verified
that
it's
going
to
have
to
do
with
sending
I'm
thinking
back
to
the
days
of
x-sender,
which
initially
was
put
in
there,
because
people
wanted
a
place
to
put
the
pop.
G
Of
the
sending
user
and
people
started
actually
using
that
field,
which
resulted
in
x-x-dash
sender,
I
think
we're
just
opening
ourselves
up
to
something
bad
happening
in
the
future.
Better
to
do
something
like
sender
is
proposing
than
to
try
to
make
another
field
to
put
the
semantics
that
from
actually
had
in
the
first
place
on
the.
D
Average
doing
protocol
development
that
that
is
modified
by
a
fear
that
somebody
at
some
point
in
the
future
might
do
something
that
isn't.
Okay
strikes
me
as
problematic.
I.
D
Nature
of
this
field
is
very
simple
and
we've
gone
a
long
time
with
a
field:
the
use
of
a
field-
that's
quite
similar.
It's
only
recently
that
that
became
a
problem
and
it
became
a
problem
because
somebody
tried
to
deal
with
it
and
we
discovered
a
conflating
semantic
there.
That
hadn't
been
a
problem
before,
but
is
a
problem.
Now
this
deflates
or
deconflates
the
semantic.
D
Route
around
it
with
so
I
would
I
would,
I
would
love
to
have
a
dmarc
be
a
different
specification
than
it
is,
but
it
is
what
it
is,
and
it's
already
been
noted
that
sender.
The
sender
proposal
involves
dramatically
more
complexity
for
implementation
and,
while
I
think
it's
still
worth
pursuing
and
discussing,
I
think
hanging
everything
on
that
would
be
a
very
serious
project
management
mistake.
D
By
the
way,
this
is
this
mechanism
is
really
interesting
because
it
lets
whoever's
speaking
actually
see
the
cue
yeah.
So
I
hate
to
tell
you
john,
but
that's
not
going
to
stop
any
of
the
pollution
you're
going
to
cause.
F
I
Now,
yes,
okay,
thank
you,
I
was
gonna,
say
more
or
less
what
pete
said,
but
in
a
slightly
different
way,
and
I
have
to
push
back
on
your
comment
about
mechanism,
because
the
author
field
is
not
useful
unless
muas
all
come
up
with
a
way
to
display
it,
which
is
enormous,
which
is
an
enormous
amount
of
implementation,
and
I
don't
see
any
reason
to
believe
that
anyone
will
actually
do
it.
I
mean
so
I
would
I
think
this
is.
I
I
think
this
is
a
very
I
think,
there's
a
useful
thought
you
get
rid
of
this.
I
think
it
is
a
useful
thought
experiment
but,
as
I
said
in
the
jabber
chat,
I
would
have
called
this
really
from,
because
I
am
absolutely
confident
that
it
will
like
take
time
about
10
seconds,
for
somebody
who
considers
himself
to
be
a
security
expert
to
invent
a
rule
that
says.
I
Oh,
if
author
is
different
from
author
is
different
from
from
then
it
must
be
spam,
which
I
realized
totally
misses
and
defeats
the
effect
that
you
have
in
mind
you
know,
and
so
we're
going
to
end
up
with
like
sort
of
a
rerun
of
what
we
had
with
with
ssl
certificates.
Well,
originally,
we
had
locks
and
locks
and
they
know
the
locks
got
the
base.
So
then
we
have
green
locks
now
the
green
lobster
device
and
stuff.
B
D
Okay-
oh
I'm
sorry,
I
was
forgetting
that
there
was
already
eq.
Why
don't
we?
Why
don't
we
drain
the
queue?
Okay?
That
was
there.
B
D
H
I
agree
with
john
on
this:
I'm
not
sure
that
this
actually
creates
value,
because
now,
instead
of
one
domain
now
you
have
to
validate
two
domains
and
understand
if
there's
a
conflict
which
one
the
receiving
entity
keys
on
the
other
issue
I
see,
is
we
don't
have
in
the
dmarc
working
group
participants
representing
mua
providers,
and
if
this
is
about
displaying
to
the
end
user,
those
are
the
folks
who
really
have
the
voice
for
us
to
be
telling
them
what
they
should
do,
how
they
should
do.
D
D
Ron
did
you
want
to
get
back
in
the
queue
and
and
comment
on
author.
F
I
was
in
the
queue
yes
yeah.
I
go,
I'm
in
the
key
now
awesome.
Yeah
I
mean
I
kind
of
do
represent
mua.
I
guess
in
that
we
have
the
web-based
interface.
F
You
can
give
either
an
aligned
value,
or
at
least
there.
There
is
a
confirmed
it
came
from
here,
so
you
have
the
name
and
the
existing
email
address,
assuming
the
rest
of
the
channel
is
clean
without
needing
to
rewrite
bron
gondwana
via
list
name,
something
or
other
as
the
from
address.
F
D
So
I
think
now
we
move
on
to
the
sender
specification.
B
If
you
can
save
your
comment
to
the
end,
because
that
was
the
end
of
that
first
queue
go
ahead:
dave.
D
All
right,
so
this
one,
the
the
the
current
version
that
I
issued
yesterday
morning,
is
significantly
different
from
the
previous
one.
In
its
philosophy,
the
original
philosophy
was
to
try
to
have
the
alignment
and
a
validation
of
the
sender.
Header
field
domain
name
be
in
preference
to
doing
that
for
the
from
field,
and
so
the
mechanism
was
designed
in
a
way
to
give
it
that
precedence.
D
Unfortunately,
that
creates
a
particular
case
with
going
to
a
receiving
engine
that
is
using
the
original
d-mark
and
not
the
modified
d-mark.
That
doesn't
support
the
the
sender
and
and
that
that
case
doesn't
really
work,
and
there
doesn't
seem
to
weigh
a
way
to
fix
that,
and
so
the
current
version
is
changed.
D
To
just
add
the
sender,
field,
alignment
and
validation
as
a
second
mechanism,
not
in
preference
to
and
the
pr
premise
for
why
that's
reasonable
is
the
real
work
with
this
stuff
is
done
in
a
filtering
engine
at
the
receiver
and
filtering
engines
at
receivers
are
already
very
complex
beasts
and
so
they're
going
to
do
what
they're
going
to
do
with
a
collection
of
information.
D
So
the
goal
here
is
to
add
one
more
data
point
for
them
to
play
with,
rather
than
try
to
quote
unquote
fix
dmarc,
and
that
ought
to
make
its
adoption
less
critical
path
for
anyone
and
its
use
more
incremental,
rather
than
possibly
have
unintended
consequences,
and
I
think
that's
all
that's
needed
for
this
summary.
J
Hello,
can
you
hear
me,
I
just
wanted
to
point
out
that
it
is
not
difficult
to
implement
the
evaluations
of
multiple
domains,
because
once
you
have
done
it
for
one
domain,
you
call
the
same
female
for
the
others,
and
comparing
two
domains
is
once
you
have
the
side
of
the
what
format
you
keep
them.
For
example,
your
label
is
not
difficult
at
all,
so
it
just
puts
more
dimensions,
presumably
keeping
the
chrome
domain
as
a
basic.
A
B
I
Oh
here
I
am
thank
you.
I
actually
I
like
this
one,
a
lot
better
than
than
the
author
field.
It
doesn't,
as
dave
said,
it
doesn't
require
that
muas
make
any
changes
which
is
good
because
I
don't
think
they
will
and
it
can
be
implemented
incrementally,
and
I
mean
I'm
a
little
go
around
the
list.
I
I
don't
find
that
this
is
semantically
all
that
different
from
just
saying
hey,
you
can
believe
my
dmarc
signature,
my
dkim
signatures,
but
I
realized
that
if
people
already
have
a
dmarc
evaluation
scheme
put
together,
then
this
this
this
was
this
would
slot
into
it
better,
and
it
certainly
would
solve
the
mailing
list
problem.
I
mean
I
can
adjust
my
million
list
software
to
to
ensure
that
it
puts
on
a
sender
and
and
and
signed
it
in
about
10
seconds.
So
I
would
be.
I
would
be
happy
to
advance
this.
D
By
the
way,
I
didn't-
I
didn't
post
anything
about
this,
but
in
thinking
about
this
I
think
that
to
be
effective,
what
you
just
said
was
sign.
I
assume
you
meant
a
dkim
signature
by
the
mediator
by
the
mailing
list.
I
think
actually
it's
that
to
be
particularly
effective.
I
Oh
yeah,
I
mean
the
for
this
to
be
useful,
the
recipient
will
have
to
say
we
have
a.
We
have
a
valid.
I
mean
this.
This
is
demarco
line
for
the
mailing
list
and
we
believe
the
mailing
list.
I
Yeah,
but
you
know,
but
having
actually
written
the
the
arc
support
for
for
sampa
supported
by
seth.
You
know
I
can
say
that
tweet
tweaking
that
to
support
this
would
be
very
straightforward,
so
this
is
techn.
This
is
this.
Is
I
think
this
is
you
know,
semantically?
Who
knows
what
the
world
will
do?
But
technically?
I
think
this
is
quite
sound.
F
B
D
Go
ahead,
I
I
don't
see
in
the
document
how
to
handle
conflicts
in
dmarc
policy,
for
instance,
if
the
sender
domain
and
the
from
domain
publish
two
different
dmarc
policies
and
say
dmarc
mechanism
check
fails
for
the
sender
domain,
with
a
policy
of
equal
reject
well,
as
dmarc
check
for
the
from
domain
passes.
D
What's
the
recommendation
for
handling
there
if
you're,
if
you're,
making
them
equivalent
yeah
there's
no,
let's
see,
is
it
politically
acceptable
to
say
tar
baby,
because
this
is
one
I
could
imagine
that
the
document
might
want
to
mention
this
issue,
there's
no
way
in
hell.
This
document
should
do
anything
normatively
about
that.
D
B
Yeah
and
thank
you
todd
for
raising
that
as
well,
michael,
if
you
can
take
your
comments
to
jabber
or
the
list,
we
need
to
move
on
to
the
next
topic.
B
Thank
you,
dave
for,
for
leaving
that
conversation,
the
giraffes,
we
have
gone
dark
for
our
a.d
murray.
The
stage
is
yours,.
C
All
right,
so
this
is
this
I'll
make
this
as
quick
as
possible.
Next
slide,
please.
C
To
begin
with,
before
dmarc
was
published,
the
general
idea
was
mailingless
break
signatures
that
makes
dmarc
unhappy,
but
then
realized,
while
doing
some
open,
dkim
debugging,
trying
to
figure
out
why
signatures
were
failing
in
specific
cases,
I
was
able
to
get
a
small
corpus
together
and
realize
most
of
the
breakage
at
least
that
you
know
five
years
ago
was
ex
can
be
exp
bucketed
into
a
certain
number
of
small,
well
understood
changes,
and
if
it's
true
that
you
can
understand
what
all
these
mutations
are
that
are
causing
the
problem,
and
you
decide
that
they
are
innocuous
enough,
that
you're
willing
to
forgive
them,
then
maybe
you
can
reverse
those
changes
and
get
back
the
original.
C
Just
just
enough
of
a
work
to
put
together
to
realize
that
you
can
get
the
author
signature
to
validate
again
now.
This
wasn't
designed
to
be
bulletproof
or
cover
100
of
the
cases.
It's
just
meant
to
solve
this
particular
problem
and
if
you
try
this,
this
amended
dkim
validation
process
and
you
and
it
fails
then
you're
in
no
worse
often
situation
than
when
you
didn't
even
try
this
at
all
and
that
you
have
a
failed
author
signature
and
therefore
no
dkim
alignment
or
anything
like
that
with
the
mark.
So
that
was
the
theory
here.
C
So
come
up
with
a
list
of
reversible,
reversible
and
acceptable
are
the
two
terms
that
are
key
here.
Reversible
is
something
that
can
be
undone
and
get
back.
The
original
content,
an
example
of
something
that
is
not
reversible.
Is
I
removed
a
mime
type,
a
mime
part
because
it
contained
a
type
that
I
don't
like.
You
obviously
can't
restore
content
that
you
don't
have,
so
that's
not
a
reversible
transformation,
an
acceptable
one
would
be.
C
I
believe
that
prefixing
subject
tags
is
probably
safe
to
undo
versus
other
things
that
you
might
not
find
acceptable
like
it's,
not
okay,
that
you
bolted
a
thousand
lines
of
footer
onto
this
message,
so
I
can
undo
a
thousand
lines
of
footer,
but
I
decided
that
I
decide
for
whatever
policy
reason
that
that's
probably
not
a
safe
thing
to
undo
and
then
attempt
to
validate
something.
C
C
Please
so
the
basic
algorithm
is
this:
you
have
a
message
with
an
author
signature
that
passes
through
an
mlm
that
gets
to
you.
The
list
has
signed
it
but
mutated
as
well
as
you
might
expect
the
list.
Signature
verifies,
but
the
author
signature
doesn't
that's
the
problem,
but
if
l
has
a
tag
on
it
saying
these
are
the
transformations
the
list
made,
then
in
theory
you
can
reverse
them
in
the
reverse
order.
C
C
So
the
upsides
to
this
are
you
don't
need
crypto,
and
you
don't
need
dns,
because
everything
you
need
to
know
you
have
within
the
protocol
itself.
This
is
I
found
in
terms
of
implementation
and
at
least
john
disagree,
but
this
was
very
lightweight
and
simple.
Compared
to
implementing
arc
the
first
set
of
proposed
transformations.
It's
a
very
small
list
are
very
well
understood.
C
The
things
to
be
worried
about
are
that,
although
you
can
do
things
like
identify
the
subject
tag
which
is,
if
you
know,
semantically,
you
can
just
say
anything
in
square
brackets,
plus
white
space
after
it
goes
away.
That's
very
easy.
You
know
a
two
dash
footer
that
you
stuck
on
a
message.
C
That's
very
easy:
to
get
rid
of
rearranging
mime
types
you
get
into
a
little
bit
of
a
problem,
because
dkim
is
sensitive
to
any
changes
and
if
you
happen
to
undo
what
you
thought
was
a
mime
transformation
and
your
code
doesn't
exactly
match
where
the
kerlis
went
when
the
original
you're
going
to
break
the
signature.
The
other
point
about
this
and
john
correctly
points
out.
This
is
kind
of
like
the
old
l
tag
problem
with
dkim.
In
that
someone
could
just
bolt
like
I
said,
a
thousand
lines
of
footer
onto
something
claim.
C
Well,
I
added
a
footer
just
remove
that
and
the
the
bolted
on
content
dominates
the
message,
and
now
you
have
a
signed,
sorry,
a
piece
of
spam
that
can
be
validated
as
with
the
author
signature,
so
it's
kind
of,
like
l,
equals
you're
sort
of
granting
permission
for
potentially
large
mutations,
and
that's
why
I
get
back
into
acceptable.
But
now
you
have
to
have
some
kind
of
idea
of
what
are
you?
What
are
the
mutations
you
consider
to
be
acceptable,
so
that
is
a
that
is
a
a
problem
with
this
proposal.
F
Braun,
I
think
I
think
the
obvious
issue
here.
Well,
I've
got
a
bad
echo
yeah
is
that
even
even
a
short,
acceptable
change
is
unsubscribe.
Click
here
takes
you
to
the
spammers
page.
It
is
very
hard
even
for
a
short
thing,
to
declare
what's
acceptable,
particularly
because
the
website
that
the
unsubscribe
link
takes
you
to
can
check
the
ip
it's
coming
from
and
know
whether
it's
getting
a
connection
from
the
testing
machine
or
from
the
actual
end
user.
C
Until
it
gets
attacked
sure
I
mean
the
the
the
footer
one,
you
might
decide,
you
don't
want
to
take
any
footer
ones,
and
the
only
thing
you're
willing
to
take
is
the
subject
tag.
It
is
flexible,
you
get
to
choose
which
ones
you
want
to
trust.
But
yes,
there
are
it's.
It
is
definitely
not
a
bulletproof
thing.
There
are
ways
yeah.
There
are
ways
to
abuse
it.
E
The
I
yeah
I
see
a
lot
of
a
lot
of
comparison
to
the
l,
equals
tag
problem
and-
and
you
know
I
that
I
recall
that
one
well
two
two
issues.
One
was
that
you
know
there
were
some
people
generated
some.
You
know
rather
surprising
results.
I
think
through
mime
and
so
forth,
with
just
the
l
equals
tag,
and
this
is
a
considerably
more
complex
set
of
reverse
transformations
than
l
equals
is
so
I'm
a
little
bit
concerned.
E
This
is
going
to
have
to
be
thoroughly
vetted
to
make
sure
that
there
aren't
some
vulnerabilities
in
the
in
the
reverse
transformation.
The
other
is,
and-
and
just
this
is
more
of
a
question-
is
the
intent
here
that
the
recipient
would
still
receive
the
message
in
its
original
form
or
is?
E
Is
the
intent
that
in
some
cases
the
the
recipient
would
receive
the
I'm
sorry
in
its
modified
form,
or
would
they
sometimes
receive
it
in
the
original
form,
because
if,
if
they
receive
it
in
the
modified
form,
the
whole
issue
of
branding
and
so
forth,
you
know
the
the
the
originating
domain
kind
of
owns?
The
content
is
brought
into
question.
C
Yeah,
that's
that
that
came
up
before
too,
and
that
is
an
interesting
one.
This
is
probably
not
that's
the
right
way.
I
want
to
say
this:
you
could
substitute
the
mlm's
version
of
it
with
the
author
version
of
it,
since
you
were
able
to
recover
the
author
version
of
it.
If
you
decide
that
any
of
the
transformations
might
have
been
dangerous,
I
don't
know
that.
That's
necessarily
a
good
idea,
though
that's
certainly
going
to
be
another
thing
you
would
need
to
vet,
for
is
that
a
wise
thing
to
do?
C
C
I
I
I
have
kind
of
one
one
and
a
half
comments
here,
there's
one
of
which
I
made
on
the
list.
One
is
the
whole
idea
of
acceptable.
I
think,
makes
this
very
problematic,
because
I
mean
for
all
of
this
complexity.
Archie
there's,
you
know,
art
gives
you
a
well-defined
result,
whereas
here
the
result
is
well
that
we
we
managed
to
undo
the
transformations.
But
now
we
have
this
this
ill-defined
policy
blob
over
here
that
has
to
decide
whether
the
transformations
were
good
or
were
were.
I
We're
acceptable
or
not,
which
means
that,
even
if,
even
if
you
do
this,
you
know
you're
going
to
send
the
same
piece
of
mail
to
four
different
four
different
people,
and
just
and
just
with
this
particular
tweak
to
dkm
you're
gonna
get
four
different
results,
because
they're
gonna
have
four
different
policies.
The
the
other
thing
is
that
it
is
my
ill-informed
belief
that
the
the
transformations
that
mail
packages
make
have
gotten
more
complicated,
particularly
is
there
is
their
mind.
I
Processing
has
gotten
more
sophisticated,
so
while
I
realize
it
is
not
fair
to
ask
murray
to
do
more
work,
I
wish
we
had
a
more
recent
set
of
mail
to
see
what
sort
of
transformations
they
do,
because,
like
my
mailing
list,
like
typically
plug
in
a
mime
type
at
the
front
at
the
front
of
the
message
with
a
disclaimer
which
is
really
hard
to
unwind,
you
know
so
it
might
turn
out
that
when
you
apply
this
to
modern
mail
from
places
other
than
other
than
mailman
that
it
doesn't,
it
doesn't
unwind
enough
enough
changes
to
be
useful.
C
Yeah
absolutely
like
I
said
this
was
based
on
work.
I
did
five
years
ago
and
just
the
list
of
transformations
that
mailman
told
me
about
what
a
month
month
and
a
half
ago
was
more
complicated
and
you're,
relying
at
that
point
on
sort
of
every
mime
management
library
to
do
everything
exactly
the
same
way
like
the
right
line,
breaks
between
out
of
the
boundary
and
other
things
to
always
sort
of
follow
the
same
pattern
and
everybody
agree
on
how
that
should
be
canonical.
C
I
H
I'm
kind
of
conflicted
about
your
proposal,
murray.
On
the
one
hand,
I
think
it's
interesting,
but
on
the
other
hand,
I
think
what
we
need
is
some
running
code
and
some
senders
and
receivers
and
intermediaries
to
test
it
so
experimental
before
we
really
push
forward
on
it.
B
B
So
the
final
thing
we
wanted
to
cover
is
that
there's
there
have
been
a
couple
of
tickets
filed
about
abn,
f
problems
in
dmarc
and
abnf
problems
that
d-mark
inherits
and
what
we
wanted
to
talk
about.
That
will
be
heavily
a
list.
Conversation
is
how
much
of
this
do
we
actually
want
to
solve
and
how
deep
of
a
rabbit
hole
is
it-
and
I
know
tim
and
john
levine
have
already
done
some
investigation
here.
B
B
Great
so
then
we're
just
at
time.
Thank
you.
Everyone
and
we'll
discuss
the
abnf
issues
on
the
list
and
thanks
for
a
productive.