Fletcher Mattox | 9 Dec 01:30 1994
Picon

SMTP 521 Reply code

Does anyone know what happened to this draft proposal?
Was it ever placed on a standards track?  Is it an RFC?

Thanks
Fletcher

> From owner-ietf-smtp <at> dimacs.rutgers.edu Tue Apr  5 13:44:30 1994
> From: John C Klensin <KLENSIN <at> infoods.mit.edu>
> Subject: Proposal for new SMTP error code
> To: ietf-smtp <at> dimacs.rutgers.edu
> 
> 
> --Boundary (ID kB7XnYPx9KHEDiBEd7kVSw)
> Content-type: TEXT/PLAIN; CHARSET=US-ASCII
> 
> The attached is a proposal for a new SMTP error code that was received by
> the RFC editor and forwarded to Erik and myself.  Comments should be sure
> to copy the authors.   There is a strong possibility of this being placed
> on the standards track.  Isd there consensus that doing so would be a 
> good idea?
> 
>    john
> 
> --Boundary (ID kB7XnYPx9KHEDiBEd7kVSw)
> Content-type: TEXT/PLAIN; CHARSET=US-ASCII
> 
>    Date: Tue, 5 Apr 1994 17:06:14 +0200 (MET DST)
>    From: Alain Durand <Alain.Durand <at> inria.fr>
>    Reply-To: Alain Durand <Alain.Durand <at> inria.fr>
>    Subject: SMTP 521 Reply code, draft proposal
(Continue reading)

Tor Iver Wilhelmsen | 9 Dec 23:46 1994
Picon
Picon

Re: Don't change RFC822 for the worse!


mohta <at> necom830.cc.titech.ac.jp (Masataka Ohta) writes:
>
>Who are the many people? As you can see, no Japanese implementor-user
>say such a thing. I have never told by anyone that my Japanese
>message is unreadable because it is not labelled.
>
>That's the reality. There is working code. There is strict consensus
>on the use of RFC 822 for Japanese.

Which is all well and fine, and it's also why the RFCs say: As long as
you have a consensus in a mail domain (say, Japan), you can do whatever
you want within that area. Send 16-bit mail, use authorization mechanisms
to your hearts content etc. But as soon as you start interacting with
mail domains _outside_ the area of consensus, you need to follow the
standards. And that currently means MIME or X.400. If you send me
ISO-2022-* mail I cannot read it, since I don't have access to any
machines (that I know of) that can display said character set. If,
however, you send me ISO-8859-1 mail, I can display that easily.

>
>The reality is that it is readable by all the people who can read it.

That's a tautology. If you reread that sentence, it amounts to 1 = 1. And
that is uninteresting.

- Tor Iver

Raif S. Naffah | 11 Dec 03:45 1994
Picon
Picon

Is it possible to recuperate lost messages?

I apologize in advance if this a FAQ, and also if it's not the right
news group to post to, but I'm in a panic mode right now.

I need to know:

1. Is it possible to recuperate messages, i.e. get them sent again from
the server?
2. If yes, how?

I use Eudora 1.5.1 on a SLIP connection to a POP server/provider. 2
days ago while Eudora was dowloading my unread messages --I saw that I
had some 40 something messages. After the 6th message, it hang and my
connection with the provider was lost. When I re-connected again,
Eudora saw that there was no more unread messages.

Talking to the provider's support people, I was told that they will
investigate why it happened, but my 35-odd messages are doomed to
oblivion.

Is any expert out there can/is willing to help on this one?

TIA;

---
Raif S. Naffah                                         Tel: +61-2-413
2700
Type & Graphics Pty Ltd (ACN 061 642 779)              Fax: +61-2-419
3731

(Continue reading)

Harald.T.Alvestrand | 12 Dec 04:10 1994
Picon
Picon

Re: SMTP 521 Reply code

At the MAILEXT working group meeting at the last IETF, the draft
got a rather unclear treatment.
The questions raised were:

- Is it enough? Some clients (in violation of spec) ignore the status
  code of the banner.

- Is it the Right Thing? It seems that a TCP-level function would be
  better, but TCP:ng is a long way off (if ever).

One simpler (?) solution is a server which replies "521" or another
500 code to *every* command; this would not need a spec change.

A further philosophical issue: Some PC mail gateway vendors might in
fact be tempted to try to use the existence of this extremely simple
"SMTP server" as a lever to wiggle out of the requirement that
"postmaster" should work on all servers. This is evil.

Well - anyway, the right list is mailext <at> cs.wisc.edu.

                 Harald T. Alvestrand

Valdis.Kletnieks | 12 Dec 18:22 1994
Picon

Re: SMTP 521 Reply code

