From lemonade-bounces@ietf.org Sun May 08 15:01:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUr28-0005Md-90; Sun, 08 May 2005 15:01:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTpF5-0007zD-4c for lemonade@megatron.ietf.org; Thu, 05 May 2005 18:54:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03272 for ; Thu, 5 May 2005 18:54:47 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTpQi-0007Da-6O for lemonade@ietf.org; Thu, 05 May 2005 19:06:53 -0400 Received: by zproxy.gmail.com with SMTP id 18so1032236nzp for ; Thu, 05 May 2005 15:51:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:mime-version:content-type; b=aQsjcDPLIOrYCOv8Xz3fcUAPLe9keURfivX4f/cZic+13ca8ZS3T+cIYmnb8Rvlay9zngov9E69gfcA/6PQyeMFma355r0PwbHxVH9HVPJFyFmNyHLhcJsu2fCbYrzZ7eXIKghRQacsSEitP7z3vTQUWqOI+pS438K7mnTCMLps= Received: by 10.36.42.19 with SMTP id p19mr501361nzp; Thu, 05 May 2005 15:51:50 -0700 (PDT) Received: by 10.36.50.6 with HTTP; Thu, 5 May 2005 15:51:50 -0700 (PDT) Message-ID: Date: Thu, 5 May 2005 18:51:50 -0400 From: Kartik Gopalan To: ietf-smtp@imc.org, asrg@ietf.org, lemonade@ietf.org Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e X-Mailman-Approved-At: Sun, 08 May 2005 15:01:42 -0400 Cc: Yingfei Dong Subject: [lemonade] draft-duan-smtp-receiver-driven-00.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kartik Gopalan List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1997793446==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --===============1997793446== Content-Type: multipart/alternative; boundary="----=_Part_25505_7975606.1115333510921" ------=_Part_25505_7975606.1115333510921 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable We'd like to solicit feedback from the SMTP community on=20 our recent IETF draft titled "Receiver-Driven Extensions to SMTP". http://www.ietf.org/internet-drafts/draft-duan-smtp-receiver-driven-00.txt The abstract of the draft is attached below. As we are new to the IETF process, we welcome any suggestions=20 pointing out potential improvements as well as deficiencies in the draft. The following DiffMail project website and our related paper in SRUTI'05=20 might also be of interest. http://www.cs.fsu.edu/~duan/projects/diffmail/diffmail.htm Thanks, Zhenhai Duan, Kartik Gopalan, Yingfei Dong Abstract: The Differentiated Mail Transfer Protocol (DMTP) provides simple=20 extensions to the Simple Mail Transfer Protocol (SMTP) that=20 enable receivers to exercise greater control over the email delivery=20 process. The current SMTP-based email delivery architecture is=20 fundamentally sender-driven and distinctly lacks receiver control over the message delivery mechanism. This document describes DMTP=20 that enables receivers to classify senders into three categories -- allowed= ,=20 denied, and unclassified -- and process the delivery of messages=20 from each category independently. As is the current practice, receivers=20 may directly accept messages from senders in the allowed category and decline senders in the denied category. In addition,=20 DMTP receivers require senders in the unclassified category to=20 store messages on the senders' own mail servers. Such messages=20 are retrieved only if and when the end receivers wish to do so.=20 By granting greater control over message delivery to receivers and imposing greater message storage and maintenance overhead on=20 senders, DMTP provides significant advantages in controlling spam.=20 DMTP also easily operates in conjunction with (but does not require)=20 many currently deployed anti-spam techniques. ------=_Part_25505_7975606.1115333510921 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
We'd like to solicit feedback from the SMTP community on
our recent IETF draft titled "Receiver-Driven Extensions to SMTP"= .

http://www.ietf.org/internet-drafts/draft-duan-smtp-receiver-dr= iven-00.txt

The abstract of the draft is attached below.

As we are new to the IETF process, we welcome any suggestions
pointing out potential improvements as well as deficiencies in the draft.
The following DiffMail project website and our related paper in SRUTI'05 might also be of interest.

http= ://www.cs.fsu.edu/~duan/projects/diffmail/diffmail.htm

Thanks,
Zhenhai Duan, Kartik Gopalan, Yingfei Dong

Abstract:

The Differentiated Mail Transfer Protocol (DMTP) provides simple
extensions to the Simple Mail Transfer Protocol (SMTP) that
enable receivers to exercise greater control over the email delivery
process. The current SMTP-based email delivery architecture is
fundamentally sender-driven and distinctly lacks receiver control over
the message delivery mechanism. This document describes DMTP
that enables receivers to classify senders into three categories -- allowed= ,
denied, and unclassified -- and process the delivery of messages
from each category independently. As is the current practice, receivers may directly accept messages from senders in the allowed
category and decline senders in the denied category. In addition,
DMTP receivers require senders in the unclassified category to
store messages on the senders' own mail servers. Such messages
are retrieved only if and when the end receivers wish to do so.
By granting greater control over message delivery to receivers and
imposing greater message storage and maintenance overhead on
senders, DMTP provides significant advantages in controlling spam.
DMTP also easily operates in conjunction with (but does not require)
many currently deployed anti-spam techniques.

