Joel Rees wrote:
On Wed, Oct 15, 2014 at 9:01 PM, Miles Fidelman
<mfidel...@meetinghouse.net> wrote:
Tanstaafl wrote:
On 10/14/2014 1:58 PM, Miles Fidelman <mfidel...@meetinghouse.net> wrote:
Well, this really is OT for debian-users, but.... Turns out that SMTP
WAS/IS intended to be reliable.
Reliable, absolutely. 100% reliable? That simply isn't possible when
people are involved in the equation (people mis-configure servers -
whether accidentally, through ignorance, or intentionally (just because
that is the way they want it).
I'd always lumped SMTP in the category of unreliable protocols, w/o
guaranteed delivery
The protocol itself is extremely reliable. It is what people *do* with
it that can cause it to become less reliable/resilient.
There are three ways in which machines can be unreliable.
One, they can break.
Two, they can do what they are told to do, but what they are told to
do can be wrong.
Three, they can operate in a context in which they were not designed to operate.
Oh come on, there are lots more ways that PROTOCOLS can be unreliable.
We're talking about an environment plagued with noise, congestion, bit
errors, routing errors, filtering - all kinds of things that are
probabilistic in nature.
"Unreliable" protocols are generally 'fire-and-forget' in nature (e.g.,
UDP) and promise, at most, "best efforts."
"Reliable" protocols are those that include end-to-end (or, more
accurately, peer-to-peer) error checking, ACKs and NACKs,
retransmission, and so forth. In a protocol context, "reliable" means,
essentially, 'once I get an ACK, I can assume that my PDU has been
delivered to my peer' - and has nothing to do with what happens beyond that.
That's one of the reasons the Requests For Comments were RFCs and not
standards dictated from on high (like many of the earlier network
definitions that ended up too inflexible).
Ummm no. RFCs were RFCs because that's how the early ARPANET R&D
community, and its leadership decided to conduct their business, and the
model stuck.
There is a technical distinction between "best efforts" (unreliable)
protocols, such as IP ('fire and forget' if you will), and "reliable"
protocols, such as TCP (with explicit acks and retransmits).
At least in the technical circles I run in (BBN - you know, we built the
ARPANET; Ray Tomlinson, who coined use of the @ sign in email nominally
worked for me, for a short period - in a matrixy version of "worked for"),
SMTP is usually discussed as providing a "best efforts" (unreliable) service
-- which, in reality, it is (particularly in real world configurations where
mail often gets relayed through multiple servers).
So.. I was just a bit surprised to go back and read the RFC and discover
that SMTP is explicitly intended to provide a reliable service.
If it is, that has changed.
Umm.... no. The goal statement hasn't changed. Limitations to that
goal have been elaborated on - i.e., specific limits and exceptions to
that reliability have been elaborated on. But, on the whole, the notion
of peer-to-peer transmission of email, as a reliable service, with
acks/nacks/retransmission/error messages/etc/, remains unchanged.
Elsewhere from the part you quoted, there used to be an explanation of
the self-contradictory nature of the requirements.
Specifically, machines cannot actually (the illusions of PKI becoming
widely accepted notwithstanding) certify delivery. That requires a
human at both ends of the chain, in addition to the possibly human
sender and recipient. RFC 821 messages were intended not to require
any human in the chain.
If that has changed, it would be the unreasoning demands of people who
want e-mail to perfect in ways snail mail only almost could be in the
best of times: people who want to be able to do things like sue other
people for not complying with obscure rules when informed of those
rules by e-mail.
Exactly. RFC 821 and its successors do not address human-to-human
communications, they specify a reliable protocol for MTA-to-MTA
communication. Period.
I'll close by noting that this branch of discussion started with a focus
on silently dropping spam, and whether that's a violation of standards.
It used to be a clear violation of the various MUST statements re.
sending non-delivery messages. It looks like more recent standards now
allow for dropping spam as a specific exception case.
Miles Fidelman
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543ea5ea.1030...@meetinghouse.net
