On 10/15/2014 8:14 AM, Tanstaafl wrote: > On 10/14/2014 3:28 PM, Jerry Stuckle <jstuc...@attglobal.net> wrote: >> 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. > > Please don't misquote me. I said it was the *worst case*, meaning, only > marginally better than *bouncing* them, which you should never do. > > I certainly did not say it was 'OK'. >
You said it was OK. You may try to attack conditions to it - but you still said it was OK. >>>> Wrong. Rejecting garbage sends a message back to the originator, > >>> No, it doesn't. It closes the connection with a response code. > > <snip> > >> I know how it works. > > Apparently not, since you keep saying that the RECEIVING server 'sends a > message back to the originator' - unless maybe you simply have a hard > time saying what you really mean, which always causes confusion. > Yes, I do. And it does send a message back to the originator - it may only be a status code, but it is still a message. >> Now how often do you get an email of 1MB? > > Like a large percentage of businesses, we get mail *all the time* that > is many MB's in size. Even all of the freemailers have very large max > sizes they accept now (I think gmail is up to 25MB or 30MB?). > Provide figures for your claim of "a large percentage of businesses". Seldom do I see messages that big on ANY of my systems. Additionally, often times ISPs will limit the size of messages users can send. And many systems have limits on how much storage email can take up. Just because a couple of free email services accept larger messages does not mean EVERYONE does. > But, I'd say 10-15% of our email traffic consists of messages that are 1MB+ > For my systems, it is < 1%. And the average email size is around 20-30K. > And yes, even lots of spam now has larger attachments (even seen them > over 2MB, though not very often). > Yes, spam with trojans and viruses often have large attachments. But those are quickly taken care of by the antivirus routines. >>> 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. > > No, it is the right thing to do. > According to which RFC? Until you can point me to what RFC I am violating, it is just your opinion. >>> 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. > > Thank you for acknowledging that at least this argument in support of > breaking recipient validation (that rejecting emails results in more > traffic than accepting/deleting them) is wrong. We're making progress. > You don't recognize sarcasm very well. >> But spammers don't know whether it is a good address or not. > > Nor do they if I reject the transaction way before the RCPT-TO stage, > which postscreen does *very* well, which is what happens most of the time. > Sure they do. They get a status message back indicating the message was rejected and why it was rejected. The fact they DON'T get that message indicates they have found a valid EMAIL address. And validated EMAIL addresses are a spammer's dream. > Also, my understanding is that there the vast majority of spammers no > longer engage in dictionary attacks to harvest valid email addresses. > Your understanding is incorrect. I see it regularly. >> I said NOTHING about security. I just don't want them to know what the >> valid email addresses are. > > In my mind saying 'I am doing this because I don't want them to know > what the valid email addresses are' is the exact same thing as saying 'I > am doing this for security purposes.'. > It has nothing to do with security, no matter is in your mind. >> That way they don't send more SPAM to the good addresses. > > It isn't about how much spam is targeted at your users, it is about how > much gets through, and an effective anti-spam solution block 99+% of it > - *without* breaking SMTP. And again, my understanding is that there the > vast majority of spammers no longer engage in dictionary attacks to > harvest valid email addresses, so you are continuing to break smtp for > your users and getting very little to no real world value out of it. > It's also about how much is targeted at my users. By not giving spammers a clue as to what is a valid email address, the mail list they use is worth that much less. >>> 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"? > > I didn't say it wasn't 'obscurity', I said it wasn't "*security through > obscurity*". The first is a simple word that has a very broad and > general meaning. The second has a very specific and limited meaning. > And what is it if it's not "security through obscurity"? >>> 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. > > Objection: asked and answered (see directly above). > No, you have shown NO RFC is being violated. Only your opinion. >>> 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? > > He'll (hopefully) know about it when it gets returned, because his > secretary (hopefully) isn't stupid and puts the correct return address > on it. > Maybe it will get returned, and maybe it will not. There is no guarantee a misaddressed letter is returned. It may have just been trash canned by the wrong recipient, for instance. Or it may end up in the dead letter office. >>> 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? > > Please answer the question. > Any email to a bad email address is fraudulent and/or inappropriate. >> The answer on this end is NONE. > > That is *your* answer - but only because you silently delete them, so in > fact, you really don't *know* how many, *because* you silently delete them. > Yes, I do, because I can read the logs, and see where they are coming from. > I see them from time to time It isn't a daily thing, but it definitely > happens often enough. I'll get a call from someone occasionally saying > 'xyz's emails to me are bouncing (their terminology, they are rejected, > and they get the rejection notice), and when I investigate, it is almost > always because of a typo. Sometimes the message is too big, or even more > rarely it is because their sending server is on a blacklist we use, but > the most common issue by far is a typo. > Maybe you need a better class of customers. > You never get these complaints because the emails are silently deleted. > Nope, but I do read the logs. >> 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. > > 100% guarantee? No. But there is a 99+% guarantee that it will in both > cases, *except* in cases where the mail server is configured to accept > then silently delete them, or the sender of the letter doesn't put the > correct return address on it. In those two cases the sender is 100% > guaranteed to *never* get a notification. > The proof of a 99+% guarantee? Or are you just pulling figures out of your head? >> Once again - point me to the RFC which states this is wrong. >> >> Otherwise, it is just your *opinion*. > > And the opinion of 99+% of the people who run the internet - people like > Wietse Venema and all of his peers. > > And your proof of "99+%" of the people who run the internet"? Once again - show me the RFC I am violating. Otherwise it is just your opinion. You don't like it? Do you know what? I really don't care! But my clients appreciate it. And they are who count. 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/543e9b8f.9070...@attglobal.net
