Subject: Re: Mail, not to be confused with spam...
From: Douglas Otis <[email-masked]>
To: Rich Kulawiec <[email-masked]>
Cc: [email-masked]
Date: Wed, 28 Dec 2011 19:08:51 -0800
List-Id: <ietf-smtp.imc.org>

On 12/21/11 5:22 AM, Rich Kulawiec wrote:
>
>  On Wed, Dec 07, 2011 at 03:47:00PM -0800, Douglas Otis wrote:
> > Without a solid defense of actual sources, email will continue to
> > be abused. On the other hand, social networks benefit from rapid
> > removal of abusive accounts, since much of their ad revenue is
> > based upon unique identifiers.
>
>  Two points:
>
>  a) Most "social networks" *are* the spammers. They've been proving
>  this to my spamtraps for years. Many of them will prove it again
>  this week. b) Social networks themselves are being overrun by
>  fictional users, see:
>
>  http://www.technologyreview.com/computing/39304/

Rich,

This was not about how social networks treat email, but I agree with 
your point.  Email lacks an authenticated identifier of the 
administrative domain transmitting messages.  And no, DKIM does not 
fulfill this role.  While social networks may be overrun by fictional 
users (which is great from an ad revenue standpoint), each user is still 
authenticated by the administrative domain.  This authentication 
(lacking with email) provides users control over who is granted access 
to their inbox or content.  A savvy user may also depend upon shared 
relationships.

>  As the author observes:
>
>  "This industry is millions of dollars per year already and [shows]
>  roughly exponential growth," says Zhao. "I think we're still in the
>  early stages of this phenomenon."

This also represents a generation no longer trusting email and often 
don't even have email-addresses.  And yes, there are many security 
vulnerabilities with proprietary social networks, especially with 
respect to smartphone apps.  There are also financial incentives for 
fixing problems affecting users when they become apparent.  Google 
offers finer grain control over shared content, for example.  Fix the 
email authentication issue, and email could play an integral role in a 
trusted social network.

-Doug

Date: Wed, 28 Dec 2011 18:25:28 -0800
From: Douglas Otis <[email-masked]>
To: [email-masked]
CC: Dave CROCKER <[email-masked]>, [email-masked]
Subject: Re: Mail, not to be confused with spam...
Sender: [email-masked]

On 12/21/11 6:15 AM, Dave CROCKER wrote:
>  On 12/1/2011 9:53 AM, John Levine wrote:
> > It was an IRTF draft. Then some people in the IESG asked why it
> > wasn't standards track. Fine, I said, let's make it standards
> > track. Then in IESG review, people (not the same ones) in the IESG
> > offered a variety of comments that revealed that their
> > understanding of spam management was stuck in the 1990s, and there
> > was no way they were going to approve this draft without a lot of
> > changes that would make it useless. So I said, never mind, and
> > flipped it back to IRTF, which is how it was published.
>  The particular example involved re-purposing DNS RRs for anti-spam,
>  since that's the most common way to publish blacklist information.
>  And as John noted, the document did not come from an IETF working
>  group.
>
>  DNS work in the IETF is dominated by a collection of folk who demand
>  quite a bit of purity in proposed standards and BCPs. Repurposing A
>  records is a long way from pure.
>
>  The fact that this is a well-established mechanism and is essential
>  to the operation of Internet Mail is irrelevant to these folk.
>
>  The fact that they and others don't know anything about modern
>  anti-spam work was, IMO, secondary to the purity concern.
>
>  Also, folks should note that DKIM was an anti-spam effort and had no
>  process problems getting on the standards track.

IMHO, few within the DNS community consider reverse DNS suitable for 
blacklisting IPv6 addresses.  A reasonable estimate of near term prefix 
announcements will soon approach an equivalent of a quadrillion /64s.  
Reverse DNS will soon fail in a blacklisting role.  Some providers, such 
as ThreatStop, now offer APL RRs as a forward looking approach.

