[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: smtp charter (revised)
Einar Stefferud writes:
> Erik M. van der Poel writes:
> > If the first MTA in the route fails to forward the message, the UA can
> > always try the old MTA. But if there is a failure somewhere along the
> > route, the message will bounce back, unless the MTA is kind enough to
> > do some gatewaying to an old MTA. So I'm saying that it is not
> > practical (nor kind) to bounce the message, and therefore we need to
> > use the old SMTP port anyway.
> I can only guess that your use of the old SMTP will be to push the
> 8-bit message into it without gateway conversion to 7-bit.
No, I was suggesting that the intermediate MTA convert from 8-bit to
7-bit, and then send the message using DATA.
> You have
> the same exact problem with (or without) a new port number!
A new port number may not be such a bad idea, as long as we specify
that an intermediate MTA *must* convert from 8-bit to 7-bit and
forward to an old SMTP port if it cannot forward to a new SMTP port.
As I said, I want to avoid message bounces.
However, I am also worried that a new port number will invite
proposals for all sorts of complicated new features, and that that
will slow down the whole process. I would prefer to do an 8-bit
extension on the old port, making sure we keep it extremely simple and
> See my immediately prior mesage on how this works fine for enclaves
> that want to use 8-bit transfer MTAs, with gateways on the boundaries.
> I have to admit that this does not work well where the 8-bit and 7-bit
> MTAs are intermixed all over the net, and are trying to act like a
> single whole integrated mail system.
I don't think you will be able to cleanly divide the world into
"enclaves". We will undoubtedly have some users demanding 8-bit in the
middle of the United States.
> This is the very problem situation that I am trying to avoid! An
> intermixed lattice mess of 8-bit and 7-bit MTAs, all trying to pass
> different mail together "over the same virtual wire".
Why would this be such a "mess"? Cleanly separating 8-bit DAT8 (or
whatever) from 7-bit DATA seems much less messy than ad hoc 7-bit and
8-bit DATA flying all over the place (as it does now).
Erik M. van der Poel firstname.lastname@example.org
Software Research Associates, Inc., Tokyo, Japan TEL +81-3-3234-2692