ietf
[Top] [All Lists]

Re: [dmarc-ietf] IETF Mailing Lists and DMARC

2016-11-04 11:56:28
Ted,

I started that note before you posted your list of four options
and decided to send it anyway.   I think your list is correct
and, since it apparently wasn't obvious from my comments, prefer
your first option.

The reason for the long note is that I don't accept this as
"just life".  I believe the IETF has an affirmative obligation
to avoid breaking the Internet -- or the protocols it has chosen
to standardize -- and to avoid encouraging those who choose to
do so.  Assuming there is no disagreement that the problem is
real, one implication of that involves a very strong preference
for bringing work to the IETF while it is still at (or before)
the design phase rather than having something half-designed
elsewhere,   deployed, and them brought to the IETF on either as
"standardize this as is because it is deployed" or a "you folks
in the IETF can now straighten out the mess we made by
developing and deploying this without thinking through the
implications".  Given that the problem is real, the IETF of
course has some obligation to take it on in a serious way.
When the breakage is bad enough (and I'm not taking a position
on whether DMARC is) and is the result of an action by a
dominant player or collection of them, I also believe that we
(individually if not in the name of the IETF, have a
professional obligation to initiate or participate in
discussions with appropriate authorities about anticompetitive
and/or monopolistic behavior.

Finally (and here is where I demonstrate that I'm very far out
in the rough), your comment about Canter and Siegel identifies a
different, but to me important, issue.  Suppose we have a
community that as a significant problem with either domestic
animals or humans defecating on the sidewalks.   Obviously one
option is for everyone who lives there or visits to become very
careful about where they step, but that has a number of serious
implications.  Another is to prohibit doing that and to also
have "clean up after your pets and offspring" rules.    However,
carrying around appropriate bags and pick-up instruments is
annoying and experience indicates that, unless those rules are
enforced (as either a matter of law or effective community
outrage), there will still be a lot of s**t on the streets.
That becomes interesting as a social problem because, if a group
of well-meaning people springs up to come around the community
every day and clean up previously-untended messes, any pressure
to punish or otherwise deter those who are responsible for those
messes disappears (and more people may be encouraged to stop
going to the trouble of cleaning up after themselves and their
pets).  On the other hand, if those spontaneous and well-meaning
efforts do not occur, then the pressures within the community to
punish those who cannot be bothered to do the cleaning up rise
until either such measures are taken or the community, including
the non-offenders, are explicitly taxed to provide funding for
claiming up the problem.

There are aspects of the spam problem that are a lot like that.
Many of the significant costs are incurred as soon as the
messages start to cross the Internet.  Solutions that involve
filtering the messages so they cannot be delivered do nothing to
address that problem, nor to impose costs on the message
originators.    Instead, by mitigating the nuisance value of the
spam and the risks to the recipient of whatever comes with the
spam messages, they have the side-effect of reducing the
incentives to find the spammers and punish their behavior in a
serious enough way to deter the practice.  Indeed, if the
spammer's objective is to get a certain number of messages
through, actions that increase the percentage of spam messages
that are blocked near the delivery point may create an incentive
to increase the number of messages sent and hence the burdens on
the network and the costs to those who maintain mail delivery
systems.

Again, I am not suggesting that the IETF (or anyone else) try to
ignore the spam problem.   However, it seems to me that we need
to think a bit more about the whole system, evaluate questions
like how much we are willing to give up for the privacy
advantages of hard-to-trace message origins, and generally be
careful what we wish for.

    best,
    john


--On Friday, November 04, 2016 11:21 -0400 Ted Lemon
<mellon(_at_)fugue(_dot_)com> wrote:

Forgive me if this isn't as respectful as it could be, but
your rather long dissertation on the problem didn't actually
say what would go wrong if we did something about it.   Is
there something missing from the summary I wrote and sent to
the mailing list yesterday?

This is an operational issue, not a philosophical issue.
People are trying to get work done, and a problem created by
people other than them is preventing them from getting work
done.  Worse, it's doing it in a way that is difficult for
third parties to detect, and that has resulted in people
unexpectedly and unknowingly not getting email they needed to
get.

This is a _really serious problem_.   Arguing that we
shouldn't solve it because we have philosophical issues is
silly.   It's like arguing that we shouldn't have
firewalls, which break IP in exactly the way you described,
because they are bad on a philosophical level.   They _are_
bad on a philosophical level.   We, the IETF, are not going to
stop people from installing them, because they are _good_ on
an ops level.   The idea that we shouldn't solve problems
like this regarding email went out the window when Canter and
Siegel came on the scene.

That's just life.   So if you have a technical reason why
fixing this problem is a bad idea, please share it.   And I am
always interested in your philosophy.   But I do not think you
have made a valid technical argument against the IESG
addressing this operational problem.





<Prev in Thread] Current Thread [Next in Thread>