On 4/29/2014 7:10 AM, Alessandro Vesely wrote:
The discussion on ietf-822 brought some mailing list assumptions
--much needed, since ML were never formally standardized-- as well as
a few proposals. Now the discussion seems to be fading out, even if
no actionable result was reached. The solutions proposed, in order of
decreasing ease (IMHO), are:
* Whitelisting,
* weak signatures,
* permission to re-sign, and
* exchange of cryptographic data.
All of those solutions require that originators' relays know whether a
message is destined to a mailing list. That is a delicate subject in
itself, as it involves privacy considerations --does a subscriber
consent to allowing her or his mailbox providers to know which lists
she or he is on?
You keep thinking this is MLM problem. NO, this is for all systems to
follow. Even a BANK for example:
"Ok, we need your email address for our new eBanking service!"
"hmmmmm, oh, I'm sorry, your email domain receiver doesn't
support DMARC so you will alway be open to fraud problems
with your email address. Have another address?"
"Ok, hmmmm, oh, I'm sorry, that one too is no good to use."
"No Problem, you can use our ONLINE service, with our EMAIL
address or you can go another ESP mail service that offers
DMARC operations."
It doesn't have to be a mailing list.
The DMARC draft is currently in "AD Followup" state. A review was
posted here last week, a process which doesn't seem to affect
deployment much.
How is the IETF going to proceed on this issue?
Get control of the DMARC draft with greater policy design advocate
participation and begin to get operational policy discussions going in
order to define new mail handling policy options.
Overall, the first principle thing is to:
* HONOR THE PROTOCOL FIRST
This has the been the fundamental issue with the middle-ware market.
Its not just the mailing list system. It could be any mail hosting
service who may wish to begin (re)sign mail.
In all cases, the remailer has to check author domain signing policies
and so far, they have refused to do so. They prefer to do this in an
unrestricted way that doesn't require the author domain permission.
They wanted to change in order to ADD DKIM, but not change to ADD
POLICY. Its not just about the mailing list but any 3rd party
resigner. This is burned into the DKIM abstract:
DKIM separates the question of the identity of
the Signer of the message from the purported author
of the message.
This was a fundamental flaw since it was not possible to separate the
author from the message without violating the signer's signature of
the message. This would be another suggestion to do an DKIM RFC6376
errata to remove this conceptual flaw and update the DKIM Assessor
input requirements that would include the Author Domain Identity
RFC6376 intentionally, refused to recognize or defined in the document.
I think the middle-ware operations who would be doing DKIM will do the
right thing and add the DKIM+POLICY layer its been sourly missing if
the IETF can correct DMARC or even ADSP to allow the resigner to exist
in a proper protocol defined way. All we had was IETF resistance to
allowing policy to exist. It made ADSP historic! DMARC snuck in.
Disaster!
There was a fundamental error in making ADSP historic so perhaps we
should revisit why and learn from the engineering that was done and/or
explored in order to update DMARC with the 9 years of multiple RFC
development and insights.
I have an ethical engineering problem with ignoring protocol policies
with offering by-passing suggestions. The DMARC drafts needs to be
updated if we want the middleware to coexist with it.
--
HLS