On Mon, 12 Dec 1994 04:10:06 +0100, Harald.T.Alvestrand <at> uninett.no said:
> A further philosophical issue: Some PC mail gateway vendors might in
> fact be tempted to try to use the existence of this extremely simple
> "SMTP server" as a lever to wiggle out of the requirement that
> "postmaster" should work on all servers. This is evil.

Is there anybody besides MicroSloth who will actually ship a product that
will send mail and never accept inbound stuff?  I mean, unless your marketing
people say "Version 2.0 - now *accepts* mail, too!!" this seems like a loser.

/Valdis (only half tounge in cheek)

Mark.R.Horton | 12 Dec 20:00 1994
X-Face
Picon

Re: SMTP 521 Reply code

On Dec 12, 12:22pm, Valdis.Kletnieks <at> vt.edu wrote:
> Subject: Re: SMTP 521 Reply code
> On Mon, 12 Dec 1994 04:10:06 +0100, Harald.T.Alvestrand <at> uninett.no said:
> > A further philosophical issue: Some PC mail gateway vendors might in
> > fact be tempted to try to use the existence of this extremely simple
> > "SMTP server" as a lever to wiggle out of the requirement that
> > "postmaster" should work on all servers. This is evil.
>
> Is there anybody besides MicroSloth who will actually ship a product that
> will send mail and never accept inbound stuff?  I mean, unless your marketing
> people say "Version 2.0 - now *accepts* mail, too!!" this seems like a loser.

How about every POP client in the world?  (Yes, I know that's what they
are supposed to do, and if you do it right replies go to the server.  But
you asked...)

MS's SMTP gateway's deficiences are just as bad in the outgoing direction.

	Mark

Harald.T.Alvestrand | 12 Dec 19:43 1994
Picon
Picon

Re: SMTP 521 Reply code

No, I don't think anyone would be that silly, Valdis; what John Klensin
suggested was that certain vendors would use ANY IETF-sanctioned entity
living at port 25 that did not support Postmaster as an excuse not to
support Postmaster at the gateway.

Me, I think the argument is silly, but apparently John thinks it is
real. There is nothing to stop people from using silly arguments!

              Harald A

Alain Durand | 13 Dec 10:51 1994
Picon
Picon

Re: SMTP 521 Reply code


Harald.T.Alvestrand <at> uninett.no:
-------------------------------
> No, I don't think anyone would be that silly, Valdis; what John Klensin
> suggested was that certain vendors would use ANY IETF-sanctioned entity
> living at port 25 that did not support Postmaster as an excuse not to
> support Postmaster at the gateway.
> 
> Me, I think the argument is silly, but apparently John thinks it is
> real. There is nothing to stop people from using silly arguments!
> 
>               Harald A

Really too bad I was not at the IETF. I reread rfc1123 that states:

      5.2.7  RCPT Command: RFC-821 Section 4.1.1

         A host that supports a receiver-SMTP MUST support the reserved
         mailbox "Postmaster".

The question is:
"Is a host that runs a 521 pseudo-smtp server (to clearly announce that
it will not received any mail) a receiver-SMTP or not?
Same question for a M... gateway.

In my mind, a gateway is a receiver-SMTP because it stores and forward mail.
So it receives it.
The 521 pseudo-server does not received any. This makes a big difference!

Other opinions?
(Continue reading)

Marius Olafsson | 16 Dec 00:23 1994
Picon
Picon

Re: CTE:

In <ab151a6c1c021004fde4 <at> [193.13.2.9]> paf <at> bunyip.com (Patrik Faltstrom) writes:

>I would say that the useful choices are 7-bit and Quoted-Printable (for text).
>There are still a lot of non-8-bit-transparent SMTP MTA's so I would like the
>recommendation to be to use 8-bit only when supported by the
>8BITMIME ESMTP extension.

Does anyone have any actual data on this statement. My feeling is that
8-bit-transparent SMTP MTA's severly outnumber UA's that properly handle
Quoted-Printable text.

QP is unfortunatly not a usable CTE in our country (and I suspect that the
same may be true for other European countries with similar number of
non-ascii letters in their written language).

Marius Olafsson
University of Iceland

Patrik Faltstrom | 16 Dec 05:28 1994

Re: CTE:

At 00.23 12/16/94, Marius Olafsson wrote:

>Does anyone have any actual data on this statement. My feeling is that
>8-bit-transparent SMTP MTA's severly outnumber UA's that properly handle
>Quoted-Printable text.

As long as we have ONE smtp server which doesn't handle 8bit transport
mechanism, that is unusable. The correct way of doing this (as I wrote in
my previous message) is to use 8BITMIME ESMTP extension and NOT just
guess that it can be used.

My suggestion was NOT to always use Q-P, only when it is needed.

>QP is unfortunatly not a usable CTE in our country (and I suspect that the
>same may be true for other European countries with similar number of
>non-ascii letters in their written language).

Well, then use Base64, but never, never 8bit without using 8BITMIME
extension first.

    Patrik


Gmane