DKIM was never part of an anti-spam effort.  It started out as an 
anti-phishing effort that did not require MUA modification for safe 
deployment.  DKIM does not verify the entity transmitting the message, 
nor intended recipients.   Spammers are normally defined as those 
transmitting messages unwanted by recipients.  DKIM is unable to confirm 
either transmitters or intended recipients.   Hardly a suitable tool for 
dealing with spam.  Even with statistics applied, domains will be unable 
to defend their reputation when DKIM is used as a basis for assessing 
spammers.  Except of course those already considered too big to block.

With DKIM signature validation ignoring prepended headers, DKIM even 
fails to meet the intended purpose as an anti-phishing tool since it now 
requires modified MUAs to detect pre-pended header fields.   A check 
lacking any type of confirmation likely to give users a false sense of 
security making them more prone to deception.  :^(

>  That is, an IETF working group that was able to produce a consensus
>  document got through the IESG with no major problems. A document
>  that did not come from a working group /did/ have problems.

Agreed, there are problems.

-Doug

Date: Wed, 21 Dec 2011 06:15:46 -0800
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Re: Mail, not to be confused with spam...
Sender: [email-masked]

On 12/1/2011 9:53 AM, John Levine wrote:
> It was an IRTF draft.  Then some people in the IESG asked why it
> wasn't standards track.  Fine, I said, let's make it standards track.
> Then in IESG review, people (not the same ones) in the IESG offered a
> variety of comments that revealed that their understanding of spam
> management was stuck in the 1990s, and there was no way they were
> going to approve this draft without a lot of changes that would make
> it useless.  So I said, never mind, and flipped it back to IRTF, which
> is how it was published.

The particular example involved re-purposing DNS RRs for anti-spam, since that's 
the most common way to publish blacklist information.  And as John noted, the 
document did not come from an IETF working group.

DNS work in the IETF is dominated by a collection of folk who demand quite a bit 
of purity in proposed standards and BCPs.  Repurposing A records is a long way 
from pure.

The fact that this is a well-established mechanism and is essential to the 
operation of Internet Mail is irrelevant to these folk.

The fact that they and others don't know anything about modern anti-spam work 
was, IMO, secondary to the purity concern.

Also, folks should note that DKIM was an anti-spam effort and had no process 
problems getting on the standards track.

That is, an IETF working group that was able to produce a consensus document got 
through the IESG with no major problems.  A document that did not come from a 
working group /did/ have problems.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Wed, 21 Dec 2011 08:22:37 -0500
From: Rich Kulawiec <[email-masked]>
To: [email-masked]
Subject: Re: Mail, not to be confused with spam...
Sender: [email-masked]

On Wed, Dec 07, 2011 at 03:47:00PM -0800, Douglas Otis wrote:
> Without a solid defense of actual sources, email will continue to be
> abused.  On the other head, social networks benefit from rapid
> removal of abusive accounts, since much of their ad revenue is based
> upon unique identifiers.

Two points:

a) Most "social networks" *are* the spammers.  They've been proving this
to my spamtraps for years.  Many of them will prove it again this week.

b) Social networks themselves are being overrun by fictional users, see:

	http://www.technologyreview.com/computing/39304/

As the author observes:

	"This industry is millions of dollars per year already and [shows]
	roughly exponential growth," says Zhao. "I think we're still in
	the early stages of this phenomenon."

---rsk

From [email-masked]  Tue Dec  4 00:47:47 2012
Date: Tue, 04 Dec 2012 09:47:35 +0100
From: Alessandro Vesely <[email-masked]>
To: SMTP Interest Group <[email-masked]>
Subject: [ietf-smtp] Revision vs independent effort, was Editorial Errata Reported

