Am 03.09.2014 um 19:16 schrieb Ted Mittelstaedt: > > > On 9/2/2014 1:52 PM, 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 >> > > You changed the discussion from what SA does to your Postfix > pre acceptance filter solution many posts ago. Weren't you > paying attention to your own posts?
i explained you a *complete setup* and why SA is only a piece >> 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 >> > > Your words: > > "i am saying to my milter "above score XYZ reject the message" because > only the [SPAM] in the subject is worthless, it just indicates which > messages should go to "spam" or "ham" fpr bayes training" > > I interpreted this to mean you are attempting to content filter on > the Subject: line with a milter. That is a post-acceptance, > post-recipient-address exposure-leak kind of filter > with the drawbacks I already illustrated what SA typically does is add the [SPAM] to subejct and a header to allow filtering for MUA or Sieve - and that is not really helpful > Once more your treating postscreen like a black box and conflating > it with the discussion of what pre acceptance filtering is and > what content filtering is. It's just more Postfix > evangelizing. no - the be behavior of a complete setup is that only a small piece makes it to the extensive content filter wether you use postfix , exim or something else well, postfix indeed has some unique features > if postscreen rejects on a DNSBL without issuing an OK to the > RCPT TO: then it's NOT content filtering or leaking addresses the *whole* point was to explain you that content filtering is only one part of the game > It is pre acceptance filtering. This is the same as greylisting > (which I do and which mainly eliminates dumb bots that ignore > SMTP response codes), and many other kinds of pre-acceptance > filters (PTR checks, milter-callback schemes, SPF and DKIM, etc.) it has *nothing* to do with greylisting greylisting answers with a 4xx code http://www.postfix.org/postconf.5.html#smtpd_delay_reject > And this discussion has little to do with SpamAssassin. YOU dragged > postscreen in here and the notion of pre-acceptance filtering > (when you referred to postscreen using DNSBLs) several posts ago. because i tried to explain you that SA alone is not a ready solution as you expect and as many others explained you: it is a framework and *part* of a solution which needs knowledge to setup > If postscreen rejects on a scan of the Subject: line then it > has issued an OK to a RCPT TO: and leaked an address - and it is > content filtering the same as SpamAssassin. that's how a spamfilter works: different stages: * IP / DNSBL -> OK / Reject * PTR: OK / Reject * Sender address: OK / Reject * SPF: OK / Reject * Subject: OK / Reject * Contentfilter: Ok / REJECT within the session * Virus Scanner: OK / REJECT within the session > At this point I think that further demonstrations from each of us as to what > the > SMTP handshake is are rather pointless. yes > In reviewing your posts and my responses it's obvious that your posts are > all based on a Postfix/postscreen setup and you are making an assumption > that everyone out there works with this software, and can understand what > your saying because they understand that context. i expect if someone talks about a contentscanner he understands the context independet of the software and keep in mind milters are not postfix-specific, frankly they are a sendmail thing originally http://www.postfix.org/MILTER_README.html http://en.wikipedia.org/wiki/Milter *that* would have been postfix specific http://www.postfix.org/SMTPD_PROXY_README.html > This is the mark of a software zealot and evangelist. it don't matter which MTA you use in combination with a contentfilter the main difference is reject or accept and deliver anyways or drop silent and the main point is that you don't want to handoff 90% of your incoming mailflow to the contentscanner at all > I am attempting to respond based on the normal understanding of what the > basic blocks of email transmission are using vendor-neutral language > as much as possible. It is no wonder your getting terribly pissed off > about it. My refusal to engage in this discussion by accepting all your > vendor-specific Postfix terms, you are interpreting as a slap in the face to > Postfix and your enraged by this. if we are talk about email you need to understand what a milter is, what before-queue filtering is, what a queue is and on which levels of the protocl you can snap in which filters and how "expensive" they are to make decisions > I want to talk about ideas me too > You want to talk about Postfix. no i explained on *examples* how things are woring > That is fine except this isn't a Postfix mailing list. that's not the point you expect 90% filtering by a single contentfilter out of the box and refuse to understand that this is just impossible and that you pretend gmail can do that is a impudence because no user ever had a touch with "oout-of-the-box" of gmail > When you can drop all references to Postfix terms and drop the > insistence that all MTA's operate the same as an MTA running > Postfix and all it's associated programs, then I think we can get > somewhere. no, you just could Google somethings, read what i talk about *before* you respond and then seek for how to do that with your MTA or even realize why i use a specific one > I will simply end by echoing something you said earlier: > content filtering should be the LAST RESORT in the filtering chain which i told you at the very beginning of that thread and after you insited in SA has to catch more i explained you why that is impossible and others tried that too > and I will add my own to that: > > NOBODY has come up with a filter yet that works well and > ONLY considers the SMTP handshake BEFORE issuing an OK on > receipt of the recipient's address, that has any long-term > stick-tion because it is technically impossible * you don't know if you accept the body before you scan it * you must answer the question for the valid RCPT before > Every one that has been created has had countermeasures worked > out by spammers. The fact that many unsophisticated spammers > don't use these countermeasures is beside the point, enough do > that too much spam gets past to NOT use content filtering > (such as provided by SA) there are no countermeasures for a spammer against make it on a RBL or use a zombie on a infected machine and get blocked by Dialup-RBL's before the first mail or by get rejected because the dynamic PTR of the infected zombie you can setup your own servers but they will land in a short on a RBL (the R is for real time) and they have not the same throughbot than a zombie-network > Thus, while SA (and any content filter) should be the last > filter in the chain, it's impossible to not have it - it > is required. to filter out the remaining 5-10% percent > In fact, (although I DO NOT do this) many people just accept > everything and put SA at the beginning of the filter chain > and get almost the same results no - read how a milter works (not postfix specific) it's in the middle of the chain and get the whole data from headers to body, but the MTA can reject a message based on the envelope data and stop before body
signature.asc
Description: OpenPGP digital signature
