[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: TURN and disconnected SMTP with dynamic IP addresses
Perhaps I'm being dense but I've thought this over for some time and fail to
see the security value in it. So you add an additional value to the ETRN command
<key>. The host that issues the ETRN command decides what the value of <key>
is. When the host that accepted the ETRN command forces a connection to the node
specified, it just adds an additional line to the EHLO parameters and
regurgitates the <key> value back. It is now up to the host that issued the ETRN command
to make sure that the <key> value returned in the EHLO parameters matches what
it sent in the previous session. What if it doesn't? Issue QUIT? What of
non-compliant servers that will just accept the mail without noticing the extra EHLO
parameters? It seems to solve the problem if both hosts are honest AND play by
the same rules.
I've got a counter argument/suggestion. Making note of the liberal timeout
values recommended in RFC1123 with regard to SMTP hosts and the and the nearly
pervasive deployment of sendmail8 as the target of ETRN requests[1] I'd suggest the
following:
In section 5.1 of RFC1985 paragraph 2 and 3 we read:
At the moment, there is no requirement that a connection must occur,
or that the connection must occur within a given time frame. This
should be noted in the case where there are no messages for the
client host at the server host and only the 250 response is used.
Since the processing of the queues may take an indeterminate amount
of time, this command should return immediately with a response to
the client host. The valid return codes for this command are:
I suggest that (1) a 200 level response be issued only after the host that
accepted the ETRN command has checked it's queue structure for a valid queue by that
name, enumerated the messages that need to be sent and, if any are pending,
established a new connection to the host that issued the ETRN command (2) the IP
address of each incoming SMTP connection be cached for the life of the session by
a server that is able to serve a ETRN request so that and dynamic DNS changes
can be avoided. This may also require that parameter provided in the EHLO command
be resolvable back to this same IP. (3) an additional 400 level code be added
to indicate that a connection back to the ETRN requester could not be
established.
I still don't think I understand just how SMTP domain resolution can occur
reliably in conjunction with dynamic DNS. Anyone want to offer any clarification?
[1] reference D.J. Bernstein's surveys of Internet mail hosts at
<ftp://koobera.math.uic.edu/www/surveys/smtpsoftware2.txt> and
<ftp://koobera.math.uic.edu/www/surveys/smtpextensions.txt>
--------------------------------------------------------------------
Mike Byrns - Quality Assurance Engineer - CE Software, Inc.
Developers of QuickMail Pro - "Your Best Choice For Internet E-mail"
mike.byrns@xxxxxxxxxx - (515) 221-1801 - http://www.cesoft.com/
On 9/30/97, Jack De Winter wrote:
>Was talking with Paul Hoffman from the IMC, and we came up with
>a manner to make ETRN work in a failsafe mode.
>
>Assume that we come out with an extra parameter for the ETRN command
>so that:
>
>C: ETRN <node> <key>
>S: 250 OK
>
>causes a connection to be forced to the given node. When the connection
>is established, we add an extra part of the EHLO parameters so that we
>would receive:
>
>...
>250-ETRN
>250-ETRNID <key>
>....
>
>when we establish the connection.
>
>In this manner, the remote host would be using the same mechanism to
>start the connection to the transient local address. When the connection
>is established, the key that was sent in the ETRN command can be compared
>against the key provided. If they do not match, you can probably assume
>that you are not connected up to the host, and the transient host's
>IP address may have changed.
>
>thoughts? this should address the problems presented thus far.
>
>regards,
>Jack
>-------------------------------------------------
>Jack De Winter - Wildbear Consulting, Inc.
>(519) 884-4498 http://www.wildbear.on.ca/
>
>Author of SLMail for 95 & NT (http://www.seattlelab.com/)
>
>.
>
>
>RFC822 header
>-----------------------------------
>RECEIVED: from SF_Database by POP_Mailbox_-1336505230 ; 30 SEP 97 11:01:06 UT
>Received: from CENIS.CESOFT.COM by abba.cesoft.com
> with SMTP (QuickMail Pro Server for MacOS 1.0.1d1); 30 SEP 97 11:00:59 UT
>Received: from CS.UTK.EDU ([128.169.94.1]) by cenis.cesoft.com
> (Post.Office MTA v3.1 release PO203a ID# 70-34528U500L100S0)
> with ESMTP id AAA17516 for <mike.byrns@xxxxxxxxxx>;
> Tue, 30 Sep 1997 11:00:53 -0500
>Received: from localhost (daemon@localhost)
> by CS.UTK.EDU with SMTP (cf v2.9s-UTK)
> id LAA22627; Tue, 30 Sep 1997 11:46:53 -0400 (EDT)
>Received: by CS.UTK.EDU (bulk_mailer v1.7); Tue, 30 Sep 1997 11:46:42 -0400
>Received:
> by CS.UTK.EDU (cf v2.9s-UTK)
> id LAA22602; Tue, 30 Sep 1997 11:46:40 -0400 (EDT)
>Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca
[199.246.132.198])
> by CS.UTK.EDU with ESMTP (cf v2.9s-UTK)
> id LAA22544; Tue, 30 Sep 1997 11:45:51 -0400 (EDT)
>Received: by lacroix.wildbear.on.ca from localhost
> (router,SLmailNT V3.0 (alpha 10)); Tue, 30 Sep 1997 11:41:23 -0400
>Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca
> (199.246.132.193::mail daemon,SLmailNT V3.0 (alpha 10)); Tue, 30 Sep 1997
11:41:08 -
>0400
>Message-Id: <3.0.1.32.19970930114656.008ef6d0@xxxxxxxxxxxxxxxxxxxxxx>
>X-Sender: "Jack De Winter" <jack@xxxxxxxxxxxxxx>
>X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
>Date: Tue, 30 Sep 1997 11:46:56 -0400
>To: "Jeff Stephenson" <jeffstep@xxxxxxxxxxxxx>, <perry@xxxxxxxxxxxx>,
> "Randall Gellens" <Randy@xxxxxxxxxxxx>
>From: "Jack De Winter" <jack@xxxxxxxxxxxxxx>
>Subject: Re: TURN and disconnected SMTP with dynamic IP addresses
>Cc: <drums@xxxxxxxxxx>, ietf-disconn-smtp@xxxxxxx
>In-Reply-To: <01bcc85b$15fb4860$abe8379d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> om>
>Mime-Version: 1.0
>Content-Type: text/plain; charset="us-ascii"
>
>