On Wed 28/Nov/2012 10:17:50 +0100 John C Klensin wrote:
> --On Tuesday, November 27, 2012 17:02 -0600 Pete Resnick
> <[email-masked]> wrote:
>> 
>> The following erratum was posted for 5322. I'm inclined to reject
>> it since this discussion actually took place during DRUMS and the
>> consensus outcome as far as I could tell was that messages
>> without a final CRLF were SMTP's problem.
> 
> First, while that requirement of SMTP may not be required by 5322,
> nothing prevents SMTP from imposing it.  Again, these are design 
> decisions made during the DRUMS period, not errors, and errata are
> not an appropriate way to reopen those design decisions.
> [...]
> I don't see the proposed clarification text as a real problem, but
> don't see it as necessary either.   If you reject the present
> erratum proposal and another one is generated against 5321, I will
> certainly recommend rejecting the latter as well (or at least
> putting it into "hold for document revision".

So far, the point seems to be about the best way to hang post-it notes
that might be useful for document revision.  A better tool than the
errata system would be handy, IMHO.  Did you see the comment system
that the FSF put up for GPLv3? [*]

[*] A glance is worth a thousand words, see it in action e.g. at:
http://gplv3.fsf.org/comments/gplv3-draft-2.html

> However, I note that each "hold for document revision" placeholder,
> especially the subset that involve earlier design decisions, will
> bring us closer to the need for a WG to revise 5321 rather than
> allowing that to be an independent effort).

Does that mean independent of the pressure exercised by the weigh of
the post-it sediment?

From [email-masked]  Tue Dec  4 06:19:43 2012
Date: Tue, 04 Dec 2012 09:19:32 -0500
From: John C Klensin <[email-masked]>
To: Alessandro Vesely <[email-masked]>, SMTP Interest Group <[email-masked]>
Subject: Re: [ietf-smtp] Revision vs independent effort, was Editorial Errata Reported

--On Tuesday, December 04, 2012 09:47 +0100 Alessandro Vesely
<[email-masked]> wrote:

>...
>> I don't see the proposed clarification text as a real
>> problem, but don't see it as necessary either.   If you
>> reject the present erratum proposal and another one is
>> generated against 5321, I will certainly recommend rejecting
>> the latter as well (or at least putting it into "hold for
>> document revision".
> 
> So far, the point seems to be about the best way to hang
> post-it notes that might be useful for document revision.  A
> better tool than the errata system would be handy, IMHO.  Did
> you see the comment system that the FSF put up for GPLv3? [*]

Yep.  Maybe better suited for discussion of legal issues than of
this sort of topic, but...

>> However, I note that each "hold for document revision"
>> placeholder, especially the subset that involve earlier
>> design decisions, will bring us closer to the need for a WG
>> to revise 5321 rather than allowing that to be an independent
>> effort).
> 
> Does that mean independent of the pressure exercised by the
> weigh of the post-it sediment?

To some extent, yes.  To be a little more clear, there are two
procedural possibilities for a 5321 (and presumably 5322)
update, almost independent of the many factors that enter into
when it happens.  One is that such an update is substantially
just a textual update, clarifying whatever needs to be
clarified, rearranging text if necessary to improve readability,
dealing with issues about which there is no substantial
disagreement, and coping with whatever whims the then-IESG
chooses to impose.*  In that case, the revisions could be
handled as either individual submissions or via the AppsAWG.
The other is that design decisions need to be reviewed and
revisited --possibly ones that would require reversion to
Proposed but even less important ones.  In the latter case, I
believe a WG will be necessary, with the recent Webfinger
overload on the AppsAWG list being only one symptom of the
problem.  Speaking personally and not as editor, I would have a
lot of trouble trying to convince others (or even myself) that,
with limited resources in the IETF, there is a sufficiently
pressing need for an SMTP update to require the costs of
creating and managing a WG.  YMMD.

best,
    john

* For those who don't know, 5321 itself nearly died because of
insistence by an IESG member or two on "editorial" changes that
would have effectively required a complete revision, including a
complete revision and reorganization of the ABNF.    We finally
got the document through by postponing those demands until "next
time", but I'm assuming that, if we were to try to do a revision
now, they would come back up again.   Having to face that
"opportunity" doesn't increase motivation to do a revision very
much.