Am 03.09.2014 um 09:13 schrieb Noel Butler: > Doesnt take you long does it Harry, you've been on this list a > month and already your abusing and putting ppl down, calling > child, telling to STFU, and some other tripe you levelled at Ted. > > Karsten already warned you once, I suggest you remember that.
read the whole thread and how much time i alreay wasted trying to explain Ted how a MTA works to get at the end explained "i leak my valid users list" that's a thead i started and if he needs basic MTA lessons he could start a own topic! > On 03/09/2014 06:52, Reindl Harald wrote: > >> Am 02.09.2014 um 22:32 schrieb Ted Mittelstaedt: >>> On 9/2/2014 4:59 AM, Reindl Harald wrote: >>>>> just get a proper MTA, enable debug logging and watch the commands / >>>>> responses between client and server due a >>>>> message transmission >>>> and to make it clear for you: until after end of data itslef is responded >>>> with success the message is >>>> *undelivered* and tried again from the sendig client if it is a proper MTA >>> However you have GIVEN THE SPAMMER AN OK that they have a valid victim >>> address. You had to issue an OK to the >>> RCPT TO: to get that DATA from them. You just told them "you got a good >>> email address" >> child you do not realize that all you claim below has >> nothing to do with SA, nor did you understand how >> a *layered* spam protecton works nor did you try >> to understand *anything* i explained you >> >> so what - otherwise i had even accepted the message as you do >> >> your setup: >> * not on RBL >> * accept it and drop it silently because the score >> * issue "250 OK i even took the whole message" >> * how do you think you don't leak the RCPT case >> * frankly with the 250 OK you invite to send more spam >> >> my setup: >> * not on a RBL >> * reject it >> * don't issue "250 OK i even took the whole message"" >> * if it was not a spammer trigger a bounce on the >> senders server so that he don't think it was >> successful delivered and can even prove it by logs >>>> if your MTA *don't repsond with success* at END-OF-DATA the message >>>> implicit is counted as *not delivered* >>>> because simply in the middle of data the server could raised an error by a >>>> full disk or something else >>> Yes and the spammer just tries again. And again. And again, forever and >>> forever. >> so what - what has that to do with anything i explained >> and you refuse to understand over the whole thread? >>> The point of blocking on DNS or IP based blocking is to issue that error >>> 5xx because that is the ONLY thing that >>> is going to cause the spammer to delist. Because at that point they are now >>> wasting money and time and resources >>> attempting to deliver to an address that probably does not exist. >> so what - that one was not on a RBL >> and now? >> >> accept the spam message or *reject* it? >> >> i at least reject it >> you accept it, say "250 OK" and then drop it silent >>> Sure they can parse the return code, looking for polite language saying >>> something to the effect "this email is >>> being blocked because you are on Wonkulating Gronkluator's blacklist" that >>> some sites issue to "help" newbie >>> Postmasters realize that their mailserver is being hijacked, or something >>> of that nature. >> what has that to to with the topic? >>> But they GUESS so many of their victim addresses that they can't spend the >>> resources doing that on a dictionary >>> attack, they KNOW that 99.99% of the error 5xx's they get back are for User >>> Unknown. So the few times they guess >>> a real address and get that polite human-readable explanation that they are >>> on a blacklist, gets lost in the noise. >> what has that to to with the topic? >>> But YOUR setup - why that's spam flypaper. Because, YOU are NOT issuing an >>> error 5xx on a sender IP that happens >>> to guess one of your users email addresses - because your just too curious >>> to get at the DATA and inspect the >>> Subject: line. >> jesus christ - Subject is not data - subject is part of the header >> come back after you made it through *basic lessons* >> >> >> the client makes it to spamass-milter because he is *not* >> on the 15 blacklists in front of >>> Thus you are HELPING the spammers build a list of valid email addresses on >>> your domain. >> bullshit - i reject more than 90% like you >> but i don't issue "250 OK" for clear spam, i reject it >>> No wonder you have such spectacular spam counts. The spammers must just >>> love you. Your handing them over your >>> user email list. >> sorry, but you are an idiot >> >> i handle nothing because the accept of DATA only happens >> if the client is not listed on RBL's and so you better >> stop to spread bullshit just because you don't understand >> what people exlaining you by wasting time with your posts >>> Sure, you may determine they are operating from a blacklist and shut them >>> down after they throw you 1,000 >>> guesses from an IP address. But in so doing you have handed them 10 good >>> addresses that they will remember and >>> just attack you from somewhere else from >> bullshit again - more than 90% are rejected by postscreen and RBL's >> frankly postscreen can't leak valid addresses because it even >> don't know them - that information has only the smtpd process >> if you make it through RBL's and protocol tests >>> Do that a couple hundred times and they have thousands of your valid emails. >>>> so the communication looks somehow like: * client: i am sending now data * >>>> server: fine, do so * client: >>>> sending data * client: i have finished with sending data * server: ok, i >>>> accepted that * client: fine, QUIT * >>>> client: closes the connection AFETR QUIT >> you missed to understand to understand that the above communication >> *happens only* if the client *passed RBL checks* and also *passed* >> HELO checks and also *passed* a lot of other tests and until DATA >> was no other reason found to reject it before >>> Here is how yours looks: Spammer: HELO >>> throwawayhostname.throwawaydomainname.TLD like .eu or .co you: OK I did >>> my DNS check, my RBL check, my PTR check and that's a good host so go ahead >>> Spammer: MAIL FROM: >>> <[email protected] >>> <mailto:[email protected]>) >>> You: OK Spammer: RCPT TO >>> <[email protected] >>> <mailto:[email protected]>> You: OK >>> looks good but I want to see your >>> content, so start sending Spammer to itself HOT DAM I GOT ANOTHER VALID >>> EMAIL ADDRESS TO TORTURE FOREVER Spammer >>> to you: DATA, blah blah blah, Subject: Viakkagra blah blah you: OK your >>> content says your a spammer so I'm going >>> to blow the TCP connection and not send a final OK Spammer to itself >>> SUCKER!!!! IF HE THINKS I'LL FALL FOR THAT >>> HE'S DUMBER THAN A POST! I'LL JUST ATTACK FROM SOMEWHERE ELSE USING >>> DIFFERENT CONTENT UNTIL I GET PAST HIS BLOCK. >> BULLSHIT >> >> the communication looks like "postfix/postscreen[30894]: NOQUEUE: reject: >> RCPT from [187.163.175.185]:61326: >> 550 5.7.1 Service unavailable; client [187.163.175.185] blocked using RBL >> xyz" >>> And here is how it SHOULD look: Spammer: HELO >>> throwawayhostname.throwawaydomainname.TLD like .eu or .co you: OK >>> Spammer: MAIL FROM: <[email protected] >>> <mailto:[email protected]>) you: OK >>> Spammer: RCPT TO: >>> <[email protected] >>> <mailto:[email protected]>> You to >>> yourself: Hmm - looks like my user has a >>> blacklist against .co so this guy is unwanted You to spammer: 500 User >>> Unknown Spammer: DAMN, I guessed wrong. >>> Toss that one and go on to the next guess. Or even better: Spammer: HELO >>> throwawayhostname.throwawaydomainname.TLD like .eu or .co you to yourself: >>> We block mail from Russian federation >>> Mafia you to spammer: error 5xx go to hell, spammer. End TCP connection. >>> Spammer: WTF just happened??? Granted, >>> this isn't how SA works but you have been talking about prefiltering and >>> this is how it should look >> damned SA is not part of the whole game >> >> more than 90% rejects happening *before handover the connection to smtpd* >> and so *long before* SA comes in the mix at all >>>> so *please* refrain from reply and discuss about good or bad defaults >>>> until you learned your *basic sessions* >> why did you not follow the advice above?
signature.asc
Description: OpenPGP digital signature
