Thread View: comp.mail.headers
3 messages
3 total messages
Started by Tovar
Sun, 14 Feb 1988 08:33
re: A plea for sanity (Errors-to:)
Author: Tovar
Date: Sun, 14 Feb 1988 08:33
Date: Sun, 14 Feb 1988 08:33
25 lines
1685 bytes
1685 bytes
Errors-To: is completely unnecessary if SMTP is correctly implemented.
I will disagree strongly on this point. Having seen any number of complaints
about mail not going through from some individuals, i can definitely see the
utility of such a field and have been tempted on at least one occasion to
put a hack into our mailer to insert this sort of thing under certain
circumstances. (I bet MRC might even know what/who i'm talking about). At
least some naive users might be better off having errors go to someone who
knows about such things (rather than just being deleted, which is what happens
all too often).
Where Errors-To: would be most useful is where a message leaves the SMTP world.
... useless bug reports. It has gotten to the point where posting a dozen
messages to one of the mailing lists I maintain produces over a
megabyte of mis-addressed garbage; I've started getting complaints
from subscribers because their (de)subscription requests are getting
lost under all this junk and thus being accidently ignored.
I think SRA is right. There is a problem here and the wider netmail goes,
the worse it's going to get until this get addresses. (Now, as i send this,
i fully expect to get numerous pages of useless crud dumped into my already
grossly overbloated mail file!)
-- Tovar
Re: A plea for sanity (Errors-to:)
Author: Bob Larson
Date: Sun, 14 Feb 1988 21:02
Date: Sun, 14 Feb 1988 21:02
20 lines
1533 bytes
1533 bytes
In article <11806@brl-adm.ARPA> TVR%CCRMA-F4@SAIL.Stanford.EDU (Tovar) writes:
[Quote from previous article:]
> Errors-To: is completely unnecessary if SMTP is correctly implemented.
>I will disagree strongly on this point.
There are many incorrect implementations out there. I fail to see the
need a need for an aditional errors-to field when existing
imlementations fail to use the one that is present already. Yes, it
is an envalope field, which means the envalope cannot be disposed of
before successful delivery. If there are gateways that can't pass
envalope data in an envalope, they should be the ones responsible for
puting the information elsewhere. Since they don't follow the
internet standards, why change the internet standards? Adding another
field does not help, since the problem mailers that can't follow the
current rules are the ones least likly to update to a new standard.
Bob Larson Arpa: Blarson@Ecla.Usc.Edu blarson@skat.usc.edu
Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson
Prime mailing list: info-prime-request%fns1@ecla.usc.edu
oberon!fns1!info-prime-request
Re: A plea for sanity (Errors-to:)
Author: John Chambers
Date: Mon, 15 Feb 1988 16:44
Date: Mon, 15 Feb 1988 16:44
18 lines
1266 bytes
1266 bytes
In article <6959@oberon.USC.EDU>, blarson@skat.usc.edu (Bob Larson) writes:
> In article <11806@brl-adm.ARPA> TVR%CCRMA-F4@SAIL.Stanford.EDU (Tovar) writes:
> [Quote from previous article:]
> > Errors-To: is completely unnecessary if SMTP is correctly implemented.
>
> >I will disagree strongly on this point.
>
Hey, I'd agree. But I'd also point out that it is a total irrelevancy in
today's networking environmant. Sensible programmers don't write code (or
at least try to sell it :-) which assumes that other software is correct.
I learned that lesson the first time I tried calling a library subroutine.
Email has lots & lots of opportunities to re-learn the lesson.
For another metaphor, I'd like to point out that seat belts would be
unnecessary if everyone drove correctly. True, but irrelevant.
--
John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads