On 10/14/2014 12:03 PM, Tanstaafl wrote: > 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. >
But you just said it was OK to delete emails. >>>> 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. > I know how it works. And it all depends on when the message is rejected - if it is rejected. Accepting it and deleting it adds no extra overhead to the network. >> increasing the traffic. Simply dropping them, as I do, does not. > > Given an identical mail transaction, with an email with a size of 1MB: > Now how often do you get an email 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). > That's your option. > If you *accept* the mail, then you accepted the entire 1MB of traffic. > > So, who is responsible for more traffic in such a case? > Sure. But spammers don't know whether it is a good address or not. >>>> 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? > I said NOTHING about security. I just don't want them to know what the valid email addresses are. That way they don't send more SPAM to the good addresses. Security is not a problem. People log in to their mailboxes with ids that are not necessarily the same as their email address. >> 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. > Then what is that if it isn't "obscurity"? >> 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 > Tell me what RFC I am violating. Unless I am violating an RFC, there is no "breaking" of SMTP. >>>> 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. > And what if he sends a letter, but misaddresses the letter? >>>> 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. > How many valid emails do you get to a bad email address? The answer on this end is NONE. >> 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? > It is a perfect analogy. In both cases the sender misaddressed the email or envelope. But there is no guarantee it will be returned to you. >>> 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. > I know because I can tell what the attempted email addresses are. >>> 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). > And even if they are configured correctly, email can get lost. Once again - point me to the RFC which states this is wrong. >> 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*... > > Once again - point me to the RFC which states this is wrong. Otherwise, it is just your *opinion*. Jerry -- 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/543d7957.6020...@attglobal.net
