Subject: Re: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt

From: "MAEDA Toru" <[email-masked]>
Date: Mon, 02 Jul 2001 19:30:44 +0200

Hi, Wing-san

Could you explain about the current situation that the existing
infrastructure doesn't permit connecting directly from Internet hosts to
internal SMTP servers

Regards.

Toru Maeda

Dan Wing wrote:
> 
> I'm unclear on why the ability to fallback requires the original attempt be in
> SMTP.
> 
> The goals document also says that "Use of Existing Infrastructure" is a goal.
> You do know that the existing infrastructure doesn't permit connecting
> directly from Internet hosts to internal SMTP servers?
> 
> -d
> 
> > -----Original Message-----
> > From: MAEDA Toru [mailto:[email-masked]]
> > Sent: Thursday, June 28, 2001 10:12 AM
> > To: Dan Wing
> > Cc: [email-masked]
> > Subject: Re: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt
> >
> >
> > Hi, Wing-san
> >
> > Thank you for your comments.
> >
> > Since Terminal Mode should fall back to Full Mode or Simple Mode,
> > ESMTP is more preferable than IPP.
> >
> > Regards.
> >
> > Toru Maeda
> >
> >
> > Dan Wing wrote:
> > >
> > > IPP is more suitable for these goals than SMTP.
> > >
> > > -d
> > >
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]]On
> > > > Behalf Of [email-masked]
> > > > Sent: Wednesday, June 27, 2001 4:03 AM
> > > > To: IETF-Announce:
> > > > Cc: [email-masked]
> > > > Subject: I-D ACTION:draft-ietf-fax-terminal-mode-goals-00.txt
> > > >
> > > >
> > > > A New Internet-Draft is available from the on-line Internet-Drafts
> > > > directories.
> > > > This draft is a work item of the Internet Fax Working Group of the IETF.
> > > >
> > > >       Title           : Goals for Terminal Mode
> > > >       Author(s)       : T. Maeda
> > > >       Filename        : draft-ietf-fax-terminal-mode-goals-00.txt
> > > >       Pages           : 5
> > > >       Date            : 26-Jun-01
> > > >
> > > > This draft describes goals of Terminal Mode which was proposed
> > > > in ITU-T SG16 meeting on November 2000 at Geneva.  The Terminal
> > > > Mode supports the transfer of image data, capabilities exchange and
> > > > confirmation for Store and Forward internet fax terminals having
> > > > limited memory and small CPU power.  Terminal Mode also supports all
> > > > features of Group 3 facsimile on the Internet using T.30 signals in
> > > > capability exchange.
> > > >
> > > > A URL for this Internet-Draft is:
> > > > http://www.ietf.org/internet-drafts/draft-ietf-fax-terminal-mode-goa
> > > > ls-00.txt
> > > >
> > > > 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-fax-terminal-mode-goals-00.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:
> > > >       [email-masked].
> > > > In the body type:
> > > >       "FILE /internet-drafts/draft-ietf-fax-terminal-mode-goals-00.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.
> > > >
> >
> > --
> > ***********************************
> > MAEDA TORU
> > Canon Research Centre France S.A.
> > ***********************************

-- 
***********************************
MAEDA TORU
Canon Research Centre France S.A.
***********************************

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 2 Jul 2001 11:13:05 -0700

My mailer I use for POP (and IMAP) here at Cisco is mira-sjcm-3.cisco.com, IP
address 171.69.24.15.

Our firewall doesn't allow you to connect to the SMTP port of 171.69.24.15
from outside of Cisco:

  # telnet 171.69.24.15 25
  Trying 171.69.24.15...
  telnet: connect to address 171.69.24.15: Operation timed out
  telnet: Unable to connect to remote host
  #

I bet you nearly all companies have similar firewall configurations, as the
current practice for any security-aware company is to have all incoming mail,
ftp, and http traffic go to a device that is on the insecure side of the
corporate firewall.  This connection is completely terminated on this device
and this device is then the only device permitted to connect to interior
devices.

You work for Canon, and I expect its configuration is similar -- direct
connections from the Internet to port 25 of arbitrary devices inside of your
company are not permitted.

