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>: > > On 10/14/2014 11:17 AM, Jerry Stuckle <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 > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/543d494f.7060...@libertytrek.org >
