Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HCAIr7058078; Wed, 17 May 2006 05:10:18 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HCAIaQ058077; Wed, 17 May 2006 05:10:18 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from mail.pscs.co.uk (lmail.pscs.co.uk [194.143.169.101]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HCAF9e058052 for ; Wed, 17 May 2006 05:10:16 -0700 (MST) (envelope-from paul@pscs.co.uk) Received: from paul.pscs.co.uk ([192.168.66.101]) by mail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP; Wed, 17 May 2006 13:08:07 +0100 Message-Id: <6.1.0.6.2.20060517130348.086b1150@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Wed, 17 May 2006 13:08:01 +0100 To: "Tulsi Ram Mayala" , "Paul Smith" , From: Paul Smith Subject: RE: Transparency In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_446096656==.ALT" X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.3.9 - Registered to: PSCS X-Organisation: Paul Smith Computer Services Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=====================_446096656==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 20:43 16/05/2006, Tulsi Ram Mayala wrote: >The question is not about the difficulty/ease of implementation. It is >about defining exact inverse operation and RFC should define it correctly. > >Yes a sender sending a single dot is buggy. >But a receiver not removing a dot in case of a single dot should not be >called buggy. Why? It simply doesn't do what RFC 2821 says it should do - ie, it's not SMTP compliant if it doesn't remove a leading dot. >Maybe a better way to put it is it can throw an error ("Invalid data >input" or something else). It probably could if it wanted to, but silently not removing the dot is a bug AFAICS. I can't see any reason to consider a change to RFC 2821 here. It's pretty clear, not self-contradictory, and not a problem to implement. --=====================_446096656==.ALT Content-Type: text/html; charset="us-ascii" At 20:43 16/05/2006, Tulsi Ram Mayala wrote:
The question is not about the difficulty/ease of implementation. It is about defining exact inverse operation and RFC should define it correctly.
 
Yes a sender sending a single dot is buggy.

But a receiver not removing a dot in case of a single dot should not be called buggy.

Why? It simply doesn't do what RFC 2821 says it should do - ie, it's not SMTP compliant if it doesn't remove a leading dot.

Maybe a better way to put it is it can throw an error (“Invalid data input” or something else).

It probably could if it wanted to, but silently not removing the dot is a bug AFAICS.

I can't see any reason to consider a change to RFC 2821 here. It's pretty clear, not self-contradictory, and not a problem to implement.

--=====================_446096656==.ALT-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H3x475046476; Tue, 16 May 2006 20:59:04 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4H3x4Ld046475; Tue, 16 May 2006 20:59:04 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from mail3.panix.com (mail3.panix.com [166.84.1.74]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H3x3aM046459 for ; Tue, 16 May 2006 20:59:04 -0700 (MST) (envelope-from hal9001@panix.com) Received: from mailspool3.panix.com (mailspool3.panix.com [166.84.1.78]) by mail3.panix.com (Postfix) with ESMTP id 1AC4C13AAE6 for ; Tue, 16 May 2006 23:59:01 -0400 (EDT) Received: from [192.168.1.11] (ool-45749fe3.dyn.optonline.net [69.116.159.227]) by mailspool3.panix.com (Postfix) with ESMTP id C07F9C98161 for ; Tue, 16 May 2006 23:59:00 -0400 (EDT) Mime-Version: 1.0 X-Sender: Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X 6.2.3 (MacOS 10.3) Date: Tue, 16 May 2006 23:47:17 -0400 To: From: "Robert A. Rosenberg" Subject: RE: Transparency Content-Type: multipart/alternative; boundary="============_-1064284156==_ma============" Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --============_-1064284156==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 12:43 -0700 on 05/16/2006, Tulsi Ram Mayala wrote about Re: Transparency: >Yes a sender sending a single dot is buggy. But a receiver not >removing a dot in case of a single dot should not be called buggy. >Maybe a better way to put it is it can throw an error ("Invalid data >input" or something else). Unless we can see what "went out over the wire" (ie: Was sent to the Receiving SMTP Server) we can not state where the error lies. The RFC states that: 1) .CR+LF is the signal that the transmission of the body is over. 2) When .CR+LF occurs in the body of a message to prevent it from being acted upon by the receiving SMTP Server, it is to be converted to ..CR+LF (by appending a second period. 3) To avoid needing to special case ..CR+LF at the receiving end, ANY line that begins with a period in the body is to be prefixed with a 2nd period when sent. 4) The receipt of .CR+LF by the receiving SMTP Server is an end-of-body signal. 5) Any OTHER line that begins with a period is to have that period removed and the rest of the line accepted. What this means is that this is what gets sent: Input Sent . .. .. ... .one ..one ..two ...two So long as the string in the Sent column is received by a properly working SMTP Server then the original string from the input column will be recovered. Now lets look at a broken sender that only adds a period if the 2nd character is NOT a period. This would cause the following: Input Sent . .. .. .. (not ...) .one ..one ..two ..two (not ...two) Now we see that the situation is as follows assuming a "correctly functioning" receiver (which seems to be what is occurring): Input Sent Received . .. . .. .. . .one ..one .one ..two ..two .two --============_-1064284156==_ma============ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit RE: Transparency
At 12:43 -0700 on 05/16/2006, Tulsi Ram Mayala wrote about Re: Transparency:

Yes a sender sending a single dot is buggy. But a receiver not removing a dot in case of a single dot should not be called buggy. Maybe a better way to put it is it can throw an error (³Invalid data input² or something else).

Unless we can see what "went out over the wire" (ie: Was sent to the Receiving SMTP Server) we can not state where the error lies.

The RFC states that:

 1) .CR+LF is the signal that the transmission of the body is over.
 2) When .CR+LF occurs in the body of a message to prevent it from being acted upon by the receiving SMTP Server, it is to be converted to ..CR+LF (by appending a second period.
 3) To avoid needing to special case ..CR+LF at the receiving end, ANY line that begins with a period in the body is to be prefixed with a 2nd period when sent.
 4) The receipt of .CR+LF by the receiving SMTP Server is an end-of-body signal.
 5) Any OTHER line that begins with a period is to have that period removed and the rest of the line accepted.

