Re: Mail, not to be confused with spam...

Rich Kulawiec <rsk@gsp.org> Wed, 21 December 2011 13:22 UTC

Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pBLDMl0W068636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Dec 2011 06:22:47 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id pBLDMlOa068635; Wed, 21 Dec 2011 06:22:47 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f
Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pBLDMkQo068630 for <ietf-smtp@imc.org>; Wed, 21 Dec 2011 06:22:46 -0700 (MST) (envelope-from rsk@gsp.org)
Received: from squonk.gsp.org (bltmd-207.114.17.210.dsl.charm.net [207.114.17.210]) by taos.firemountain.net (8.14.5/8.14.5) with ESMTP id pBLDMhoj018558 for <ietf-smtp@imc.org>; Wed, 21 Dec 2011 08:22:45 -0500 (EST)
Received: from vorlon.gsp.org (vorlon.gsp.org [192.168.0.20]) by squonk.gsp.org (8.14.3/8.14.3) with ESMTP id pBLDXWEp001848 for <ietf-smtp@imc.org>; Wed, 21 Dec 2011 08:33:32 -0500 (EST)
Received: from localhost6.localdomain6 (localhost.localdomain [127.0.0.1]) by vorlon.gsp.org (8.14.3/8.14.3/Debian-9.2ubuntu1) with ESMTP id pBLDMcHE010551 for <ietf-smtp@imc.org>; Wed, 21 Dec 2011 08:22:38 -0500
Received: (from rsk@localhost) by localhost6.localdomain6 (8.14.3/8.14.3/Submit) id pBLDMbHq010547 for ietf-smtp@imc.org; Wed, 21 Dec 2011 08:22:37 -0500
Date: Wed, 21 Dec 2011 08:22:37 -0500
From: Rich Kulawiec <rsk@gsp.org>
To: ietf-smtp@imc.org
Subject: Re: Mail, not to be confused with spam...
Message-ID: <20111221132237.GA6320@gsp.org>
References: <4ED63E05.7030509@tana.it> <CAHhFybo0Y6e9wOJDYKzHfO0oYTSNgqkydu2a2Qwgr-FQOL-aeA@mail.gmail.com> <4EDFFAF4.1080201@mail-abuse.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4EDFFAF4.1080201@mail-abuse.org>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: owner-ietf-smtp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=unsubscribe>

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 vesely@tana.it  Tue Dec  4 00:47:47 2012
Return-Path: <vesely@tana.it>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F2D21F8C1C for <ietf-smtp@ietfa.amsl.com>; Tue,  4 Dec 2012 00:47:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.719
X-Spam-Level: 
X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OijYK92wKUcI for <ietf-smtp@ietfa.amsl.com>; Tue,  4 Dec 2012 00:47:46 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id EFEB621F8BE0 for <ietf-smtp@ietf.org>; Tue,  4 Dec 2012 00:47:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1354610856; bh=JcTSjkKPJhOp3EIbg5X0q4zkwx4y3H5LQ+Dds71+/Dg=; l=1722; h=Date:From:To:References:In-Reply-To; b=CgOy1bkxIi6R+/xAebgV9C2727ZEt1yecjNCgyoMcz+RrakE1yndHgCt2mD0Vj14x lYC9bd2hGnKfoVzu4Wpr7NHAB/Hx/ZUSehuLpH6SaUmlmD/kmrvLMowCblPY3Bn8aL 87G6sRegbO5UwPlTzO7B6/jZ0gLQES4ZLR+HFtE0=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Tue, 04 Dec 2012 09:47:36 +0100 id 00000000005DC039.0000000050BDB8A8.00006347
Message-ID: <50BDB8A7.9050801@tana.it>
Date: Tue, 04 Dec 2012 09:47:35 +0100
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: SMTP Interest Group <ietf-smtp@ietf.org>
References: <20121107020448.E2B9BB1E003@rfc-editor.org> <50B54668.4050006@qti.qualcomm.com> <DDA0373D6759951BD5151E05@JcK-HP8200.jck.com>
In-Reply-To: <DDA0373D6759951BD5151E05@JcK-HP8200.jck.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [ietf-smtp] Revision vs independent effort, was Editorial Errata Reported
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-smtp>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Dec 2012 08:47:47 -0000

On Wed 28/Nov/2012 10:17:50 +0100 John C Klensin wrote:
> --On Tuesday, November 27, 2012 17:02 -0600 Pete Resnick
> <presnick@qti.qualcomm.com> 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 john+smtp@jck.com  Tue Dec  4 06:19:43 2012
Return-Path: <john+smtp@jck.com>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E87521F8A92 for <ietf-smtp@ietfa.amsl.com>; Tue,  4 Dec 2012 06:19:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ws2K8G9kTLXt for <ietf-smtp@ietfa.amsl.com>; Tue,  4 Dec 2012 06:19:43 -0800 (PST)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id DC9A221F8A85 for <ietf-smtp@ietf.org>; Tue,  4 Dec 2012 06:19:42 -0800 (PST)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <john+smtp@jck.com>) id 1TftLY-0002xt-14; Tue, 04 Dec 2012 09:19:40 -0500
Date: Tue, 04 Dec 2012 09:19:32 -0500
From: John C Klensin <john+smtp@jck.com>
To: Alessandro Vesely <vesely@tana.it>, SMTP Interest Group <ietf-smtp@ietf.org>
Message-ID: <A6AFC0B7BA44BB29FFB3D5FF@JcK-HP8200.jck.com>
In-Reply-To: <50BDB8A7.9050801@tana.it>
References: <20121107020448.E2B9BB1E003@rfc-editor.org> <50B54668.4050006@qti.qualcomm.com> <DDA0373D6759951BD5151E05@JcK-HP8200.jck.com> <50BDB8A7.9050801@tana.it>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: Re: [ietf-smtp] Revision vs independent effort, was Editorial Errata Reported
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-smtp>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Dec 2012 14:19:43 -0000

--On Tuesday, December 04, 2012 09:47 +0100 Alessandro Vesely
<vesely@tana.it> 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.