Well, this really is OT for debian-users, but.... Turns out that SMTP
WAS/IS intended to be reliable.
I'd always lumped SMTP in the category of unreliable protocols, w/o
guaranteed delivery - but then, being a bit pedantic, I went back to the
source RFC 821, SMTP, authored by Jon Postel, and found a few tidbits...
------------
1. INTRODUCTION
The objective of Simple Mail Transfer Protocol (SMTP) is to transfer
mail reliably and efficiently.
SMTP is independent of the particular transmission subsystem and
requires only a reliable ordered data stream channel.
<and>
4.2. SMTP REPLIES
Replies to SMTP commands are devised to ensure the synchronization
of requests and actions in the process of mail transfer, and to
guarantee that the sender-SMTP always knows the state of the
receiver-SMTP. Every command must generate exactly one reply.
---------------
The latest spec, RFC5321 goes on to say:
6. Problem Detection and Handling
6.1. Reliable Delivery and Replies by Email
When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
message in response to DATA), it is accepting responsibility for
delivering or relaying the message. It must take this responsibility
seriously. It MUST NOT lose the message for frivolous reasons, such
as because the host later crashes or because of a predictable
resource shortage. Some reasons that are not considered frivolous
are discussed in the next subsection and in Section 7.8.
If there is a delivery failure after acceptance of a message, the
receiver-SMTP MUST formulate and mail a notification message. This
notification MUST be sent using a null ("<>") reverse-path in the
envelope. The recipient of this notification MUST be the address
from the envelope return path (or the Return-Path: line). However, .....
--------
Mind you, we're only talking about transferring mail reliably from SMTP
peer to SMTP peer (or perhaps, file system on the sending system to file
system on the receiving system); and RFC821 does not address multi-hop
mail transfer.
Miles Fidelman
Joel Rees wrote:
Oh, dear. Somebody is WRONG on the Internet!
You're talking past each other.
Still, the current "standard" e-mail protocols were never meant to be
either reliable or secure, and their is a very good reason for that.
People may not be as reliable as machines in executing protocols, but
they cannot be 100% reliable, and only people can certify things.
2014/10/15 1:04 "Tanstaafl" <tansta...@libertytrek.org
<mailto:tansta...@libertytrek.org>>:
>
> On 10/14/2014 11:17 AM, Jerry Stuckle <jstuc...@attglobal.net
<mailto:jstuc...@attglobal.net>> wrote:
> > On 10/14/2014 8:05 AM, Tanstaafl wrote:
> >> If you think I'm kidding, please by all means go make these silly
> >> statements on the postfix list and I'll just sit and watch the fun.
>
> > You don't read very well. This has nothing to do with emails to a
valid
> > address. A large amount of that spam goes to invalid addresses.
I see
> > them go through the logs regularly.
>
> I read fine. The 'silly statements' reference was about your suggestion
> that it is in any way shape or form 'ok' to *accept* mail to invalid
> recipients then send it to dev/null.
>
> >>> To bounce all of those invalid addresses not only would further
> >>> increase the amount of junk on the internet,
>
> >> That is pure and absolute nonsense. The vast majority of spam
comes from
> >> botnets, and *rejecting* garbage from these results in ZERO
additional
> >> smtp traffic.
>
> > Wrong. Rejecting garbage sends a message back to the originator,
>
> No, it doesn't. It closes the connection with a response code.
>
> The system that had opened the connection and was attempting to send the
> email is the one responsible for 'sending a message back to the
originator'.
>
> Well, *if* the system talking to your server is the originating server,
> that is.
>
> If, on the other hand, there were relays involvbed, then it would simply
> relay the response code back down the chain until it got to the
> originating server.
>
> This is very simple to validate. I suggest you do so before compounding
> your error in public.
>
> > increasing the traffic. Simply dropping them, as I do, does not.
>
> Given an identical mail transaction, with an email with a size of 1MB:
>
> If I reject the mail at the RCPT-TO stage, then I only accepted a few
> bytes of traffic before terminating the connection with an SMTP response
> (error) code. The connecting machine then decides whether to pass the
> response back or not (again, a few bytes at most).
>
> If you *accept* the mail, then you accepted the entire 1MB of traffic.
>
> So, who is responsible for more traffic in such a case?
>
> >>> but by not replying, servers tell the spammers what are valid email
> >>> addresses.
>
> >> More nonsense. Security through obscurity *never* works, and only, in
> >> this case totally breaks SMTP.
>
> > Wrong on two counts. First of all, the false notion "Security through
> > obscurity *never* works". This has nothing to do with security.
>
> You said you were concerned about telling spammers valid emails. Why are
> you concerned about that if not from a security perspective?
>
> > And BTW, that statement is also wrong - why do you think people are
> > encouraged to use obscure passwords if it doesn't work? But that's
> > another subject.
>
> Lol! Not even in the same ballpark, Jerry. Passwords, by their very
> nature, are intended to be difficult/impossible to 'guess'.
>
> To suggest that this is even in the same universe as 'security through
> obscurity' is ludicrous.
>
> > On the second count - please point out exactly which RFC I am
violating
> > that "breaks SMTP".
>
> You don't necessarily need to explictly violate any give RFC to 'break
> SMTP', Jerry.
>
> Breaking recipient validation defacto breaks SMTP. It tells the sending
> server that everything is OK, when it isn't. It allows someone who
>
> >>> Finally, as for "...undermine confidence in the reliability of the
> >>> Internet's mail systems..." - it hasn't been reliable since spammers
> >>> virtually took over the email. And even when emails were
rejected, it
> >>> still was no indication the recipient got the message.
> >>
> >> Of course it wasn't, but it was certainly a positive indication
that the
> >> recipient did *not* receive it (as long as the sending server is
> >> properly configured).
>
> > And why should I care if a bot finds out the message has not been
received?
>
> No one should. What I do care about is if the President of NBC typos an
> email address to our President when sending an important email, I want
> him to know the email didn't make it.
>
> >>> BTW - by definition, any messages to any of the domains I manage
without
> >>> a valid email address are "seriously fraudulent or otherwise
inappropriate".
> >>>
> >> Really?
> >
> > Yes
> >
> >> So when the President/CEO of XYZ Corporation, who does business
with a
> >> customer whose domain happens to be managed by you, accidentally
typos
> >> an email address, you consider that a 'seriously fraudulent or
otherwise
> >> inappropriate' email?
>
> > Yes.
>
> Please explain what is *Seriously Fraudulent* or *otherwise
> inappropriate* about a typo in the recipient address of an otherwise
> perfectly legitimate email, Jerry.
>
> > Just like a misaddressed letter at the post office. It will not
> > necessarily be returned.
>
> While not a perfect analogy (big difference between totally automated
> systems and systems that have imperfect humans (postoffice workers) in
> the mix), it is still generally wrong.
>
> I have had more than one letter/package returned because it was
> misaddressed in my lifetime - but of course, this does require that you
> actually put a valid return address on it. But I guess maybe you are
> against that too?
>
> >> You must not have any real commercial customers, because I would
imagine
> >> you would be a prime target for lawsuits for losing emails like
this, as
> >> it would only be a matter of time before it was something
important sent
> >> by someone important to someone else important.
>
> > I have enough, and there are no valid emails lost.
>
> And you know this because you check every single email that you 'drop'
> to make sure it wasn't a legitimate email with a typo in the recipient
> address?
>
> You have lost all credibility with me Jerry.
>
> >> That said, I do have an email template I send to our users regularly
> >> explaining why/how email should never be considered 100%
reliable, and
> >> if they ever send an email that has money riding on it being
received,
> >> they should follow it up with a phone call to make sure it
actually was
> >> received. I guess people like you are one of the reasons I have that
> >> template and need to send it out on occasion.
>
> > Ah, so even you admit email is not reliable.
>
> Of course... mostly due to people who mis-configure servers, either
> accidentally, through ignorance, or even intentionally (like you are
> advocating).
>
> > If it were, why would you encourage your people to follow up with a
> > phone call? After all, if they didn't get a reject message, the email
> > MUST have gone through.
>
> Again - because:
>
> a) mistakes happen, and
> b) because of people like *you*...
>
>
> --
> To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
<mailto:debian-user-requ...@lists.debian.org>
> with a subject of "unsubscribe". Trouble? Contact
listmas...@lists.debian.org <mailto:listmas...@lists.debian.org>
> Archive: https://lists.debian.org/543d494f.7060...@libertytrek.org
>
--
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/543d6451.7040...@meetinghouse.net