-d

> Sent: Monday, July 02, 2001 10:31 AM
> To: Dan Wing
> Cc: [email-masked]
> > > > >       "FILE
> /internet-drafts/draft-ietf-fax-terminal-mode-goals-00.txt".
> > > > >

---

From: Claudio Allocchio <[email-masked]>
Date: Tue, 3 Jul 2001 11:20:22 +0100

> and this device is then the only device permitted to connect to interior

This is also completely true in general, as this is the correct secure 
configuration of servers on any LAN/Intranet. For example at GARR (and at 
nearly all the other R&D and academic netqorks, too) there is ONLY a few 
devices (well configured and controlled) which are SMTP accessible from 
outside. A tipical configuration on the router (cisco in this case) is:

access-list 101 permit tcp any host 140.105.4.200 eq smtp
access-list 101 deny   tcp any any
access-list 101 permit ip any any

This will introduce a "relay" host (140.105.4.200 in the above example) 
between any sender and any internal SMTP server in ANY case, and thus 
there will be no direct negotiation nor delivery.

Thus SMTP is defintly a "relay" protocol.

Regards,
Claudio

---

From: "MAEDA Toru" <[email-masked]>
Date: Mon, 09 Jul 2001 18:08:08 +0900

Hi, Wing-san

Sorry for slow responce.

Can IPP and IPP-fax protocol go through under the current firewall
configurations?

Regards.

Toru Maeda

-- 
*********************************
MAEDA Toru
CANON Research Centre France S.A.
*********************************

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 9 Jul 2001 10:23:43 -0700

> Thus SMTP is defintly a "relay" protocol.

Yep.

And I don't see this changing to support 'terminal mode' fax on the Internet.
So for 'terminal mode', I really think we need something other than SMTP as
the underlying protocol.

-d

---

From: "MAEDA Toru" <[email-masked]>
Date: Tue, 10 Jul 2001 23:31:16 +0900

Allocchio-san

Thank you very much for comments.

> Thus SMTP is defintly a "relay" protocol.

I think that the router is confifurated SMTP server as a "relay" device.

Regards.

Toru Maeda

---

From: Claudio Allocchio <[email-masked]>
Date: Tue, 10 Jul 2001 17:09:10 +0100

> I think that the router is confifurated SMTP server as a "relay" device.

... the "router" ? the router does not support any application protocol 
like SMTP. it is level 3 downwards...

If it is a "firewall", then it can act as an intermiediate SMTP relay.

Regards
Claudio

---

From: "MAEDA Toru" <[email-masked]>
Date: Tue, 17 Jul 2001 19:59:14 +0900

Hi, Claudio.

My point is that "firewall" is SMTP relay, 
but SMTP is not a "relay" protocol.

Regards.

Toru Maeda

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 17 Jul 2001 18:19:40 +0200

> but SMTP is not a "relay" protocol.

I disagree.  SMTP is a relay protocol.  RFC2821, says this in Section 1,
"Introduction":

   An important feature of SMTP is its capability to transport mail
   across networks, usually referred to as "SMTP mail relaying" (see
   section 3.8).  A network consists of the mutually-TCP-accessible
   hosts on the public Internet, the mutually-TCP-accessible hosts on a
   firewall-isolated TCP/IP Intranet, or hosts in some other LAN or WAN
   environment utilizing a non-TCP transport-level protocol.  Using
   SMTP, a process can transfer mail to another process on the same
   network or to some other network via a relay or gateway process
   accessible to both networks.

The trouble is the "multually-TCP-accessible hosts on a firewall-isolated
TCP/IP Intranet" -- the remote ifax device will (nearly) always be on a
firewall-isolated TCP/IP Intranet.  If this significant problem can be somehow
overcome, then SMTP could work.  But I am not convinced that network
administrators would allow unauthenticated connections from the Internet to
their internal ifax devices.

Is the intent of the 'full mode' ifax to work only within an enterprise's
internal network, or between enterprises that trust each other, or between
enterprises that have a VPN set up between themselves?  If that's the model,
that's fine, too.  In fact, I could believe such a model would be more
successful and more viable.

-d