What this means is that this is what gets sent:

   Input          Sent
   .              ..
   ..             ...
   .one           ..one
   ..two          ...two


So long as the string in the Sent column is received by a properly working SMTP Server then the original string from the input column will be recovered.

Now lets look at a broken sender that only adds a period if the 2nd character is NOT a period. This would cause the following:

   Input          Sent
   .              ..
   ..             ..     (not ...)
   .one           ..one
   ..two          ..two  (not ...two)

Now we see that the situation is as follows assuming a "correctly functioning" receiver (which seems to be what is occurring):

   Input          Sent       Received
   .              ..         .
   ..             ..         .
   .one           ..one      .one
   ..two          ..two      .two
--============_-1064284156==_ma============-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H0NAqu099566; Tue, 16 May 2006 17:23:10 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4H0NASL099565; Tue, 16 May 2006 17:23:10 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from mail1.strongmailsystems.com (mail1.strongmailsystems.com [216.31.248.231]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4H0N9VL099545 for ; Tue, 16 May 2006 17:23:10 -0700 (MST) (envelope-from tulsi_rammayala@strongmail.com) DomainKey-Signature: a=rsa-sha1; c=nofws; s=mail1; d=strongmail.com; q=dns; b=aT7pFZWynnpdiCh/pFgASgNoZkvGQNVPGTCwmKiE5evCbwmdLKRGrs5x90wwQ8UD0jpzmCMsOJ2XloIp05DOEvd5OINTa9IKybq792E/kZO5FFD7n5iuoFcn/8isF2ER X-Mailer: StrongMail Enterprise 3.0.2(2.00.75) X-MailingID: 00000::00000::00000::00000::::478 X-Destination-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Transparency Date: Tue, 16 May 2006 17:20:59 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Transparency Thread-Index: AcZ5Rk0cP+jvDz24SfWyTHxZ6Ah/FgAAMFQA From: "Tulsi Ram Mayala" To: Cc: X-VirtualServerGroup: UNDEF Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4H0NAVL099560 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Oops. Major confusion :). Thanks for clarifying. -----Original Message----- From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Tuesday, May 16, 2006 5:12 PM To: Tulsi Ram Mayala Cc: ietf-smtp@imc.org Subject: Re: Transparency On Tue, 16 May 2006 16:32:31 PDT, Tulsi Ram Mayala said: > I apologize if you found my reply as offending. > I appreciate you response. I think he was merely referring to the fact that your replies didn't conform to the usual "prefix the quoted text with a > or similar", so it was difficult to tell which parts were the original message and which were your added text. > From: owner-ietf-smtp@mail.imc.orga [mailto:owner-ietf-smtp@mail.imc.org] > On Behalf Of Alex van den Bogaerdt > It seems you are quoting me but do so in quite an unusual manner. > Now I have to correct this... Like here - your reply didn't >-quote this, so now it looks like this text is yours, not Alex's. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GNYaIU089794; Tue, 16 May 2006 16:34:37 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4GNYafo089793; Tue, 16 May 2006 16:34:36 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from mail1.strongmailsystems.com (mail1.strongmailsystems.com [216.31.248.231]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4GNYZIT089768 for ; Tue, 16 May 2006 16:34:35 -0700 (MST) (envelope-from tulsi_rammayala@strongmail.com) DomainKey-Signature: a=rsa-sha1; c=nofws; s=mail1; d=strongmail.com; q=dns; b=gqbtWgdCXqM7tVV0mU390ujkiiZSkzz0cmxwi3sXHyeCOYk0r8T6+Ug4K9awbdTudr2nAMiOOEC2jTozbn/qYGSdZWdFxQHfmMPrgJAmcKQ+YKCK6nXYSNGWaapylExF X-Mailer: StrongMail Enterprise 3.0.2(2.00.75) X-MailingID: 00000::00000::00000::00000::::378 X-Destination-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Transparency Date: Tue, 16 May 2006 16:32:31 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Transparency Thread-Index: AcZ5LFLCn4kgs62TTBW9paLVCgiIJQAFHM1A From: "Tulsi Ram Mayala" To: X-VirtualServerGroup: UNDEF Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4GNYaIT089788 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I apologize if you found my reply as offending. I appreciate you response. Thanks, Tulsi Ram. -----Original Message----- From: owner-ietf-smtp@mail.imc.org [mailto:owner-ietf-smtp@mail.imc.org] On Behalf Of Alex van den Bogaerdt Sent: Tuesday, May 16, 2006 1:40 PM To: ietf-smtp@imc.org Subject: Re: Transparency It seems you are quoting me but do so in quite an unusual manner. Now I have to correct this... >> Why would one look for an invalid case that shouldn't be there in >> the first place? That would be an unnecessary operation. >> >> if the 1st character is '.' and the 2nd character is not end of line, >> remove the first character. >> >> vs. >> >> if the 1st character is '.' and the 2nd character is '.' and the 3rd >> character is not end of line, remove the first character. > > This might be needed to throw an error. There is no error. If the line starts with a dot and is not only a dot, remove the dot. This is as the manual specifies. > > > NOTE the input set precondition in the derived inverse function. If > > > f'(y) is not defined for y=1 then how can it be expected to give a > > > result for y=1. > > The input *is* defined. < > one character>> is to be modified. > > It is not correct inverse operation and the suggestion is to > correct it. Then correct it at the sender's side. Just because a handful of sender MTAs does this wrong, you want the whole world to handle a special case? > > The output is not defined. The sending MTA should have done something > > different, not the receiving one. > > Yes, I agree and that is why I would not call receiving MTA as > buggy in this case. Neither did I. On the contrary. Ergo, the receiving end does not need to change. This means ".a line starting with a dot" should not be handled different than "..a line starting with a dot". In both cases remove one leading dot. There is no need to look for the single dot as a special case. That would just be more work for the receiver and would not be necessary in way too many cases. It would be an error if the receiving end threw an error. The problem is in the sending MTA. Fix it there. Guessing at the receiver's side will, in most cases, probably work fine but in the long run this would just mean that those faulty senders won't be repaired. Enough reasons why the receiver does not need to, and should not, change. Alex Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GM0xnn070177; Tue, 16 May 2006 15:00:59 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4GM0xO3070176; Tue, 16 May 2006 15:00:59 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GM0ugv070151 for ; Tue, 16 May 2006 15:00:59 -0700 (MST) (envelope-from john+smtp@jck.com) Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Fg7ay-000Pyw-2t; Tue, 16 May 2006 18:00:48 -0400 Date: Tue, 16 May 2006 18:00:47 -0400 From: John C Klensin To: Tulsi Ram Mayala , Paul Smith , ietf-smtp@imc.org Subject: RE: Transparency Message-ID: <24D5307528242E1A00422FBC@p3.JCK.COM> In-Reply-To: References: X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, For whatever my perspective is worth, please calm down. First and foremost, if the robustness principle is applied, all cases are covered. The sender, being conservative about what is sent, never sends lines with one leading dot and any other text. The receiver, being liberal about what is accepted, (i) allows for the possibility of white space between a leading dot and CRLF, treating either .CRLF or .CRLF as end-of-data, and (ii) removes a leading dot regardless of what follows it. The second rule creates some slight possibility of removing a dot that should have been there, but such a singular dot is an error anyway, so no one is in much condition to complain. The text in 2821, and the distinction between sending and receiving behavior, is intentional and basically reflects the principles above. With regard to "throwing errors", who are you going to tell? Certainly one could add a header that says, more or less "the input was a little bogus and we tried to fix it up", although I'd assume most MUAs and users would ignore such a message. A trace field could be annotated (with a comment) in much the same way (and that is what I'd do personally if I felt obligated to report something like this). 2821 basically prohibits (again, intentionally) returning a error reply but still delivering the message; rejecting or bouncing a message over something like this would impress me as strange indeed. While you are welcome to continue if you like, I think that ought to be more or less the end of this discussion unless it can be demonstrated that following the robustness principle and/or the text of 2821 causes harm. Yours for robust and interoperable SMTP implementations, john --On Tuesday, 16 May, 2006 12:43 -0700 Tulsi Ram Mayala wrote: > The question is not about the difficulty/ease of > implementation. It is about defining exact inverse operation > and RFC should define it correctly. > > > > Yes a sender sending a single dot is buggy. But a receiver not > removing a dot in case of a single dot should not be called > buggy. Maybe a better way to put it is it can throw an error > ("Invalid data input" or something else). > > > > ________________________________ > > From: Paul Smith [mailto:paul@pscs.co.uk] > Sent: Tuesday, May 16, 2006 1:13 AM > To: Tulsi Ram Mayala; ietf-smtp@imc.org > Subject: Re: Transparency > > > > At 01:55 16/05/2006, Tulsi Ram Mayala wrote: > > > > However there are conflicting statements in RFC regarding > single dot. Here are the RFC statements: > > 1. Before sending a line of mail text the sender-SMTP checks > the first character of the line. If it is a period, one > additional period is inserted at the beginning of the line. > >>> This implies a reciever should never recieve a line with >>> single dot > followed by characters (other than CRLF). > > 2. When a line of mail text is received by the receiver-SMTP > it checks the line. If the line is composed of a single > period it is the end of mail. If the first character is a > period and there are other characters on the line, the first > character is deleted. > >>> This says remove dot even in case of single dot followed by >>> charactes > other than CRLF. IT SHOULD HAVE BEEN IF MORE THAN ONE DOTS. > > In my opinion single dot case is not a valid test case. > > > There are two statements there, one applies to the sender, and > one applies to the receiver. > > In your example, you have a bug in the sender (not your > software) AND a bug in the receiver (your software). > > You CAN fix the bug in your software - ie do what (2) above > says - if the first character is a period, and it's not on a > line of its own, delete the first character. Statement (2) > above isn't ambiguous. > > You can't fix the bug in the sending software (unless your > software does that as well...) so don't worry about that. If > the developers of the sending software complain that your > software shouldn't remove the leading '.' unless there's two > of them, you have plenty of ammunition to defeat their > arguments! > > I can't see it being hard to fix the bug in the receiving > software... > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GKdxcJ055309; Tue, 16 May 2006 13:39:59 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4GKdxXP055308; Tue, 16 May 2006 13:39:59 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from mx2.elm.net (mx2.elm.net [80.69.83.193]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GKdxIi055300 for ; Tue, 16 May 2006 13:39:59 -0700 (MST) (envelope-from alex@ergens.op.het.net) Received: from mx2.corp.elm.net (mx2.corp.elm.net [10.7.12.192]) by mx2.elm.net (Postfix) with ESMTP id 0B58E7C46 for ; Tue, 16 May 2006 22:39:58 +0200 (CEST) Received: from mx2.elm.net ([127.0.0.1]) by mx2.corp.elm.net (amavisd) with ESMTP id 24848-05 for ; Tue, 16 May 2006 22:39:55 +0200 (CEST) Received: from shell.elm.net (shell.corp.elm.net [10.7.12.194]) by mx2.elm.net (Postfix) with SMTP id AC42C7BFD for ; Tue, 16 May 2006 22:39:55 +0200 (CEST) Received: (nullmailer pid 24897 invoked by uid 504); Tue, 16 May 2006 20:39:55 -0000 Date: Tue, 16 May 2006 22:39:55 +0200 From: Alex van den Bogaerdt To: ietf-smtp@imc.org Subject: Re: Transparency Message-ID: <20060516203955.GK12336@ergens.op.het.net> Reply-To: ietf-smtp@imc.org Mail-Followup-To: ietf-smtp@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Scanned: amavisd-new at elm.net Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It seems you are quoting me but do so in quite an unusual manner. Now I have to correct this... >> Why would one look for an invalid case that shouldn't be there in >> the first place? That would be an unnecessary operation. >> >> if the 1st character is '.' and the 2nd character is not end of line, >> remove the first character. >> >> vs. >> >> if the 1st character is '.' and the 2nd character is '.' and the 3rd >> character is not end of line, remove the first character. > > This might be needed to throw an error. There is no error. If the line starts with a dot and is not only a dot, remove the dot. This is as the manual specifies. > > > NOTE the input set precondition in the derived inverse function. If > > > f'(y) is not defined for y=1 then how can it be expected to give a > > > result for y=1. > > The input *is* defined. < > one character>> is to be modified. > > It is not correct inverse operation and the suggestion is to > correct it. Then correct it at the sender's side. Just because a handful of sender MTAs does this wrong, you want the whole world to handle a special case? > > The output is not defined. The sending MTA should have done something > > different, not the receiving one. > > Yes, I agree and that is why I would not call receiving MTA as > buggy in this case. Neither did I. On the contrary. Ergo, the receiving end does not need to change. This means ".a line starting with a dot" should not be handled different than "..a line starting with a dot". In both cases remove one leading dot. There is no need to look for the single dot as a special case. That would just be more work for the receiver and would not be necessary in way too many cases. It would be an error if the receiving end threw an error. The problem is in the sending MTA. Fix it there. Guessing at the receiver's side will, in most cases, probably work fine but in the long run this would just mean that those faulty senders won't be repaired. Enough reasons why the receiver does not need to, and should not, change. Alex Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GJnYu2044666; Tue, 16 May 2006 12:49:34 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4GJnY2A044665; Tue, 16 May 2006 12:49:34 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from mail1.strongmailsystems.com (mail1.strongmailsystems.com [216.31.248.231]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4GJnXWN044640 for ; Tue, 16 May 2006 12:49:34 -0700 (MST) (envelope-from tulsi_rammayala@strongmail.com) DomainKey-Signature: a=rsa-sha1; c=nofws; s=mail1; d=strongmail.com; q=dns; b=quHQl1mY9e/DW1qWfkOm7zYFUjzFLVAJNxk0Q/1TkeDZtSwl8r7AcHWA+WezTFlh5q24lezubC4IkuAxfzk31twoL7Af3mMsk5nmkUHGNnxU25p9j4HfCf+Aj0b1/Jy4 X-Mailer: StrongMail Enterprise 3.0.2(2.00.75) X-MailingID: 00000::00000::00000::00000::::218 X-Destination-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Transparency Date: Tue, 16 May 2006 12:47:32 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Transparency Thread-Index: AcZ4vVOpiy2CeNt1RBqjwjosZUQlFAAY9yPw From: "Tulsi Ram Mayala" To: X-VirtualServerGroup: UNDEF Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4GJnYWN044659 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Why would one look for an invalid case that shouldn't be there in the first place? That would be an unnecessary operation. if the 1st character is '.' and the 2nd character is not end of line, remove the first character. vs. if the 1st character is '.' and the 2nd character is '.' and the 3rd character is not end of line, remove the first character. [TR] This might be needed to throw an error. > NOTE the input set precondition in the derived inverse function. If > f'(y) is not defined for y=1 then how can it be expected to give a > result for y=1. The input *is* defined. <> is to be modified. [TR] It is not correct inverse operation and the suggestion is to correct it. The output is not defined. The sending MTA should have done something different, not the receiving one. [TR] Yes, I agree and that is why I would not call receiving MTA as buggy in this case. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GJk25E043969; Tue, 16 May 2006 12:46:02 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4GJk2Q1043966; Tue, 16 May 2006 12:46:02 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from mail1.strongmailsystems.com (mail1.strongmailsystems.com [216.31.248.231]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4GJk13v043940 for ; Tue, 16 May 2006 12:46:01 -0700 (MST) (envelope-from tulsi_rammayala@strongmail.com) DomainKey-Signature: a=rsa-sha1; c=nofws; s=mail1; d=strongmail.com; q=dns; b=FwNEY3ChLNiZ+GhH+x825sduhUpPvC4vhvyzjOfdn3M97IQL3w2j72fb6feyuTDRDheh93rsp9UNCCRXSGCATbP4IBFnXrgI81X/hv5Xu8nAWyVQVbJAOJlytukyZFPa X-Mailer: StrongMail Enterprise 3.0.2(2.00.75) X-MailingID: 00000::00000::00000::00000::::212 X-Destination-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67921.128F628A" Subject: RE: Transparency Date: Tue, 16 May 2006 12:43:59 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Transparency Thread-Index: AcZ4wU7Obar1uxfFQXOGKHF8/rtf8AAXwLYA From: "Tulsi Ram Mayala" To: "Paul Smith" , X-VirtualServerGroup: UNDEF Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C67921.128F628A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The question is not about the difficulty/ease of implementation. It is about defining exact inverse operation and RFC should define it correctly. =20 Yes a sender sending a single dot is buggy. But a receiver not removing a dot in case of a single dot should not be called buggy. Maybe a better way to put it is it can throw an error ("Invalid data input" or something else). =20 ________________________________ From: Paul Smith [mailto:paul@pscs.co.uk]=20 Sent: Tuesday, May 16, 2006 1:13 AM To: Tulsi Ram Mayala; ietf-smtp@imc.org Subject: Re: Transparency =20 At 01:55 16/05/2006, Tulsi Ram Mayala wrote: However there are conflicting statements in RFC regarding single dot. Here are the RFC statements: 1. Before sending a line of mail text the sender-SMTP checks the first character of the line. If it is a period, one additional period is inserted at the beginning of the line. >> This implies a reciever should never recieve a line with single dot followed by characters (other than CRLF). 2. When a line of mail text is received by the receiver-SMTP it checks the line. If the line is composed of a single period it is the end of mail. If the first character is a period and there are other characters on the line, the first character is deleted. >> This says remove dot even in case of single dot followed by charactes other than CRLF. IT SHOULD HAVE BEEN IF MORE THAN ONE DOTS. In my opinion single dot case is not a valid test case. There are two statements there, one applies to the sender, and one applies to the receiver. In your example, you have a bug in the sender (not your software) AND a bug in the receiver (your software).=20 You CAN fix the bug in your software - ie do what (2) above says - if the first character is a period, and it's not on a line of its own, delete the first character. Statement (2) above isn't ambiguous. You can't fix the bug in the sending software (unless your software does that as well...) so don't worry about that. If the developers of the sending software complain that your software shouldn't remove the leading '.' unless there's two of them, you have plenty of ammunition to defeat their arguments! I can't see it being hard to fix the bug in the receiving software... ------_=_NextPart_001_01C67921.128F628A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The question is not about the = difficulty/ease of implementation. It is about defining exact inverse operation and RFC = should define it correctly.

 

Yes a sender sending a single dot = is buggy. But a receiver not removing a dot in case of a single dot should = not be called buggy. Maybe a better way to put it is it can throw an error = (“Invalid data input” or something else).

 

From: Paul = Smith [mailto:paul@pscs.co.uk]
Sent: Tuesday, May 16, = 2006 1:13 AM
To: Tulsi Ram Mayala; ietf-smtp@imc.org
Subject: Re: = Transparency

 

At 01:55 16/05/2006, Tulsi Ram Mayala wrote:

However there are conflicting statements in RFC regarding single = dot. Here are the RFC statements:

1. Before sending a line of mail text the sender-SMTP checks the first character of the line.  If it is a period, one additional period is inserted at the beginning of the line.

>> This implies a reciever should never recieve a line with single = dot followed by characters (other than CRLF).

2. When a line of mail text is received by the receiver-SMTP it checks = the line.  If the line is composed of a single period it is the end of mail.  If the first character is a period and there are other = characters on the line, the first character is deleted.

>> This says remove dot even in case of single dot followed by = charactes other than CRLF. IT SHOULD HAVE BEEN IF MORE THAN ONE DOTS.

In my opinion single dot case is not a valid test = case.


There are two statements there, one applies to the sender, and one = applies to the receiver.

In your example, you have a bug in the sender (not your software) AND a = bug in the receiver (your software).

You CAN fix the bug in your software - ie do what (2) above says - if = the first character is a period, and it's not on a line of its own, delete the = first character. Statement (2) above isn't ambiguous.

You can't fix the bug in the sending software (unless your software does = that as well...) so don't worry about that. If the developers of the sending software complain that your software shouldn't remove the leading '.' = unless there's two of them, you have plenty of ammunition to defeat their = arguments!

I can't see it being hard to fix the bug in the receiving = software...

------_=_NextPart_001_01C67921.128F628A-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4G8KEWu087438; Tue, 16 May 2006 01:20:14 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4G8KEBe087437; Tue, 16 May 2006 01:20:14 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from mail.pscs.co.uk (lmail.pscs.co.uk [194.143.169.101]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4G8KBoU087421 for ; Tue, 16 May 2006 01:20:12 -0700 (MST) (envelope-from paul@pscs.co.uk) Received: from paul.pscs.co.uk ([192.168.66.101]) by mail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP; Tue, 16 May 2006 09:13:15 +0100 Message-Id: <6.1.0.6.2.20060516090952.076bfeb0@lmail.pscs.co.uk> X-Sender: paul@lmail.pscs.co.uk X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Tue, 16 May 2006 09:13:15 +0100 To: "Tulsi Ram Mayala" , From: Paul Smith Subject: Re: Transparency In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_345606484==.ALT" X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V2.3.9 - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=====================_345606484==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 01:55 16/05/2006, Tulsi Ram Mayala wrote: >However there are conflicting statements in RFC regarding single dot. Here >are the RFC statements: > >1. Before sending a line of mail text the sender-SMTP checks the first >character of the line. If it is a period, one additional period is >inserted at the beginning of the line. > > >> This implies a reciever should never recieve a line with single dot > followed by characters (other than CRLF). > >2. When a line of mail text is received by the receiver-SMTP it checks the >line. If the line is composed of a single period it is the end of >mail. If the first character is a period and there are other characters >on the line, the first character is deleted. > > >> This says remove dot even in case of single dot followed by charactes > other than CRLF. IT SHOULD HAVE BEEN IF MORE THAN ONE DOTS. > >In my opinion single dot case is not a valid test case. There are two statements there, one applies to the sender, and one applies to the receiver. In your example, you have a bug in the sender (not your software) AND a bug in the receiver (your software). You CAN fix the bug in your software - ie do what (2) above says - if the first character is a period, and it's not on a line of its own, delete the first character. Statement (2) above isn't ambiguous. You can't fix the bug in the sending software (unless your software does that as well...) so don't worry about that. If the developers of the sending software complain that your software shouldn't remove the leading '.' unless there's two of them, you have plenty of ammunition to defeat their arguments! I can't see it being hard to fix the bug in the receiving software... --=====================_345606484==.ALT Content-Type: text/html; charset="us-ascii" At 01:55 16/05/2006, Tulsi Ram Mayala wrote:
However there are conflicting statements in RFC regarding single dot. Here are the RFC statements:

1. Before sending a line of mail text the sender-SMTP checks the first character of the line.  If it is a period, one additional period is inserted at the beginning of the line.

>> This implies a reciever should never recieve a line with single dot followed by characters (other than CRLF).

2. When a line of mail text is received by the receiver-SMTP it checks the line.  If the line is composed of a single period it is the end of mail.  If the first character is a period and there are other characters on the line, the first character is deleted.

>> This says remove dot even in case of single dot followed by charactes other than CRLF. IT SHOULD HAVE BEEN IF MORE THAN ONE DOTS.

In my opinion single dot case is not a valid test case.

There are two statements there, one applies to the sender, and one applies to the receiver.

In your example, you have a bug in the sender (not your software) AND a bug in the receiver (your software).

You CAN fix the bug in your software - ie do what (2) above says - if the first character is a period, and it's not on a line of its own, delete the first character. Statement (2) above isn't ambiguous.

You can't fix the bug in the sending software (unless your software does that as well...) so don't worry about that. If the developers of the sending software complain that your software shouldn't remove the leading '.' unless there's two of them, you have plenty of ammunition to defeat their arguments!

I can't see it being hard to fix the bug in the receiving software...

 --=====================_345606484==.ALT-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4G7K9tA073650; Tue, 16 May 2006 00:20:09 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4G7K9WL073649; Tue, 16 May 2006 00:20:09 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from mx2.elm.net (mx2.elm.net [80.69.83.193]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4G7K8U8073629 for ; Tue, 16 May 2006 00:20:08 -0700 (MST) (envelope-from alex@ergens.op.het.net) Received: from mx2.corp.elm.net (mx2.corp.elm.net [10.7.12.192]) by mx2.elm.net (Postfix) with ESMTP id 84C2A7C46 for ; Tue, 16 May 2006 09:20:05 +0200 (CEST) Received: from mx2.elm.net ([127.0.0.1]) by mx2.corp.elm.net (amavisd) with ESMTP id 23198-07 for ; Tue, 16 May 2006 09:20:02 +0200 (CEST) Received: from shell.elm.net (shell.corp.elm.net [10.7.12.194]) by mx2.elm.net (Postfix) with SMTP id B1B2E7BFD for ; Tue, 16 May 2006 09:20:02 +0200 (CEST) Received: (nullmailer pid 23271 invoked by uid 504); Tue, 16 May 2006 07:20:02 -0000 Date: Tue, 16 May 2006 09:19:57 +0200 From: Alex van den Bogaerdt To: ietf-smtp@imc.org Subject: Re: Transparency Message-ID: <20060516071957.GA1940@ergens.op.het.net> Reply-To: ietf-smtp@imc.org Mail-Followup-To: ietf-smtp@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Scanned: amavisd-new at elm.net Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, May 15, 2006 at 09:43:00PM -0700, Tulsi Ram Mayala wrote: > > Why should an MTA remove a dot in case of technically invalid '.one'? > What would be its significance? RFC should not mandate any unnecessary > operation. Why would one look for an invalid case that shouldn't be there in the first place? That would be an unnecessary operation. if the 1st character is '.' and the 2nd character is not end of line, remove the first character. vs. if the 1st character is '.' and the 2nd character is '.' and the 3rd character is not end of line, remove the first character. > NOTE the input set precondition in the derived inverse function. If > f'(y) is not defined for y=1 then how can it be expected to give a > result for y=1. The input *is* defined. <> is to be modified. The output is not defined. The sending MTA should have done something different, not the receiving one. alex Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4G5XsBk048641; Mon, 15 May 2006 22:33:54 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4G5XsJ0048640; Mon, 15 May 2006 22:33:54 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from winserver.com (winserver.com [208.247.131.9]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4G5XrbO048621 for ; Mon, 15 May 2006 22:33:53 -0700 (MST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.1.451.7) for ietf-smtp@imc.org; Tue, 16 May 2006 01:34:55 -0400 Received: from hdev1 ([72.153.86.223]) by winserver.com (Wildcat! SMTP v6.1.451.7) with ESMTP id 411150094; Tue, 16 May 2006 01:34:54 -0400 Message-ID: <02b401c678aa$0b63c860$0201a8c0@hdev1> From: "Hector Santos" To: References: Subject: Re: Transparency Date: Tue, 16 May 2006 01:31:52 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: That's the problem - SMTP is not math. :-) Sender: while (not end of file) s = GetNextLine() if (s == ".") then s = ".." send s+CRLF wend send "."+CRLF Receiver: while (not end of socket) s = GetNextLineFromSocket() if (s == ".") then break if (s == "..") then s = "." savetofile s+CRLF wend --- HLS ----- Original Message ----- From: "Tulsi Ram Mayala" To: Cc: Sent: Tuesday, May 16, 2006 12:43 AM Subject: RE: Transparency > > Why should an MTA remove a dot in case of technically invalid '.one'? > What would be its significance? RFC should not mandate any unnecessary > operation. > > It is like a mathematical function and its inverse function: > f(x) = x+1, where x>=1 > f'(y) = y-1, where y>1 > > NOTE the input set precondition in the derived inverse function. If > f'(y) is not defined for y=1 then how can it be expected to give a > result for y=1. > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4G4jKoF038039; Mon, 15 May 2006 21:45:20 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4G4jK0H038038; Mon, 15 May 2006 21:45:20 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from mail1.strongmailsystems.com (mail1.strongmailsystems.com [216.31.248.231]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4G4jIGo038006 for ; Mon, 15 May 2006 21:45:19 -0700 (MST) (envelope-from tulsi_rammayala@strongmail.com) DomainKey-Signature: a=rsa-sha1; c=nofws; s=mail1; d=strongmail.com; q=dns; b=HVWCrEt+XeYhlrGnkbhZPr/mKDknEWgSfEjyno2knxxaR+XhbYzEbDAPgcmBRknQgOZMj6CHp81emu58GQnAbLra4+cmTEw8uxQky8nZFGYXc18uayBb+RkLN/dZjGgy X-Mailer: StrongMail Enterprise 3.0.2(2.00.75) X-MailingID: 00000::00000::00000::00000::::6 X-Destination-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Transparency Date: Mon, 15 May 2006 21:43:00 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Transparency Thread-Index: AcZ4kOjHr/+1qMSBQC294EiBpkiY3QAESEAA From: "Tulsi Ram Mayala" To: Cc: X-VirtualServerGroup: UNDEF Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4G4jJGo038028 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Why should an MTA remove a dot in case of technically invalid '.one'? What would be its significance? RFC should not mandate any unnecessary operation. It is like a mathematical function and its inverse function: f(x) = x+1, where x>=1 f'(y) = y-1, where y>1 NOTE the input set precondition in the derived inverse function. If f'(y) is not defined for y=1 then how can it be expected to give a result for y=1. -----Original Message----- From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Monday, May 15, 2006 7:34 PM To: Tulsi Ram Mayala Cc: ietf-smtp@imc.org Subject: Re: Transparency On Mon, 15 May 2006 17:55:06 PDT, Tulsi Ram Mayala said: > Here is the case that demonstrates the dot destuffing functionality in strongmail MTA: What does this demonstrate other than a buggy MTA? telnet ::1 25 Trying ::1... Connected to ::1. Escape character is '^]'. 220 turing-police.cc.vt.edu ESMTP Sendmail 8.13.7.PreAlpha0/8.13.7.PreAlpha0; Mon, 15 May 2006 22:14:08 -0400 ehlo localhost 250-turing-police.cc.vt.edu Hello turing-police.cc.vt.edu [IPv6:::1] (may be forged), pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH DIGEST-MD5 CRAM-MD5 250-STARTTLS 250-DELIVERBY 250 HELP mail from:<> 250 2.1.0 <>... Sender ok rcpt to: 250 2.1.5 ... Recipient ok data 354 Enter mail, end with "." on a line by itself Subject: test From: valdis To: valdis Date: Mon, 15 May 2006 17:55:06 -0700 .one ..two ...three ....four . 250 2.0.0 k4G2E8vt011665 Message accepted for delivery quit 221 2.0.0 turing-police.cc.vt.edu closing connection And that gets us: > Received: from localhost (turing-police.cc.vt.edu [IPv6:::1] (may be forged)) by turing-police.cc.vt.edu (8.13.7.PreAlpha0/8.13.7.PreAlpha0) with ESMTP id k4G2E8vt011665 for ; Mon, 15 May 2006 22:14:24 -0400 Message-Id: <200605160214.k4G2E8vt011665@turing-police.cc.vt.edu> Subject: test From: valdis@turing-police.cc.vt.edu To: valdis@turing-police.cc.vt.edu Date: Mon, 15 May 2006 17:55:06 -0700 one .two ..three ...four This Does The Right Thing (deletes a single dot) even when we send a technically invalid '.one' (which should have been '..one'). Your test case does it *doubly* wrong - first, an invalid '.one' is sent, and the the leading '.' isn't removed. Remember, one of the rules (add a dot) applies to the *sending* (client) SMTP, and the other (remove a dot) applies to the *receiving* (server) SMTP. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4G10ooC086855; Mon, 15 May 2006 18:00:51 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4G10owK086854; Mon, 15 May 2006 18:00:50 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from mail1.strongmailsystems.com (mail1.strongmailsystems.com [216.31.248.231]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4G10n6U086837 for ; Mon, 15 May 2006 18:00:50 -0700 (MST) (envelope-from tulsi_rammayala@strongmail.com) DomainKey-Signature: a=rsa-sha1; c=nofws; s=mail1; d=strongmail.com; q=dns; b=F0GLRGuLPT196vNF4XhTLxcyL7N/ctOAV56fMX/cb2cBqd4sMpjP9qa/BFZrKG3VFz9y6zU3yO1zKB/qTXpTi791ezz2DWs8dRUi+ZmJgNc+UfRyq6/oqGuaZKpc16/5 X-Mailer: StrongMail Enterprise 3.0.2(2.00.75) X-MailingID: 00000::00000::00000::00000::::2151 X-Destination-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67883.E29B8B32" Subject: Transparency Date: Mon, 15 May 2006 17:55:06 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Transparency Thread-Index: AcZ4TJpQNc6CGGGYRouWMI9b8wG4yAAJys9wAAPmgEI= References: From: "Tulsi Ram Mayala" To: X-VirtualServerGroup: UNDEF Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C67883.E29B8B32 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I had a question and suggestion for RFC 2821: Here is the case that demonstrates the dot destuffing functionality in = strongmail MTA: [root@localhost strongmail-mta]# telnet 0 25 Trying 0.0.0.0... Connected to 0 (0.0.0.0). Escape character is '^]'. 220 localhost.localdomain StrongMail SMTP Service Version: = 3.1.5(2.00.222) ready at Mon, 15 May 2006 10:43:42 -0700 for server = 27509 helo sdfasd 250 Ok mail from: 250 Ok rcpt = to: 250 Ok data 354 send the mail data, end with . .one =20 ..two .one ...three ....four . 250 ok, Accepted quit 221 Service closing transmission channel Connection closed by foreign = host. [root@localhost strongmail-mta]# cat log/test.mail =20 >From Mon May 15 10:44:26 2006 .one << We do not remove = dot in case of single dot. =20 .two .one << We do not remove = dot in case of single dot. ..three ...four However there are conflicting statements in RFC regarding single dot. = Here are the RFC statements: 1. Before sending a line of mail text the sender-SMTP checks the first = character of the line. If it is a period, one additional period is = inserted at the beginning of the line. >> This implies a reciever should never recieve a line with single dot = followed by characters (other than CRLF). 2. When a line of mail text is received by the receiver-SMTP it checks = the line. If the line is composed of a single period it is the end of = mail. If the first character is a period and there are other characters = on the line, the first character is deleted. >> This says remove dot even in case of single dot followed by charactes = other than CRLF. IT SHOULD HAVE BEEN IF MORE THAN ONE DOTS. In my opinion single dot case is not a valid test case. RFC 2821 should be corrected accordingly. ------_=_NextPart_001_01C67883.E29B8B32 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Transparency

I had a question and suggestion for RFC 2821:

Here is the case that demonstrates the dot destuffing functionality in = strongmail MTA:

[root@localhost strongmail-mta]# telnet 0 25 Trying 0.0.0.0...
Connected to 0 (0.0.0.0).
Escape character is '^]'.
220 localhost.localdomain StrongMail SMTP Service Version: = 3.1.5(2.00.222) ready at Mon, 15 May 2006 10:43:42 -0700 for server = 27509 helo sdfasd 250 Ok mail from:<dsfsdafs@sadffas.com> 250 Ok = rcpt to:<dsfsd@dsafsd.com> 250 Ok data
354 send the mail data, end with .
.one

..two
.one
...three
....four
.
250 ok, Accepted
quit
221 Service closing transmission channel Connection closed by foreign = host.


[root@localhost strongmail-mta]# cat log/test.mail

>From <dsfsdafs@sadffas.com> Mon May 15 10:44:26 2006
.one           &nb= sp;           &nbs= p;            = ;           << = We do not remove dot in case of single dot.

.two
.one           &nb= sp;           &nbs= p;            = ;           << = We do not remove dot in case of single dot.
..three
...four


However there are conflicting statements in RFC regarding single dot. = Here are the RFC statements:

1. Before sending a line of mail text the sender-SMTP checks the first = character of the line.  If it is a period, one additional period is = inserted at the beginning of the line.

>> This implies a reciever should never recieve a line with single = dot followed by characters (other than CRLF).

2. When a line of mail text is received by the receiver-SMTP it checks = the line.  If the line is composed of a single period it is the end = of mail.  If the first character is a period and there are other = characters on the line, the first character is deleted.

>> This says remove dot even in case of single dot followed by = charactes other than CRLF. IT SHOULD HAVE BEEN IF MORE THAN ONE = DOTS.

In my opinion single dot case is not a valid test case.

RFC 2821 should be corrected accordingly.

------_=_NextPart_001_01C67883.E29B8B32-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k49ItG8U018954; Tue, 9 May 2006 11:55:16 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k49ItGHe018953; Tue, 9 May 2006 11:55:16 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k49ItFLP018946 for ; Tue, 9 May 2006 11:55:15 -0700 (MST) (envelope-from arnt@gulbrandsen.priv.no) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 4EC1F4AC28; Tue, 9 May 2006 20:55:14 +0200 (CEST) Message-Id: Date: Tue, 9 May 2006 20:58:49 +0200 From: Arnt Gulbrandsen To: ietf-smtp@imc.org Subject: Re: smtp trace id extension Cc: Tony Hansen References: <4+gzdQ6fZM88q0X7he4DPw.md5@libertango.oryx.com> <4460E343.5010605@att.com> In-Reply-To: <4460E343.5010605@att.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tony Hansen writes: > Look up message tracking, RFCs 3885-3888. Oh, I was looking at RFCs from the previous millenium. Some text in this series reminds me of the thing I'm thinking of, but it's much newer. Anyway, it suits my purposes. Thank you. Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k49IjSTT018542; Tue, 9 May 2006 11:45:28 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k49IjSiv018541; Tue, 9 May 2006 11:45:28 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.241.195]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k49IjRNL018535 for ; Tue, 9 May 2006 11:45:27 -0700 (MST) (envelope-from tony@att.com) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-4.tower-121.messagelabs.com!1147200325!9121103!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 30284 invoked from network); 9 May 2006 18:45:25 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-4.tower-121.messagelabs.com with SMTP; 9 May 2006 18:45:25 -0000 Received: from [135.91.110.64] (thansen-n.mt.att.com[135.91.110.64](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20060509184525gw1001002ue> (Authid: tony); Tue, 9 May 2006 18:45:25 +0000 Message-ID: <4460E343.5010605@att.com> Date: Tue, 09 May 2006 14:45:23 -0400 From: Tony Hansen User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Arnt Gulbrandsen CC: ietf-smtp@imc.org Subject: Re: smtp trace id extension References: <4+gzdQ6fZM88q0X7he4DPw.md5@libertango.oryx.com> In-Reply-To: <4+gzdQ6fZM88q0X7he4DPw.md5@libertango.oryx.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Look up message tracking, RFCs 3885-3888. Tony Hansen tony@att.com Arnt Gulbrandsen wrote: > > Hi, > > I have a vague recollection that there once was an SMTP extension to > trace the path a message took after the fact. I cannot find it. Is my > memory playing tricks with me, or was there really such an extension? > > (It doesn't matter whether the extension is odd, obscure and > unimplemented. I just need a fairly small part of it anyway. I want to > pass the ID assigned to the message by the sender-SMTP's to the > receiver-SMTP and log it there, and both sender and receiver are under > my control.) > > Arnt > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k49ITqcK017957; Tue, 9 May 2006 11:29:52 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k49ITqHF017956; Tue, 9 May 2006 11:29:52 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k49ITpxq017950 for ; Tue, 9 May 2006 11:29:52 -0700 (MST) (envelope-from arnt@gulbrandsen.priv.no) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id DC3764AC28 for ; Tue, 9 May 2006 20:29:49 +0200 (CEST) Message-Id: <4+gzdQ6fZM88q0X7he4DPw.md5@libertango.oryx.com> Date: Tue, 9 May 2006 20:33:24 +0200 From: Arnt Gulbrandsen To: ietf-smtp@imc.org Subject: smtp trace id extension Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, I have a vague recollection that there once was an SMTP extension to trace the path a message took after the fact. I cannot find it. Is my memory playing tricks with me, or was there really such an extension? (It doesn't matter whether the extension is odd, obscure and unimplemented. I just need a fairly small part of it anyway. I want to pass the ID assigned to the message by the sender-SMTP's to the receiver-SMTP and log it there, and both sender and receiver are under my control.) Arnt