------=_Part_25505_7975606.1115333510921-- --===============1997793446== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --===============1997793446==-- From lemonade-bounces@ietf.org Sun May 08 15:01:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUr28-0005N2-H8; Sun, 08 May 2005 15:01:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU7ou-0002vL-C5; Fri, 06 May 2005 14:45:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21867; Fri, 6 May 2005 14:44:58 -0400 (EDT) Received: from out2.smtp.messagingengine.com ([66.111.4.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU83M-0000mV-Rq; Fri, 06 May 2005 15:00:03 -0400 Received: from frontend3.messagingengine.com (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id C2119C8B2A7; Fri, 6 May 2005 14:44:55 -0400 (EDT) X-Sasl-enc: f+I8VeQJcZ2zBuD44Ey4/iaSWXBTT+AKPtcFTNDZlNhL 1115405095 Received: from [192.168.1.208] (banana.groupd.com [64.139.6.95]) by frontend3.messagingengine.com (Postfix) with ESMTP id 298145F; Fri, 6 May 2005 14:44:52 -0400 (EDT) Message-ID: <427BBB22.2090009@elvey.com> Date: Fri, 06 May 2005 11:44:50 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kartik Gopalan References: In-Reply-To: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -8.0 (--------) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 08 May 2005 15:01:42 -0400 Cc: lemonade@ietf.org, asrg@ietf.org, Yingfei Dong , ietf-smtp@imc.org Subject: [lemonade] Re: [Asrg] draft-duan-smtp-receiver-driven-00.txt (DMTP/DiffMail) X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Given the initial crosspost, I'm doing the same (though they may be rejected) and suggesting all follow-up go to one list, only. I suggest asrg. FEEDBACK: Yes, this is ~= IM2000, but with an improvement: it's potentially sometimes backward-compatible with SMTP. Generally, this draft (which I'll refer to as DMTP or DiffMail) has features (the draft lists 3 advantages*) that, IMO, are better provided by other systems. Addressing them in reverse order: 3)This is better provided by greylisting+. That forces the sender to maintain something like a real mail queue. 2)Standard use of DNSRBLs (and sometimes RHSBLs with CSV or SPF) reduces bandwidth and storage costs more effectively and is compatible with all senders and most receivers today, with no code changes, and generally require just trivial configuration changes. 1)Again, greylisting allows a receiver a window of opportunity to allow the sender to get on a BL (or the message to enter a razor2 type DB) before receiving the message. It is true, however, that DMTP does provide a potentially larger window, and does so without indroducing a significant delay. The question is, is this worth the cost of requiring senders and receivers support new commands and a new reply code? Confused by acronyms? See for elucidation. +See *Purported Advantages: "1. By asking senders (non-regular contacts) to maintain messages on their mail servers, spammers are forced to keep their servers up. They cannot simply send a large number of spam messages, shut down their servers, and switch to another domain (and/or change IP addresses). In this way, DiffMail helps to improve the effectiveness of IP-address-based filtering schemes. 2. Since a (complete) message is only retrieved by a receiver at his will, less bandwidth and storage resource will be consumed at the receiver side if the user does not retrieve the majority of messages from non-regular contacts. 3. Spammers now have more responsibilities to maintain their outgoing messages[.]" On 5/5/05 3:51 PM, Kartik Gopalan sent forth electrons to convey: _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue May 10 15:35:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVaVv-00034T-RZ; Tue, 10 May 2005 15:35:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVaVu-00033z-N4 for lemonade@megatron.ietf.org; Tue, 10 May 2005 15:35:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06305 for ; Tue, 10 May 2005 15:35:29 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DValG-0000Wp-Ve for lemonade@ietf.org; Tue, 10 May 2005 15:51:24 -0400 Received: by zproxy.gmail.com with SMTP id 18so2959148nzp for ; Tue, 10 May 2005 12:35:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QSwBPANZipn4sYbh30VSdLvh679U3XhAqvRmGCt0Ctkt1ZZSyY8mINplRt2Q/MD+7nT6/PUm9n1/zJ+z5/xd2vzwDt9Ye20Mms6XO+BrC+VXzi468amMO0VkNMzA/cWg/+9N0G6R1cP9HUHqXfosHSrFeCKKNBYYs3+tbr659NE= Received: by 10.36.109.16 with SMTP id h16mr1687362nzc; Tue, 10 May 2005 12:35:20 -0700 (PDT) Received: by 10.36.50.6 with HTTP; Tue, 10 May 2005 12:35:20 -0700 (PDT) Message-ID: Date: Tue, 10 May 2005 12:35:20 -0700 From: Kartik Gopalan To: John C Klensin In-Reply-To: <6730573FC732D83C70050BDB@scan.jck.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <6730573FC732D83C70050BDB@scan.jck.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable Cc: lemonade@ietf.org, asrg@ietf.org, ietf-smtp@imc.org Subject: [lemonade] Re: draft-duan-smtp-receiver-driven-00.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kartik Gopalan List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org John,=20 Thanks for your note. In DMTP, we use coarser MTA classifiers at the level of their IP address or domain names -- not the fine-grained email-address classifiers (as you seem to mention below). Using the latter would indeed have the problems you describe -- but DMTP I-D does not use email-address classifiers. Its possible to do that, but only with the kind of strong sender authentication you mention, which is the reason we steered away from them in the first place. - Kartik On 5/10/05, John C Klensin wrote: >=20 >=20 > --On Tuesday, 10 May, 2005 00:52 -0400 Kartik Gopalan > wrote: >=20 > >... > > DMTP gives solution to the scenario that none of the currently > > used anti-spam technologies can satisfactorily handle without > > receiving the entire message. DMTP intent messages are used > > ONLY for unclassified senders that are neither in receivers > > MTA's whitelists nor blacklists. It is only unclassified > > senders who are treated using the receiver-pull model. And > > even to this category you can apply the same > > sender-discouragement schemes that are currently being applied > > -- such as greylisting, any other challenge-response schemes, > > etc. > >... >=20 > Kartik, >=20 > I want to reinforce, from a different perspective, one of Tony's > points. >=20 > Ultimately, to let a message through, you are depending on a > whitelist that is, in turn, based on sender addresses. Your > greylist technique, effective or not, is ultimately just a > technique for determining which addresses get onto the > whitelist. That causes you to inherit all of the issues with > whitelists based on sender addresses, especially the fact that, > in the absence of strong authentication, sender addresses are > easily faked. If, as a receiver, I've got sufficient > infrastructure --probably, but perhaps not necessarily, PKI > machinery-- in place to authenticate sender addresses, then I > probably don't need your technique. If I don't, then all the > spammer needs to do is to send messages to me that are "from" > people whom I know and with whom I have corresponded in the > past. >=20 > Not only is that not hard, but they are doing it today. >=20 > That brings me to the serious downside of this, and many other, > "maybe it would help at least a little bit" ideas. Assume, > for purposes of argument, that the details of your proposal, > such as not understanding how to use the SMTP extension model, > can be sorted out. Assume you can get it widely enough > deployed in sending and receiving SMTP servers to make it useful > without putting huge burdens on legitimate, known, users trying > to exchange mail with each other (for better or worse, this is a > very high barrier). Now, what we end up with is: >=20 > (1) Another list of really-good addresses that can presumably be > easily harvested by an address-harvesting virus. Note that > your technique is of almost zero use against a spam generator > who relies on compromising a machine and using the sender name > to spam the people in the and address books or using the names > in the address book to spam the machine's owner from other > machines at a later date. In either case, names intentionally > put in the address book or whitelist are presumably already > whitelisted. >=20 > (2) Another cycle in which: (i) A technique reduces the amount > of spam that is received slightly. (ii) The spammers respond by > increasing the amount of spam sent by, say, twice that amount, > resulting in a slight increase in the amount of spam received. > (iii) The spammers then devise a countermeasure. In this case, > the countermeasure is quite easy: address-pair lists are > apparently already in heavy use by some spammer-enabling tools. > Net result is an increase in the total amount of spam being > delivered by around twice the amount that your method presumably > stopped. >=20 > Those "arms race" cycles are not good for anyone concerned. >=20 > john >=20 > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue May 10 18:27:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVdCX-0005DV-Sh; Tue, 10 May 2005 18:27:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVdCV-0005DM-H9 for lemonade@megatron.ietf.org; Tue, 10 May 2005 18:27:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29482 for ; Tue, 10 May 2005 18:27:36 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.204]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVdRt-0004Hj-8z for lemonade@ietf.org; Tue, 10 May 2005 18:43:34 -0400 Received: by zproxy.gmail.com with SMTP id 16so40845nzp for ; Tue, 10 May 2005 15:27:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lfwzfmM3icDHWHb7WxaGHvWDd7KvB0MukCnVDF3U1fA6vf70AQwGF2a8dQ6WE5FfZAo3XL0NjDE5oPY7iatrCCfAdAksCg5f/rjzaS88EwKSQlBSwzH0XZjBycnSbGEIOZuAqvLDIJZCzzy8elSIiRNNdKnt9qW5hT0gaI6Tbzo= Received: by 10.36.42.13 with SMTP id p13mr22443nzp; Tue, 10 May 2005 15:27:29 -0700 (PDT) Received: by 10.36.50.6 with HTTP; Tue, 10 May 2005 15:27:29 -0700 (PDT) Message-ID: Date: Tue, 10 May 2005 15:27:29 -0700 From: Kartik Gopalan To: Tony Finch In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: lemonade@ietf.org, asrg@ietf.org, ietf-smtp@imc.org Subject: [lemonade] Re: Re: draft-duan-smtp-receiver-driven-00.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kartik Gopalan List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org > > You missed one more piece of information in the notification: a > > limited subject header summarizing the contents. >=20 > A wonderful place to put a spam message and URL. It says "limited subject header" above which can include restrictions on placing URLs. (I had mentioned this already earlier.) > > 1) Your regular contacts will typically be in the allowed class. If > > you see a notification from your regular contact that is in the > > unclassified folder, it is easy to tell it is a faked message and you > > need not spend time on it. >=20 > This statement is not generally true. For example, the IP addresses of th= e > sending site's MTAs may have changed, or the sender may be roaming. Its the sender that's is roaming, not the sending MTA -- I don't see any problem. And if the sending MTA changes its IP address, the currently used IP-based blacklists and whitelists go for a toss anyway. So its not a new problem here. > > messages, they need to be in sync about state of outgoing message queue > > (for example, shared file systems). >=20 > Gee, that's a good idea. Imagine a shared filesystem supporting the whole > email infrastructure for millions of customers! Again, it said "for example" above. Its an engineering decision that would be different for different situations that designers make every day depending on the scale of the system. The point is to design the MTA to fit the email architecture, not to design the email architecture to fit the current MTA design. Else you are simply putting the cart before the horse. - Kartik _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 11 14:40:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVw8b-00028X-4h; Wed, 11 May 2005 14:40:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVw8Z-00028S-76 for lemonade@megatron.ietf.org; Wed, 11 May 2005 14:40:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04545 for ; Wed, 11 May 2005 14:40:49 -0400 (EDT) Received: from bra.gulbrandsen.priv.no ([212.125.101.197]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DVwO8-0007Rl-PN for lemonade@ietf.org; Wed, 11 May 2005 14:56:57 -0400 Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id B42751A72E; Wed, 11 May 2005 20:40:58 +0200 (CEST) Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 2874C1A6E7; Wed, 11 May 2005 20:39:04 +0200 (CEST) Message-Id: Date: Wed, 11 May 2005 20:38:15 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-smtp@imc.org References: <6730573FC732D83C70050BDB@scan.jck.com> <2873121D8E5BCBD53ED16ED0@scan.jck.com> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: asrg@ietf.org, David hagel Subject: [lemonade] Re: draft-duan-smtp-receiver-driven-00.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org David hagel writes: > its almost impossible to spoof tcp sessions now. spoofer needs to > correctly guess the randomly generated sequence/ack numbers. Have a look at http://www.completewhois.com/hijacked/ for an alternative, simpler approach. (And please don't spell your name like that. It makes you look like a 419 spammer.) Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 11 20:27:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW1Y5-0004Zr-9c; Wed, 11 May 2005 20:27:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVFep-0007av-Lk; Mon, 09 May 2005 17:19:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12785; Mon, 9 May 2005 17:19:17 -0400 (EDT) Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVFtw-0005Q6-J5; Mon, 09 May 2005 17:35:01 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:53702) by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1DVFef-0005M4-UE (Exim 4.51) (return-path ); Mon, 09 May 2005 22:19:09 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1DVFef-0005Rb-Ad (Exim 4.43) (return-path ); Mon, 09 May 2005 22:19:09 +0100 Date: Mon, 9 May 2005 22:19:09 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Kartik Gopalan In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-Mailman-Approved-At: Wed, 11 May 2005 20:27:31 -0400 Cc: dot@dotat.at, asrg@ietf.org, Yingfei Dong , lemonade@ietf.org, ietf-smtp@imc.org Subject: [lemonade] Re: draft-duan-smtp-receiver-driven-00.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org This draft is worthless. The fundamental idea that it shares with IM2000 is based on a mis-targeted optimisation. The main cost of spam is the human time it wastes, whereas disk space on the recipient servers is very cheap. In fact DMTP makes dealing with poorly-classified email MORE time-consuming than it is already, because a recipient must deal with a content-free notification (containing only a forged sender address and a message ID) as well as the actual message. If you enhance notification messages so that they are sufficiently informative for a recipient to be able to decide whether to retrieve the bulk message, then spammers will just put the entirety of their payload in the notification message. This has already occurred with certain kinds of mobile phone spam. When in doubt about the spamminess of a message it is better to receive the whole thing. This allows the full gamut of classification technology can be applied to it, so that there is a greater chance of it being classified before it wastes the time of a person. IM2000 and DMTP are also based on an incorrect assumption, that spam messages actually cost space on the senders disks. Most spam software is stateless, and it can continue to be in IM2000 or DMTP: the spammer just encodes enough information in the message ID in order to be able to reconstruct the message when it is requested. As well as being based on a fundamentally useless idea, the details of the specification are incompetent. It fails to use the SMTP extension model correctly. A client indicates that it wishes to use an extension by using a command from the extenstion or a MAIL or RCPT parameter, NOT by appending a keyword to its EHLO command. It shows a misunderstanding of the difference between the SMTP envelope and the message header. It has inexplicable colons in its command names, in contradiction to SMTP's requirement that commands are alphabetic. It makes assumptions about IP routeing which compromise the usability of DMTP with highly scaled MTA clusters, which often involve NAT and/or multi-homed servers. The attempt at cryptography in section 3.4 is laughable. Tony. -- f.a.n.finch http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 11 20:27:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW1Y5-0004aJ-K1; Wed, 11 May 2005 20:27:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVMjS-0000CF-AD for lemonade@megatron.ietf.org; Tue, 10 May 2005 00:52:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18131 for ; Tue, 10 May 2005 00:52:31 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.195]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVMyh-000434-HH for lemonade@ietf.org; Tue, 10 May 2005 01:08:19 -0400 Received: by zproxy.gmail.com with SMTP id 16so4436447nzp for ; Mon, 09 May 2005 21:52:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AWuE8OpV0H0jgqLKFF/4hJfMijxssQioAKdgfq0s7B1hDaBm52eMXLk70vF1Gk33OR8O+ffVoL8QYVvvbp8P9lz8ZenSIfMpaA6UIVCZ818qKlti+FtYqsW0P2MghQnwzSRr38Vpmk2VRm1bOGHSFPpbPS/it2L/v1fh8CKgVB4= Received: by 10.36.126.1 with SMTP id y1mr1306674nzc; Mon, 09 May 2005 21:52:24 -0700 (PDT) Received: by 10.36.50.6 with HTTP; Mon, 9 May 2005 21:52:24 -0700 (PDT) Message-ID: Date: Tue, 10 May 2005 00:52:24 -0400 From: Kartik Gopalan To: Tony Finch In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 11 May 2005 20:27:31 -0400 Cc: lemonade@ietf.org, asrg@ietf.org, Yingfei Dong , ietf-smtp@imc.org Subject: [lemonade] Re: draft-duan-smtp-receiver-driven-00.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kartik Gopalan List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Before replying to your comments specifically, we'd like to stress again that, unlike IM2000, DMTP classifies sender MTAs into three categories: allowed, denied, and unclassified. The receiver pull model is only used for messages from the unclassified category. Just as usual, whitelisted senders can send mail using normal SMTP and blacklisted ones are summarily declined, with no additional overhead. > The fundamental idea that it shares with IM2000 is based on a mis-targete= d > optimisation. The main cost of spam is the human time it wastes, whereas > disk space on the recipient servers is very cheap. DMTP holds the unclassified senders responsible for *managing* their own outgoing messages. Storage is just one component of this management. DMTP strongly discourages the current "fire-forget-and-disappear" behaviour of spammers who now need to wait (potentially indefinitely) for receivers to retrieve their messages. This goal can hardly be called a mis-targeted optimization. Now spammers would face the dilemma: They should online longer if they want more people to read, on the other hand, the longer they stay online, the more likely that they will be black listed. > In fact DMTP makes > dealing with poorly-classified email MORE time-consuming than it is > already, because a recipient must deal with a content-free notification > (containing only a forged sender address and a message ID) as well as the > actual message. DMTP gives solution to the scenario that none of the currently used anti-spam technologies can satisfactorily handle without receiving the entire message. DMTP intent messages are used ONLY for unclassified senders that are neither in receivers MTA's whitelists nor blacklists. It is only unclassified senders who are treated using the receiver-pull model. And even to this category you can apply the same sender-discouragement schemes that are currently being applied -- such as greylisting, any other challenge-response schemes, etc. > If you enhance notification messages so that they are sufficiently > informative for a recipient to be able to decide whether to retrieve the > bulk message, then spammers will just put the entirety of their payload i= n > the notification message. This has already occurred with certain kinds of > mobile phone spam. First, this is inevitable in *ANY* form of communication where you wish to allow untrusted parties to communicate with you (or to express their intent to communicate). It is just like when your phone rings and you can't recognize the caller ID, you either ignore it or pick it up anyway. If its a wrong number, prank call, or a telemarketer, you simply hang up. So the problem is not specific to DMTP. Secondly, DMTP requires a configurable upper limit on the notification size. It is effective to the extent that it limits the content of SPAM delivered (just as phone caller ID helps in making an initial decision). If one wishes, one could place additional restrictions like not permitting HTML tags in the notification to make spammer's life more difficult. > When in doubt about the spamminess of a message it is better to receive > the whole thing. This allows the full gamut of classification technology > can be applied to it, so that there is a greater chance of it being > classified before it wastes the time of a person. One can still apply the whole gamut of classification technologies on any complete emails in DMTP. Handling intent messages for a small unclassified category of senders will not be too much of trouble. This can even be implemented as transparently as retrieving the complete message when *and only when* the receiver issues the open command on the intent message at his/her MUA (again simply like deciding whether to press talk/ignore upon receiving a caller-ID on the phone). =20 > IM2000 and DMTP are also based on an incorrect assumption, that spam > messages actually cost space on the senders disks. Most spam software is > stateless, and it can continue to be in IM2000 or DMTP: the spammer just > encodes enough information in the message ID in order to be able to > reconstruct the message when it is requested. As mentioned earlier, the primary goal is to discourage the "fire-forget-and-disappear" behaviour that the current sender-push model of SMTP encourages. Storage overhead is only one small part of the picture. The bigger advantage is that spammer MTA needs to be up and running for potentially indefinite duration if it wants the receiver to read the entire message. In any event, storage becomes one less problem for the receiver to deal with even if the spammer does the kind of encoding you mention above. > It fails to use the SMTP extension model correctly. A client indicates > that it wishes to use an extension by using a command from the extenstion > or a MAIL or RCPT parameter, NOT by appending a keyword to its EHLO > command. It shows a misunderstanding of the difference between the SMTP > envelope and the message header. It has inexplicable colons in its comman= d > names, in contradiction to SMTP's requirement that commands are > alphabetic. The above is more a issue of syntax than of content and can be easily addressed. We have noticed this issue already and are fixing it in our next draft. As mentioned in the initial post, being new to IETF process we appreciate such feedback. =20 > It makes assumptions about IP routeing which compromise the usability of > DMTP with highly scaled MTA clusters, which often involve NAT and/or > multi-homed servers. There is no assumption about IP routing anywhere in the draft. It is true if you mean making MTA clusters DMTP-compliant would require changes depending on nature of the cluster. However these are fairly simple and straightforward changes. Also note that DMTP-compliant MTAs can interoperate with non-DMTP-compliant legacy MTAs, whether latter is a scalable cluster or standalone MTA. If the latter is whitelisted with the former, the transaction is same as regular SMTP. If the latter is unclassified, it is subject to sender-discouragement mechanisms at the same cost as today. > The attempt at cryptography in section 3.4 is laughable. There is no attempt at PKI whatsoever, if that is what you mean. The terminology may be similar and can be easily clarified. If you read that section carefully, the sole purpose of the related paragraph is to make the mapping between a message id and a message itself less guessable, and to speedup the lookup of the message when the message id is presented. Moreover, as stated in the section, this is just one of possible design choices. Different schemes can be deployed by different MTAs, as long as it achieves the above purpose, given that this is really a local matter at the sending MTAs. - Kartik _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 11 20:27:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW1Y5-0004ai-Sh; Wed, 11 May 2005 20:27:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVRe8-0007Q8-G3; Tue, 10 May 2005 06:07:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03920; Tue, 10 May 2005 06:07:22 -0400 (EDT) Received: from ppsw-1.csi.cam.ac.uk ([131.111.8.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVRtO-0002ZM-Hf; Tue, 10 May 2005 06:23:13 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:56222) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:fanf2) id 1DVRe1-0006eg-4h (Exim 4.51) (return-path ); Tue, 10 May 2005 11:07:17 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1DVRe1-0000ig-8b (Exim 4.43) (return-path ); Tue, 10 May 2005 11:07:17 +0100 Date: Tue, 10 May 2005 11:07:17 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Kartik Gopalan In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-Mailman-Approved-At: Wed, 11 May 2005 20:27:31 -0400 Cc: lemonade@ietf.org, asrg@ietf.org, Yingfei Dong , Tony Finch , ietf-smtp@imc.org Subject: [lemonade] Re: draft-duan-smtp-receiver-driven-00.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Tue, 10 May 2005, Kartik Gopalan wrote: > > DMTP classifies sender MTAs into three categories: allowed, denied, and > unclassified. So do SMTP servers. > The receiver pull model is only used for messages from the unclassified > category. And this is the category of messages where it is least useful. You are forcing people to guess whether they want to receive a message before you have expended any automated effort to classify it. > > When in doubt about the spamminess of a message it is better to receive > > the whole thing. This allows the full gamut of classification technology > > can be applied to it, so that there is a greater chance of it being > > classified before it wastes the time of a person. > > One can still apply the whole gamut of classification technologies on > any complete emails in DMTP. But only after you have wasted someone's time. You have not addressed the user interface issues of DMTP. How is a user supposed to decide whether to receive a message given only the sender address and message ID? You suggest that message IDs should be cryptographically generated, and therefore meaningless to people, and you do not address the problem of forged sender addresses. Therefore DMTP's notification messages are useless to the recipient. > > It makes assumptions about IP routeing which compromise the usability of > > DMTP with highly scaled MTA clusters, which often involve NAT and/or > > multi-homed servers. > > There is no assumption about IP routing anywhere in the draft. You are assuming that each server's idea of its own IP address is the same as the other TCP endpoint's idea of it. You are assuming that incoming and outgoing connections to an MTA are symmetrical. > > The attempt at cryptography in section 3.4 is laughable. > > There is no attempt at PKI whatsoever, if that is what you mean. No, I mean that you are using a cryptographic hash incompetently. Tony. -- f.a.n.finch http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 11 20:27:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW1Y6-0004b7-4k; Wed, 11 May 2005 20:27:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVTVd-0001dA-7x; Tue, 10 May 2005 08:06:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19296; Tue, 10 May 2005 08:06:43 -0400 (EDT) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVTkv-0002uk-41; Tue, 10 May 2005 08:22:34 -0400 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1DVTVN-000LUK-4O; Tue, 10 May 2005 08:06:29 -0400 Date: Tue, 10 May 2005 08:06:29 -0400 From: John C Klensin To: Kartik Gopalan , Tony Finch Message-ID: <6730573FC732D83C70050BDB@scan.jck.com> In-Reply-To: References: X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 11 May 2005 20:27:31 -0400 Cc: lemonade@ietf.org, asrg@ietf.org, Yingfei Dong , ietf-smtp@imc.org Subject: [lemonade] Re: draft-duan-smtp-receiver-driven-00.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --On Tuesday, 10 May, 2005 00:52 -0400 Kartik Gopalan wrote: >... > DMTP gives solution to the scenario that none of the currently > used anti-spam technologies can satisfactorily handle without > receiving the entire message. DMTP intent messages are used > ONLY for unclassified senders that are neither in receivers > MTA's whitelists nor blacklists. It is only unclassified > senders who are treated using the receiver-pull model. And > even to this category you can apply the same > sender-discouragement schemes that are currently being applied > -- such as greylisting, any other challenge-response schemes, > etc. >... Kartik, I want to reinforce, from a different perspective, one of Tony's points. Ultimately, to let a message through, you are depending on a whitelist that is, in turn, based on sender addresses. Your greylist technique, effective or not, is ultimately just a technique for determining which addresses get onto the whitelist. That causes you to inherit all of the issues with whitelists based on sender addresses, especially the fact that, in the absence of strong authentication, sender addresses are easily faked. If, as a receiver, I've got sufficient infrastructure --probably, but perhaps not necessarily, PKI machinery-- in place to authenticate sender addresses, then I probably don't need your technique. If I don't, then all the spammer needs to do is to send messages to me that are "from" people whom I know and with whom I have corresponded in the past. Not only is that not hard, but they are doing it today. That brings me to the serious downside of this, and many other, "maybe it would help at least a little bit" ideas. Assume, for purposes of argument, that the details of your proposal, such as not understanding how to use the SMTP extension model, can be sorted out. Assume you can get it widely enough deployed in sending and receiving SMTP servers to make it useful without putting huge burdens on legitimate, known, users trying to exchange mail with each other (for better or worse, this is a very high barrier). Now, what we end up with is: (1) Another list of really-good addresses that can presumably be easily harvested by an address-harvesting virus. Note that your technique is of almost zero use against a spam generator who relies on compromising a machine and using the sender name to spam the people in the and address books or using the names in the address book to spam the machine's owner from other machines at a later date. In either case, names intentionally put in the address book or whitelist are presumably already whitelisted. (2) Another cycle in which: (i) A technique reduces the amount of spam that is received slightly. (ii) The spammers respond by increasing the amount of spam sent by, say, twice that amount, resulting in a slight increase in the amount of spam received. (iii) The spammers then devise a countermeasure. In this case, the countermeasure is quite easy: address-pair lists are apparently already in heavy use by some spammer-enabling tools. Net result is an increase in the total amount of spam being delivered by around twice the amount that your method presumably stopped. Those "arms race" cycles are not good for anyone concerned. john _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 11 20:27:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW1Y6-0004bX-CU; Wed, 11 May 2005 20:27:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVatR-0005rf-VW; Tue, 10 May 2005 15:59:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08062; Tue, 10 May 2005 15:59:48 -0400 (EDT) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVb8o-0001ux-DU; Tue, 10 May 2005 16:15:43 -0400 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1DVatN-000PcJ-DO; Tue, 10 May 2005 15:59:45 -0400 Date: Tue, 10 May 2005 15:59:45 -0400 From: John C Klensin To: Kartik Gopalan , John C Klensin Message-ID: <2873121D8E5BCBD53ED16ED0@scan.jck.com> In-Reply-To: References: <6730573FC732D83C70050BDB@scan.jck.com> X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 11 May 2005 20:27:31 -0400 Cc: lemonade@ietf.org, asrg@ietf.org, ietf-smtp@imc.org Subject: [lemonade] Re: draft-duan-smtp-receiver-driven-00.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --On Tuesday, 10 May, 2005 12:35 -0700 Kartik Gopalan wrote: > Thanks for your note. In DMTP, we use coarser MTA classifiers > at the level of their IP address or domain names -- not the > fine-grained email-address classifiers (as you seem to mention > below). Using the latter would indeed have the problems you > describe -- but DMTP I-D does not use email-address > classifiers. Its possible to do that, but only with the kind > of strong sender authentication you mention, which is the > reason we steered away from them in the first place. Unless you abandon mail relaying, and perhaps even if you do, domain names and IP addresses are as easily spoofed as full email addresses. The spammers figured both out many years ago. john _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 11 20:27:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW1Y6-0004bx-K8; Wed, 11 May 2005 20:27:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVaxn-00083f-5m; Tue, 10 May 2005 16:04:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09566; Tue, 10 May 2005 16:04:17 -0400 (EDT) Received: from cs2075.cs.fsu.edu ([128.186.122.75] helo=mail.cs.fsu.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVbD9-0002ZD-B3; Tue, 10 May 2005 16:20:11 -0400 Received: from diablo.cs.fsu.edu (diablo.cs.fsu.edu [128.186.120.2]) by mail.cs.fsu.edu (Postfix) with ESMTP id 453A6F2A47; Tue, 10 May 2005 16:04:58 -0400 (EDT) Received: from localhost (duan@localhost) by diablo.cs.fsu.edu (8.13.2/8.13.2/Submit) with ESMTP id j4AK3RT0022824; Tue, 10 May 2005 16:03:27 -0400 (EDT) X-Authentication-Warning: diablo.cs.fsu.edu: duan owned process doing -bs Date: Tue, 10 May 2005 16:03:26 -0400 (EDT) From: Zhenhai Duan To: Tony Finch In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f X-Mailman-Approved-At: Wed, 11 May 2005 20:27:31 -0400 Cc: lemonade@ietf.org, asrg@ietf.org, Yingfei Dong , ietf-smtp@imc.org Subject: [lemonade] Re: Re: draft-duan-smtp-receiver-driven-00.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Tony, Thank you for the helpful discussions. Let me try to clarify some of the intuition behind the schemes in the I-D. >> DMTP classifies sender MTAs into three categories: allowed, denied, and >> unclassified. > > So do SMTP servers. Our comparison above was to IM2000. Indeed the current SMTP servers know how to handle senders that are denied (blacklisted), or allowed (whitelisted). A message that falls in neither class is currently subject to the content filters to decide if it is a spam message or not. To put it another way, the current SMTP does not have an explicit concept of unclassified senders. The one we are aware of that supports the similar concept is Greylisting, which defines unclassified sources as new triplets that are not in the whitelist and blacklist yet. However, as other people on this list have pointed out already, spammers haven't yet adapted to this scheme because it hasn't impacted their bottomline. This would happen once greylisting becomes widespread. >> The receiver pull model is only used for messages from the unclassified >> category. > > And this is the category of messages where it is least useful. You are > forcing people to guess whether they want to receive a message before you > have expended any automated effort to classify it. > This really is related to what kind of classification we are talking about. As one example, the receiver can configure his/her MTA such that most regular contacts are in the allowed class. As a consequence, after a brief learning time period, most important messages fall in the allowed category (that do not need the notification process) and the receiver pays only infrequent attention to the notifications in the unclassfied folder. Note that this definition of classification is different and orthogonal from classifying a message based on its content. Occasionally, an important message may lie unread for a long time -- its not desirable but it is not a new problem. It happens even now with automated content-based classifiers you mention above. You get false positives all the time even now -- they are either tagged as [SPAM] to be stored away in a junk folder or (worse yet) deleted without receiver's knowledge. With DMTP, at least receiver gets to periodically review the notifications from these unclassified senders (if receivers so choose to). > You have not addressed the user interface issues of DMTP. How is a user > supposed to decide whether to receive a message given only the sender > address and message ID? You suggest that message IDs should be > cryptographically generated, and therefore meaningless to people, and you > do not address the problem of forged sender addresses. Therefore DMTP's > notification messages are useless to the recipient. You missed one more piece of information in the notification: a limited subject header summarizing the contents. You may say that "well subject can be misleading and sender address can be forged to make it appear like a regular contact". Its possible and happens with viruses all the time. But this technique is useless to spammers because it doesn't help them to send the tremendous volume of commercial traffic that makes spamming so attractive. Just imagine the amount of state and association they need to maintain per spammed receiver to make heavy volume mailing successful with this technique. Also, 1) Your regular contacts will typically be in the allowed class. If you see a notification from your regular contact that is in the unclassified folder, it is easy to tell it is a faked message and you need not spend time on it. 2) For the other legitimate senders that are not in your allowed class, how often you hear from them? and how likely is it that a spammer knows that this is not only your legitimate contact but ALSO is not in your regular contact class? > You are assuming that each server's idea of its own IP address is the same > as the other TCP endpoint's idea of it. You are assuming that incoming and > outgoing connections to an MTA are symmetrical. This is a good point and Kartik's email addressed your question to some extent by mentioning that some MTA modifications are inevitable to make them DMTP-compliant. As it is in the current draft, the sender MTA IP address is used for the RMTA to retrieve the complete message. We made this choice because of security concerns and also for the simplicity of the RMTA. It is possible that instead of relying on RMTA to record the SMTA IP address, we can do a DNS MX lookup of sender email address to get the MTA IP address at the sender side. However, this indeed means that if sender side uses different MTA servers for incoming and outgoing messages, they need to be in sync about state of outgoing message queue (for example, shared file systems). In the long run, its a tradeoff worth making. >> There is no attempt at PKI whatsoever, if that is what you mean. > > No, I mean that you are using a cryptographic hash incompetently. > We do not quite see you mentioning a specific concern here. As long as the sender-side hash serves the purpose, it does not matter how simple/complicated it is. For example, when you subscribe to a mailing list, you normally receive a message asking you to confirm the intent to subscribe. How complicated do you think the method to generate the random text on the Subject line is? Thank you, -Zhenhai _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 11 20:27:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW1Y6-0004cM-Rw; Wed, 11 May 2005 20:27:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVbkb-0004dO-2G; Tue, 10 May 2005 16:54:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19788; Tue, 10 May 2005 16:54:42 -0400 (EDT) Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVbzu-0007OJ-KL; Tue, 10 May 2005 17:10:39 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:47410) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1DVbkP-00088b-NP (Exim 4.51) (return-path ); Tue, 10 May 2005 21:54:33 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1DVbkP-0004dt-6w (Exim 4.43) (return-path ); Tue, 10 May 2005 21:54:33 +0100 Date: Tue, 10 May 2005 21:54:33 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Zhenhai Duan In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-Mailman-Approved-At: Wed, 11 May 2005 20:27:31 -0400 Cc: lemonade@ietf.org, asrg@ietf.org, Yingfei Dong , Tony Finch , ietf-smtp@imc.org Subject: [lemonade] Re: Re: draft-duan-smtp-receiver-driven-00.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org > You missed one more piece of information in the notification: a > limited subject header summarizing the contents. A wonderful place to put a spam message and URL. > 1) Your regular contacts will typically be in the allowed class. If > you see a notification from your regular contact that is in the > unclassified folder, it is easy to tell it is a faked message and you > need not spend time on it. This statement is not generally true. For example, the IP addresses of the sending site's MTAs may have changed, or the sender may be roaming. > 2) For the other legitimate senders that are not in your allowed > class, how often you hear from them? These kinds of messages are frequently extremely valuable. > It is possible that instead of relying on RMTA to record the SMTA IP > address, we can do a DNS MX lookup of sender email address to get the > MTA IP address at the sender side. However, this indeed means that if > sender side uses different MTA servers for incoming and outgoing > messages, they need to be in sync about state of outgoing message queue > (for example, shared file systems). Gee, that's a good idea. Imagine a shared filesystem supporting the whole email infrastructure for millions of customers! Tony. -- f.a.n.finch http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 11 20:27:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW1Y7-0004co-4f; Wed, 11 May 2005 20:27:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVvEs-0007OO-Il for lemonade@megatron.ietf.org; Wed, 11 May 2005 13:43:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26805 for ; Wed, 11 May 2005 13:43:15 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.201]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVvUO-00045H-J6 for lemonade@ietf.org; Wed, 11 May 2005 13:59:23 -0400 Received: by zproxy.gmail.com with SMTP id 13so340746nzp for ; Wed, 11 May 2005 10:43:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bedW0PbS8OwQsIRAY5q2R/7del6HKDfLjiGbbXQMkfNG7UskLGEAcRjBPLCAuDOayboBKxS8/rulkMxv77ISohuC/znghW2J9fzTITuUq0G/RyibVNjUmdVlyBweEYYM319kRm6Al9ydfwSUrWQoAQSzO8/ZWqqQ3BGgKs99FO0= Received: by 10.36.148.3 with SMTP id v3mr272961nzd; Wed, 11 May 2005 10:43:05 -0700 (PDT) Received: by 10.36.25.18 with HTTP; Wed, 11 May 2005 10:43:05 -0700 (PDT) Message-ID: Date: Wed, 11 May 2005 10:43:05 -0700 From: David hagel To: ietf-smtp@imc.org, asrg@ietf.org, lemonade@ietf.org In-Reply-To: <2873121D8E5BCBD53ED16ED0@scan.jck.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <6730573FC732D83C70050BDB@scan.jck.com> <2873121D8E5BCBD53ED16ED0@scan.jck.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 11 May 2005 20:27:31 -0400 Cc: Subject: [lemonade] Re: draft-duan-smtp-receiver-driven-00.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David hagel List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On 5/10/05, John C Klensin wrote: > > Unless you abandon mail relaying, and perhaps even if you do, > domain names and IP addresses are as easily spoofed as full > email addresses. The spammers figured both out many years ago. > you're mistaken. udp spoofing is easy BUT smtp uses tcp. its almost impossible to spoof tcp sessions now. spoofer needs to correctly guess the randomly generated sequence/ack numbers. even if you magically do this, you gotta control ALL intermediate routers or else smtp server's responses will be misdirected. meaning you cannot create a normal tcp session. it's a common misconception that "ip spoofing" can be used to hide your ip address while surfing the net, chatting on-line, sending e-mail, and so forth. this is not true unless you're on the same subnet as victim where you can sniff their tcp seq. #'s. if whay you say is true, all DNSBLs would stop working dude. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 11 20:27:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW1Y7-0004dd-Ep; Wed, 11 May 2005 20:27:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVvXx-0002AU-MU; Wed, 11 May 2005 14:03:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28323; Wed, 11 May 2005 14:03:00 -0400 (EDT) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVvnV-000560-J8; Wed, 11 May 2005 14:19:07 -0400 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1DVvXj-0009YX-04; Wed, 11 May 2005 14:02:47 -0400 Date: Wed, 11 May 2005 14:02:46 -0400 From: John C Klensin To: David hagel , ietf-smtp@imc.org, asrg@ietf.org, lemonade@ietf.org Message-ID: In-Reply-To: References: <6730573FC732D83C70050BDB@scan.jck.com> <2873121D8E5BCBD53ED16ED0@scan.jck.com> X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 11 May 2005 20:27:31 -0400 Cc: Subject: [lemonade] Re: draft-duan-smtp-receiver-driven-00.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --On Wednesday, 11 May, 2005 10:43 -0700 David hagel wrote: > > On 5/10/05, John C Klensin wrote: >> >> Unless you abandon mail relaying, and perhaps even if you do, >> domain names and IP addresses are as easily spoofed as full >> email addresses. The spammers figured both out many years >> ago. >> > > you're mistaken. udp spoofing is easy BUT smtp uses tcp. > its almost impossible to spoof tcp sessions now. > spoofer needs to correctly guess the randomly generated > sequence/ack numbers. even if you magically do this, you gotta > control ALL intermediate routers or else smtp server's > responses will be misdirected. meaning you cannot create a > normal tcp session. > it's a common misconception that "ip spoofing" > can be used to hide your ip address while surfing the net, > chatting on-line, sending e-mail, and so forth. > this is not true unless you're on the same subnet as victim > where you can sniff their tcp seq. #'s. > if whay you say is true, all DNSBLs would stop working dude. (The reply below was previously sent privately because Mr Hagel and/or his MUA seem to be unable to send an individual message that reflects the mailing lists to which it was copied.) David, I am, "dude" or not, somewhat familiar with how SMTP works. There are rumors that I actually also understand something about TCP and about the DNS, but those rumors are less well established. However, the comment I made is not dependent on TCP, merely on the ability of a spammer who is operating an SMTP-sender to fake the Received headers in a message prior to those representing the SMTP-receiver over which you have presumed control and/or trust. There are various tricks for detecting such spoofing. Some of them can be quite effective against spammers who are either dumb or too lazy to be careful and intelligent about construction of those trace fields... both of which disabilities tend to disappear if their incentives were strong enough. That situation is precisely why I started my comment with "unless you abandon mail relaying". If you insist on direct connections between the initial sender (or an MTA that will take responsibility for the sender and which you trust to do so) and the receiver/ delivery SMTP server, then you are quite right and the spoofing issue depends on control of intermediate routers (and/or much more sophisticated tricks). But, as long as intermediate SMTP relays (not routers, but at the SMTP level) continue to be permitted, TCP is just not the issue because there is no end to end connection. The workings of most blacklists have nothing to do with this because they depend on either most-recent-hop or on assumptions about [dis]trusted SMTP servers at intermediate points rather than, as this does, properties of the initiating sender system. And, of course, if they worked better, you presumably would not need the draft in question. john _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 11 20:27:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW1Y7-0004eM-O8; Wed, 11 May 2005 20:27:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVwFw-0004k6-85 for lemonade@megatron.ietf.org; Wed, 11 May 2005 14:48:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06900 for ; Wed, 11 May 2005 14:48:25 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.194]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVwVU-0007x7-2A for lemonade@ietf.org; Wed, 11 May 2005 15:04:33 -0400 Received: by zproxy.gmail.com with SMTP id 13so375787nzp for ; Wed, 11 May 2005 11:48:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=W7QYiqsdO6ZVZP0N0jY2oNXJ4p22JLoBNWsAfnu4ycuhJvEtYW3M6hPuvMt+r/yoAlpVrEtIhqqskbZ8sHGZNR24qI/KaX+z/aHaslLTtxmCSaTLP1CYC3CT8X0b2H3Ri3atBzKvJq3JN0tqh5Q6pS1E9OnM/56kYGkCc6eSwFs= Received: by 10.36.158.13 with SMTP id g13mr320883nze; Wed, 11 May 2005 11:48:17 -0700 (PDT) Received: by 10.36.25.18 with HTTP; Wed, 11 May 2005 11:48:17 -0700 (PDT) Message-ID: Date: Wed, 11 May 2005 11:48:17 -0700 From: David hagel To: John C Klensin In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <6730573FC732D83C70050BDB@scan.jck.com> <2873121D8E5BCBD53ED16ED0@scan.jck.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 11 May 2005 20:27:31 -0400 Cc: lemonade@ietf.org, asrg@ietf.org, ietf-smtp@imc.org Subject: [lemonade] Re: draft-duan-smtp-receiver-driven-00.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David hagel List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org > That situation is precisely why I started my comment with > "unless you abandon mail relaying". If you insist on direct > connections between the initial sender (or an MTA that will take > responsibility for the sender and which you trust to do so) and > the receiver/ delivery SMTP server, then you are quite right and > the spoofing issue depends on control of intermediate routers > (and/or much more sophisticated tricks). But, as long as > intermediate SMTP relays (not routers, but at the SMTP level) > continue to be permitted, TCP is just not the issue because > there is no end to end connection. >=20 > The workings of most blacklists have nothing to do with this > because they depend on either most-recent-hop or on assumptions > about [dis]trusted SMTP servers at intermediate points rather > than, as this does, properties of the initiating sender system. ah, then ip spoofing is not quite the same as hiding behind=20 someone else's mail relays. i admit missing the connection=20 you made there. but open mail relays are hated and justifiably blacklisted= =20 aggresively (i am sure you know). its the right thing to do. ain't it? no harm blocking someone who lets their mail server to be=20 used by spammers. david _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 11 20:27:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW1Y8-0004eo-0e; Wed, 11 May 2005 20:27:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVwJA-00061s-1C; Wed, 11 May 2005 14:51:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07853; Wed, 11 May 2005 14:51:46 -0400 (EDT) Received: from cs2075.cs.fsu.edu ([128.186.122.75] helo=mail.cs.fsu.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVwYg-0008IM-L4; Wed, 11 May 2005 15:07:53 -0400 Received: from diablo.cs.fsu.edu (diablo.cs.fsu.edu [128.186.120.2]) by mail.cs.fsu.edu (Postfix) with ESMTP id 0E3F6F2A0C; Wed, 11 May 2005 14:52:51 -0400 (EDT) Received: from localhost (duan@localhost) by diablo.cs.fsu.edu (8.13.2/8.13.2/Submit) with ESMTP id j4BIpIGl006266; Wed, 11 May 2005 14:51:18 -0400 (EDT) X-Authentication-Warning: diablo.cs.fsu.edu: duan owned process doing -bs Date: Wed, 11 May 2005 14:51:18 -0400 (EDT) From: Zhenhai Duan To: Tony Finch In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-Mailman-Approved-At: Wed, 11 May 2005 20:27:31 -0400 Cc: lemonade@ietf.org, asrg@ietf.org, Yingfei Dong , ietf-smtp@imc.org Subject: [lemonade] Re: Re: Re: draft-duan-smtp-receiver-driven-00.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Tony, > >> It is possible that instead of relying on RMTA to record the SMTA IP >> address, we can do a DNS MX lookup of sender email address to get the >> MTA IP address at the sender side. However, this indeed means that if >> sender side uses different MTA servers for incoming and outgoing >> messages, they need to be in sync about state of outgoing message queue >> (for example, shared file systems). > > Gee, that's a good idea. Imagine a shared filesystem supporting the whole > email infrastructure for millions of customers! > I think there is some misunderstanding. Note that this is for supporting MTA clusters. Shared file systems/NFS/Replications are used in today's MTA clusters. -Zhenhai > Tony. > -- > f.a.n.finch http://dotat.at/ > BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR > GOOD. > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 11 20:27:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW1Y8-0004fS-AA; Wed, 11 May 2005 20:27:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVwWs-00017V-4w; Wed, 11 May 2005 15:05:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09086; Wed, 11 May 2005 15:05:56 -0400 (EDT) Received: from cs2075.cs.fsu.edu ([128.186.122.75] helo=mail.cs.fsu.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVwmQ-0000YU-MU; Wed, 11 May 2005 15:22:04 -0400 Received: from diablo.cs.fsu.edu (diablo.cs.fsu.edu [128.186.120.2]) by mail.cs.fsu.edu (Postfix) with ESMTP id DBCCCF2A0C; Wed, 11 May 2005 15:07:02 -0400 (EDT) Received: from localhost (duan@localhost) by diablo.cs.fsu.edu (8.13.2/8.13.2/Submit) with ESMTP id j4BJ5Us2006395; Wed, 11 May 2005 15:05:30 -0400 (EDT) X-Authentication-Warning: diablo.cs.fsu.edu: duan owned process doing -bs Date: Wed, 11 May 2005 15:05:30 -0400 (EDT) From: Zhenhai Duan To: John C Klensin In-Reply-To: Message-ID: References: <6730573FC732D83C70050BDB@scan.jck.com> <2873121D8E5BCBD53ED16ED0@scan.jck.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-Mailman-Approved-At: Wed, 11 May 2005 20:27:31 -0400 Cc: lemonade@ietf.org, asrg@ietf.org, David hagel , ietf-smtp@imc.org Subject: [lemonade] Re: draft-duan-smtp-receiver-driven-00.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org John, > > That situation is precisely why I started my comment with > "unless you abandon mail relaying". If you insist on direct > connections between the initial sender (or an MTA that will take > responsibility for the sender and which you trust to do so) and > the receiver/ delivery SMTP server, then you are quite right and > the spoofing issue depends on control of intermediate routers > (and/or much more sophisticated tricks). But, as long as > intermediate SMTP relays (not routers, but at the SMTP level) > continue to be permitted, TCP is just not the issue because > there is no end to end connection. This (open relay) is one part that puzzled me from time to time. Correct me if I am wrong. In the early days, the Internet is not stable and we may have difficults sometime to deliver a message from the source MTA directly to the destination MTA. Under this kind of circumstance, I may appreciate open relays. However, as the Internet is getting so (reasonably) reliable. I think some assumption should be changed. I do not know how often we still encounter network problems when we (sender) try to deliver a message to a receiver. I assume it is rare. And even if this happens, I do not see it is a big problem for the original SMTA to hold the message and retry later. In a nutshell, I believe all open relays should be disabled or otherwise blocked. (I do not want to go into a fight:-), so I make it clear that we are talking about open relay, not MTA clusters, not the cases where a company have multiple MTAs, and one (or more) are used for external-internal interface, while others are used internals and depending on the interface MTA to do the relay. It can be seen that these situations can be addressed adequately.) -Zhenhai > > The workings of most blacklists have nothing to do with this > because they depend on either most-recent-hop or on assumptions > about [dis]trusted SMTP servers at intermediate points rather > than, as this does, properties of the initiating sender system. > And, of course, if they worked better, you presumably would not > need the draft in question. > > john > > > > > > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed May 11 20:27:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW1Y8-0004gK-Tk; Wed, 11 May 2005 20:27:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVwgO-0002nM-Du for lemonade@megatron.ietf.org; Wed, 11 May 2005 15:15:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10350 for ; Wed, 11 May 2005 15:15:46 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.196]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVwvw-00011s-VI for lemonade@ietf.org; Wed, 11 May 2005 15:31:54 -0400 Received: by zproxy.gmail.com with SMTP id 13so388154nzp for ; Wed, 11 May 2005 12:15:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NZhE571TF67Wh8rUUj3dfxyJg6a3a4tkHm7EqEsA8O52D7P6heAy67jQahseiGNH1/iVHgF+cIcY51ep+N6VQx9cYWX2cZVaY7q5BLonkCHP2KOyD7X8rddzwl8FOuD5jvZLdm5gpgSA/1N5tK93BBFU02ztjCp8pVQ1nMHt958= Received: by 10.36.154.8 with SMTP id b8mr321124nze; Wed, 11 May 2005 12:15:37 -0700 (PDT) Received: by 10.36.25.18 with HTTP; Wed, 11 May 2005 12:15:37 -0700 (PDT) Message-ID: Date: Wed, 11 May 2005 12:15:37 -0700 From: David Hagel To: Arnt Gulbrandsen In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <6730573FC732D83C70050BDB@scan.jck.com> <2873121D8E5BCBD53ED16ED0@scan.jck.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 11 May 2005 20:27:31 -0400 Cc: lemonade@ietf.org, asrg@ietf.org, ietf-smtp@imc.org Subject: [lemonade] Re: draft-duan-smtp-receiver-driven-00.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Hagel List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On 5/11/05, Arnt Gulbrandsen wrote: > David hagel writes: > > its almost impossible to spoof tcp sessions now. spoofer needs to > > correctly guess the randomly generated sequence/ack numbers. >=20 > Have a look at http://www.completewhois.com/hijacked/ for an > alternative, simpler approach. granted one can steal whole ip blocks.=20 its still ok blacklisting those ip blocks if its in the hands of spammers. right? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon May 16 06:11:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXcZF-0002A2-EP; Mon, 16 May 2005 06:11:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXcZD-00029x-9v for lemonade@megatron.ietf.org; Mon, 16 May 2005 06:11:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19498 for ; Mon, 16 May 2005 06:11:16 -0400 (EDT) Received: from monkey.teamware.com ([62.61.83.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXcpi-0006p3-9F for lemonade@ietf.org; Mon, 16 May 2005 06:28:23 -0400 Received: from mx.teamw.com (mx.teamw.com [10.142.128.25]) by monkey.teamware.com (8.11.6/8.11.6) with ESMTP id j4GACsK09838 for ; Mon, 16 May 2005 13:12:54 +0300 Received: from [10.142.1.4] ([10.142.1.4]) (authenticated bits=0) by mx.teamw.com (8.12.8/8.12.8) with ESMTP id j4GAF3kx026776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 16 May 2005 13:15:04 +0300 Message-ID: <428871AF.9020505@teamware.com> Date: Mon, 16 May 2005 11:10:55 +0100 From: Antony Bowesman User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: lemonade@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TWG-MailScanner: Found to be clean, Found to be clean X-TWG-MailScanner-Information: Please contact the ISP for more information X-TWG-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.697, required 5, autolearn=disabled, ALL_TRUSTED -2.82, AWL 0.12) X-MailScanner-From: adb@teamware.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Subject: [lemonade] delta times in FUTUREDELIVERY and time zones X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org A couple of commnets 1) The specification takes no account of time zone differences between client and server. As a result, with differing time zones, none of the use cases given in the introduction can be guaranteed and using future delivery as a personal reminder service is, at best, unreliable. RFC2852 gives some justification for its use of delta times against server side locale specific time to calculate the delivery by time although this justification seems weak. The future delivery abstract states a. "... client indication of future delivery time" b. "...an appointed time in the future" c. "...delivery at an appointed time " The client decides a based on its own TZ, the MSA decides b based on its TZ and c indicates a "DELIVERY AT" specification which conflicts with the effective "DELAY FOR" definition. While everything is OK if both client and MSA are in the same TZ, it all gets messy if not. MSAs are particularly useful for mobile submission to corporate mail systems and by its very nature, this use case introduces more chance of TZ mismatch. Although there are implications for a client implementation, would it be better to require the delta time be relative to current UTC for both client and server. That would allow the server to honour the request as given by the client rather than introducing a potentially random mismatch between the two. An MSA can be injecting messages to any number of servers in different time zones. An alternative would be to make this a "DELIVERY AT" extension and use date-time specification for delivery time with MAIL FROM... AT date-time. Otherwise, there should be a discussion of TZ factors and how mismatches can occur. 2. Section 4.2.1 1) When an MSA generates a DSN... Should be "If...". There's no guarantee the MSA is making final delivery. Same for 2) Regards Antony _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon May 16 10:46:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXgrr-0006yh-4i; Mon, 16 May 2005 10:46:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXgro-0006yU-LV for lemonade@megatron.ietf.org; Mon, 16 May 2005 10:46:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21378 for ; Mon, 16 May 2005 10:46:46 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXh8M-00060f-IS for lemonade@ietf.org; Mon, 16 May 2005 11:03:55 -0400 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j4GEkaom020661; Mon, 16 May 2005 09:46:37 -0500 (CDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 16 May 2005 09:46:11 -0500 Message-ID: <54E40201497DF142B06B27255953F79714F7968E@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Antony Bowesman , lemonade@ietf.org Subject: RE: [lemonade] delta times in FUTUREDELIVERY and time zones Date: Mon, 16 May 2005 09:46:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org The delta time was choosen exactly to address the time-zone issues. There is no machinery for indicating timezones between senders, receivers, and potential recipients. Delta time works because ten minutes from now is ten minutes from now everywhere. The client indicates it wants a message released to the network in ten minutes, the server releases it to the network in ten minutes. Now, if you want the message sent at 10:00AN local time, and it is 8:00AM local time now, the client should compute that the message should be sent in two hours... So, if it is 11AM local time where the server is, the server will release the message at 1:00 PM, the right thing happens. Any fancier "release at 10:00 in his timezone" calculations have to be done at the client with local knowledge of what timezone the recipient is in. This feature is not intended to solve that problem. There is no way for the submission MTA to know the timezone of an arbirary recipient. This extension does not place obligations on a final-delivery MTA which may have that knowledge to implement the feature. (Various denial-of-service attacks are possible if the future-delivery storage is outside the senders administative domain) Greg V. -----Original Message----- From: Antony Bowesman [mailto:adb@teamware.com] Sent: Monday, May 16, 2005 6:11 AM To: lemonade@ietf.org Subject: [lemonade] delta times in FUTUREDELIVERY and time zones A couple of commnets 1) The specification takes no account of time zone differences between client and server. As a result, with differing time zones, none of the use cases given in the introduction can be guaranteed and using future delivery as a personal reminder service is, at best, unreliable. RFC2852 gives some justification for its use of delta times against server side locale specific time to calculate the delivery by time although this justification seems weak. The future delivery abstract states a. "... client indication of future delivery time" b. "...an appointed time in the future" c. "...delivery at an appointed time " The client decides a based on its own TZ, the MSA decides b based on its TZ and c indicates a "DELIVERY AT" specification which conflicts with the effective "DELAY FOR" definition. While everything is OK if both client and MSA are in the same TZ, it all gets messy if not. MSAs are particularly useful for mobile submission to corporate mail systems and by its very nature, this use case introduces more chance of TZ mismatch. Although there are implications for a client implementation, would it be better to require the delta time be relative to current UTC for both client and server. That would allow the server to honour the request as given by the client rather than introducing a potentially random mismatch between the two. An MSA can be injecting messages to any number of servers in different time zones. An alternative would be to make this a "DELIVERY AT" extension and use date-time specification for delivery time with MAIL FROM... AT date-time. Otherwise, there should be a discussion of TZ factors and how mismatches can occur. 2. Section 4.2.1 1) When an MSA generates a DSN... Should be "If...". There's no guarantee the MSA is making final delivery. Same for 2) Regards Antony _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon May 16 12:05:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXi5m-0005qA-RS; Mon, 16 May 2005 12:05:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXi5m-0005q5-BQ for lemonade@megatron.ietf.org; Mon, 16 May 2005 12:05:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00028 for ; Mon, 16 May 2005 12:05:15 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXiML-00086B-0g for lemonade@ietf.org; Mon, 16 May 2005 12:22:26 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j4GFsv5D027440 for ; Mon, 16 May 2005 11:54:57 -0400 (EDT) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Mon, 16 May 2005 11:50:24 -0400 Message-ID: From: Eric Burger To: lemonade@ietf.org Date: Mon, 16 May 2005 11:50:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [lemonade] FW: Protocol Action: 'Message Submission for Mail' to Draft Stand ard X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org The IESG has approved the following document: - 'Message Submission for Mail ' as a Draft Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Ted Hardie. Technical Summary This document describes a message submission service which is distinct from message relay; this allows each service to operate according to its own rules. It specifies what actions are to be taken by a submission server. When conformant to this document, message submission uses the protocol specified here, normally over port 587. Message relay is unaffected, and continues to use SMTP over port 25. Working Group Summary This update is the product of individual submitters. The implementation reports submitted indicate that this service has been widely implemented and should advance along the standards track. Protocol Quality This document was reviewed for the IESG by Ted Hardie _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu May 26 15:46:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbOJX-0001Rs-F0; Thu, 26 May 2005 15:46:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbOJS-0001QH-CM; Thu, 26 May 2005 15:46:38 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27106; Thu, 26 May 2005 15:46:36 -0400 (EDT) Message-Id: <200505261946.PAA27106@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 26 May 2005 15:46:36 -0400 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-mms-mapping-04.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail Author(s) : R. Gellens Filename : draft-ietf-lemonade-mms-mapping-04.txt Pages : 32 Date : 2005-5-26 The cellular telephone industry has defined a service known as the Multimedia Messaging Service (MMS). This service uses formats and protocols which are similar to, but differ in key ways from, those used in Internet mail. This document specifies how to exchange messages between these two services, including mapping information elements as used in MMS X-Mms-* headers as well as delivery and disposition reports, to and from that used in ESMTP and Internet message headers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-mms-mapping-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-mms-mapping-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-mms-mapping-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-26161701.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-mms-mapping-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-mms-mapping-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-26161701.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Wed Jun 01 14:38:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdY6o-00005u-EE; Wed, 01 Jun 2005 14:38:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbijc-0003qO-1t; Fri, 27 May 2005 13:35:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01293; Fri, 27 May 2005 13:34:57 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbj2S-0000qh-BN; Fri, 27 May 2005 13:54:28 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DbijU-0003gq-Pv; Fri, 27 May 2005 13:34:52 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Fri, 27 May 2005 13:34:52 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-Mailman-Approved-At: Wed, 01 Jun 2005 14:38:29 -0400 Cc: lemonade mailing list , lemonade chair , Internet Architecture Board , lemonade chair , RFC Editor Subject: [lemonade] Protocol Action: 'Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail' to Proposed Standard X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org The IESG has approved the following document: - 'Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail ' as a Proposed Standard This document is the product of the Enhancements to Internet email to support diverse service environments Working Group. The IESG contact persons are Ted Hardie and Scott Hollenbeck. Technical Summary The cellular telephone industry has defined a service known as the Multimedia Messaging Service (MMS). This service uses formats and protocols which are similar to, but differ in key ways from those used in Internet mail. This document specifies how to exchange messages between these two services, including mapping information elements as used in MMS X-Mms-* headers as well as delivery and disposition reports, to and from that used in ESMTP and Internet message headers. Working Group Summary The LEMONADE working group came to consensus on the publication of this document. No issues were raised during IETF Last Call. This work was coordinated with 3GPP and 3GPP2 by the author and working group chairs. Protocol Quality This work was reviewed for the IESG by Eric Burger and Glenn Parsons. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade