Re: How I deal with (false positive) IP-address blacklists...
On Dec 9, 2008, at 2:42 PM, Keith Moore wrote: when the reputation is based on something (like an address or address block) that isn't sufficiently fine-grained to reliably distinguish spam from ham, as compared to a site filter which has access to more criteria and can use the larger set of criteria to filter more accurately. Email systems resources must be defended when confronting millions of compromised systems and infiltrated providers slow at removing abusive accounts. Resources are best preserved when acceptance is decided prior to the exchange of message data. Mapping regions known to host compromised systems or having been frequently hijacked is typically done by IP address. As Ned mentioned, some systems block ranges that span across announced routes. Although there is no reason for this, the growing size of the problem and the address space requires negative assessments be done by CIDR. Rather than depending upon knowing the location of specific abusive sources, the Internet needs a registry of legitimate sources which includes contacts and IP address ranges. Such a list should reduce the scale of the problem, and allow safer exclusions. Normal defenses using Turing tests fail as the state of the art advances. Even if there was a registry, what egalitarian identifier can be used to defend the registration process? Receipt of text messages or faxes? Postal mail? What can replace the typical Turing test? -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How I deal with (false positive) IP-address blacklists...
--On Thursday, 11 December, 2008 10:24 -0800 Douglas Otis do...@mail-abuse.org wrote: ... Rather than depending upon knowing the location of specific abusive sources, the Internet needs a registry of legitimate sources which includes contacts and IP address ranges. Such a list should reduce the scale of the problem, and allow safer exclusions. ... Doug, Independent of much of the rest of this discussion (and a lot of its tone, which I both sympathize with and deplore), that suggestion takes us down exactly the path some of us most fear and which some of the folks who have been posting read into the use of blacklists in practice (whether that reading is reasonable or not). As soon as one starts talking about a registry of legitimate sources, one opens up the question of how legitimate is determined. I can think of a whole range of possibilities -- you, the ITU Secretary-General, anyone who claims to have the FUSSP, governments (for their own countries by licensing or more generally), ICANN or something ICANN-like, large email providers, and so on. Those options have two things in common. Most (but not all) of them would actually be dumb enough to take the job on and they are all unacceptable if we want to continue to have a distributed-administration email environment in which smaller servers are permitted to play and people get to send mail without higher-level authorization and certification. While I freely admit that I have not had hands-on involvement in managing very large email systems in a large number of years now, I mostly agree with Ned that some serious standards and documentation of clues would be useful in this general area. But I see those as useful if they are voluntary standards, not licensing or external determination of what is legitimate. And they must be the result of real consensus processes in which anyone interested, materially concerned, and with skin in the game gets to participate in development and review/evaluation, not specifications developed by groups driven by any single variety of industry interests and then presented to the IETF (or some other body) on the grounds that they must be accepted because anyone who was not part of the development group is obviously an incompetent idiot who doesn't have an opinion worth listening to. That has been my main problem with this discussion, and its variants, all along. While I've got my own share of anecdotes, I don't see them as directly useful other than as refutations of hyperbolic claims about things that never or always happen. But, when the IETF effectively says to a group ok, that is a research problem, go off and do the research and then come back and organize a WG, it ought to be safe for someone who is interested in the problem and affected by it --but whose primary work or interests lie elsewhere-- to more or less trust the RG to produce a report and then to re-engage when that WG charter proposal actually appears. Here, the RG produced standards-track proposals, contrary to that agreement, and then several of its participants took the position that those proposals already represented consensus among everyone who counted or was likely to count. Independent of the actual content of the proposal(s), that is not how I think we do things around here... nor is laying the groundwork for an official determination of who is legitimate and who is not. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How I deal with (false positive) IP-address blacklists...
[EMAIL PROTECTED] wrote: Like it or not, sample size reallly does matter. But if you really do prefer individual anecdotal evidence, I'll point out that in practically every bogus blocking incident I've seen of late, the fault lies not with an operation like Spamhaus, but with some local yokel who thinks he's come up with the FUSSP. In the case government of austria contra spamhaus that local yokel must have been Bundeskanzler Gusenbauer ? Neither the austrian government nor their atnic.at is or has been sending spam nor are they selling domains. But spamhaus blocked them. All mailblockers are primarily mailblockers and sometimes they do hit spam. But it is in this list like in real spam live. One party believes in the holy blacklist also there are different cults who believe in their very own blacklist - and the other party knows all mailblockers are run by the devil and they can proof it. But a proof is nothing against a belief. Kind regards Peter -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] http://www.peter-dambier.de/ http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ULA= fd80:4ce1:c66a::/48 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: How I deal with (false positive) IP-address blacklists...
Schemes that attempt to assess the desirability of the email to the recipient have been tried - personal whitelists, personal Bayesian filters, etc. etc. In practice they haven't worked all that well, perhaps due to the average user's inability to capably and consistently perform such assessments. You are talking about the operational imperative. In ops you have to work with what you have and make the best of things. Well, sure. When you have a million users it's not only difficult to focus on an individual user's needs, it's also totally inappropriate. In ops, yes. But in design its the other way around. The needs of a single user form a use-case which guides the designers. In this forum there are some who believe that the Internet email architecture can be reformed so that it does not have the same weakenesses which allow the flood of spam to produce a positive statistical result for the spammers. DNSBLs may be needed today in email operations, but if the IETF steps up and does the work to fix the root of the problem, perhaps they won't be needed at all in the future. And from what I've seen most of the ones I deal with - these folks are our main customers - take those responsibilities extremely seriously, if for no other reason than large numbers of complaints are very costly to deal with and will end up getting them fired. Again you are talking about email operations which is dealt with very well by MAAWG. It provoked a strong reaction from me because it both reminded me of the appallingly low quality of the previous discourse and seemed like an indication of the resumption of same. And I simply couldn't take another round of it. So how do you and Ted reach consensus? What is it that you and he have failed to understand which causes you to have such emotionally opposite reactions? I suspect that you are thinking like an email operator who has the position that you can't change what is being thrown at you so you just have to deal with it and live with the damage. And Ted is thinking like a user who wishes that Internet email would just work, like his TV and his web browser. Neither of you are wrong. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: How I deal with (false positive) IP-address blacklists...
(While Dave's response to this is exactly correct - notihng in my original note had anything to do with sacrificing small scale setups - our failure to discuss these matters sensibly has some very important implications for small operators that deserve further comment.) [EMAIL PROTECTED] wrote: ... Maybe it's just me, but I'll take the evidence presented by someone who has access to the operational statistics for a mail system that services 10s of millions of end users and handles thousands of outsourced email setups over someone like myself who runs a tiny little setup any day. While large scale is important, small scale setups must not be sacrificed along the way. Of course not. But that's precisely the effect our current approach - or rather, non-approach, is having. We must not create a system where a small cartel of players hold the keys to 'interoperability' at the deployment level. We're not creating much of anything - we seem to prefer endless religious arguments and discussions of irrelevanyt anecdotes to actually getting stuff done. And one of the results of this is that the big players, who would very much like to see the development of standards for accessing reputation systems, standards for so-called feedback loops, and so on and so forth, get tired of waiting and simply roll their own. And when that happens the little guys have no place at the table. Current filtering practice creates way too many false positives already because the large organizations can't afford to bother with identifying the source. My lowly server just handles my wife, myself, and my daughter's business, and way too often I hear complaints about bounces because largeispmailer.com is refusing to accept mail from an insignificant non-member-of-the-club server. Exactly. You and I are not able to play because the standards for the reputation systems and other antispam measure these guys are using are designed in private with no consideration given to open access. The way you change that is by, you know, codifying ways to do these things in openly available standards. But we don't seem to be able to do that. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How I deal with (false positive) IP-address blacklists...
On Tue, Dec 09, 2008 at 02:03:51AM -0500, Theodore Tso wrote: Well, it blocked a legitimate e-mail message, so by definition the rejection was false positive. That's incorrect. Determining whether the rejection was a false positive or true positive is the sole prerogative of the recipient, never the sender. Why? Well, first, because it is the recipient who is generously furnishing the privilege of access to a service to the sender. And second, because were it otherwise, we would of course be told by every spammer on the planet that rejection of their abuse constituted a FP. (We already *have* been told this by a substantial number of them.) Of source, the sender may wish to report the incident to the recipient, or suggest to the recipient that this may be a FP, but the final decision is still that of the recipient. For example, I've blocked all the IP allocations of several countries in some of the mail servers that I run. (After years of non-stop spam and precisely zero non-spam messages.) Those rules are doing precisely what I intend them to do, and unless the IP allocations are changed, will never cause a FP. (That is: suppose a block is reassigned to another country that I do not wish to block, and that an incoming message from it subsequently is presented and rejected. That would be a FP.) ---Rsk ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How I deal with (false positive) IP-address blacklists...
On Tue, Dec 09, 2008 at 11:23:10AM -0800, Dave CROCKER wrote: Evidently you believe that the anecdote you posted proves something, but I am not sure what. Some others have suggested that it proves something which, I strongly suspect, is not what you had in mind. Perhaps you can clarify the purpose of your note. How should it be incorporated into the IETF's deliberations? The point I was trying to make is that there seems to be an inherent assumption by some people, perhaps because the people who make these assumptions run large mail servers, that the problem with someone who is wrongly blocked rests solely with the sender, and not with the utimate recipient, or with the mailer operator. It's essentially an attitude of you have no _right_ to send us e-mail, and if we make an (inevitable) mistake, and blacklist list you incorrectly, it is up to **you** (the sender) to go to us on bended knee and prove tht you are not an evil spammer, or an incompentent Windows desktop owner who has let their machine be taken over by a botnet. I'm sure they feel magnaminous when they offer some method of approaching them on bended knee, hoping that that they will give you permissionto send e-mail --- whether it is via a phone number or whether it is via placing an international phone call and paying $$$ to some Austrialian PTT to beg and plead to be removed from some IP blacklist --- and I am still not convinced it is the best indetifier when deciding whether or not blocking *all* mail from a particular IP address. You may be trying to place the burden on me, but consider that we are merely getting assertions from the other side of the aisle as well. My main point, though, is that in some cases, the ultimate recipient may have a much greater interest in receiving the e-mail than the sender, and so the model of requiring the sender to assume the burden of proof and go on bended knee to the mailserver administrator to let their e-mails through may not be a particularly good model to use as the basis for making recommendations for best practice. Regards, - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How I deal with (false positive) IP-address blacklists...
Theodore Tso wrote: On Tue, Dec 09, 2008 at 11:23:10AM -0800, Dave CROCKER wrote: Perhaps you can clarify the purpose of your note. How should it be incorporated into the IETF's deliberations? The point I was trying to make is that there seems to be an inherent assumption by some people, perhaps because the people who make these assumptions run large mail servers, that the problem with someone who is wrongly blocked ... My main point, though, is that in some cases, the ultimate recipient may have a much greater interest in receiving the e-mail Ted, I asked how your comments were relevant to current IETF deliberations and you responded by re-asserting your complaints. We have all suffered slights from one service provider or another. Shall we all burden the IETF list with recitations of them? To the extent that you believe there is a larger issue, as you appear to, based on your saying inherent assumption by some people you provide no documentation that it is pervasive or significantly problematic for email operation, nor that it is a matter the IETF can do anything about. Email abuse is extremely frustrating. We all understand that. Some of us put quite a bit of effort trying to find ways to counter it. But I fail to see how it helps to use the IETF list for venting one's favorite, latest example of a problem with getting something resolved. Really: If there is a larger issue that the IETF can and should tackle, then let's talk about it. But I'm still not seeing how the thread you started qualifies. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How I deal with (false positive) IP-address blacklists...
At 11:57 AM -0500 12/10/08, Theodore Tso wrote: The point I was trying to make is that there seems to be an inherent assumption by some people, perhaps because the people who make these assumptions run large mail servers, that the problem with someone who is wrongly blocked rests solely with the sender, and not with the utimate recipient, or with the mailer operator. seems ... perhaps ... I know of no one on this list who makes those assumptions. In my discussions with people who run large mail servers, none of them have made that assumption. Who do you think are making those assumptions? --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How I deal with (false positive) IP-address blacklists...
Hi - From: Dave CROCKER [EMAIL PROTECTED] To: Theodore Tso [EMAIL PROTECTED] Cc: ietf@ietf.org Sent: Wednesday, December 10, 2008 10:23 AM Subject: Re: How I deal with (false positive) IP-address blacklists... ... Really: If there is a larger issue that the IETF can and should tackle, then let's talk about it. But I'm still not seeing how the thread you started qualifies. ... The problem is a mis-match between the protocol model (and the points for spam blocking it affords) and the economics of actual use. The debate about sender-vs-recipient responsibility for dealing with false positives misses the point that the party usually responsible for the blocking is under the control of neither the sender nor the recipient. I've spent enough time on hold to far-away lands to be skeptical of claims that ISPs are really that interested in resolving false positives, but I recognize that the experience of individual users isn't considered valid data. Ted's core point seems to be that that the delivery value economic argument does not always align with the sender assumes responsibility for out-of-band-delivery when blocked model, particularly when the cost of out-of-band delivery is far greater than the value of delivery to the sender, no matter how badly the intended recipient who requested the information might want it. By looking only at the SMPT protocol exchange, rather than the next-layer-up request-for-info followed by response, the real use case is distorted. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How I deal with (false positive) IP-address blacklists...
Paul Hoffman wrote: At 11:57 AM -0500 12/10/08, Theodore Tso wrote: The point I was trying to make is that there seems to be an inherent assumption by some people, perhaps because the people who make these assumptions run large mail servers, that the problem with someone who is wrongly blocked rests solely with the sender, and not with the utimate recipient, or with the mailer operator. seems ... perhaps ... I know of no one on this list who makes those assumptions. In my discussions with people who run large mail servers, none of them have made that assumption. My experiences are similar to Ted's. They may not realize that they're making such assumptions. But such assumptions are implicit in the notion that the sender should jump through some additional hoop in order to get his name off of a blacklist or to get his mail accepted. (One hoop that I was recently asked to jump through was to change the PTR record for the source address of my outgoing mail server so that it contained a label of the form mail or mx#.) The emphaiss on operators of large mail servers may be missing the point. A significant amount of mail is not sent via large mail servers. And I don't think that many of us want effective email to be limited to large mail servers. And maybe there are some good guys out there who don't expect senders (or their mail systems) to jump through arbitrary hoops in order to get mail through. But unless there are clear and effective guidelines for what all operators should do regarding spam (and most operators follow them), mail will continue to be unreliable. Simply saying use a trustworthy blacklist is not sufficient - it's just deferring the problem to a third party with even less accountability to the endpoints and less transparency. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How I deal with (false positive) IP-address blacklists...
At 23:58 08-12-2008, Theodore Tso wrote: Well, the intended recipient, is a Linux Kernel Developer. He posted a message on the Linux Kernel Mailing List, about Linux Kernel Developement. I responded, on-topic, with a message that had no advertising material, soliticted, or unsolicited. I think that meets the definition of legitimate e-mail, don't you think? It seems By that definition this message would be legitimate too. Fortunately, this message is being sent through a service provider that does not add a message footer with advertising material. pretty clear the recipient probably wnated to receive it, and in this case, an IP address-based blacklist is causing him not to receive the e-mail. It has been made unreliable for him. The mail server of the recipient rejected the message because the IP address of the sender is listed locally in a blacklist. This doesn't seem like a mail rejection solely based on information provided by a third-party. For classification purposes, this is a false positive if the recipient wants the message. Obviously, the recipient must be aware that he/she was not able to receive the message for that to happen. The rejection message contained a phone number. That can be used to contact the postmaster of the site if the rejection was incorrect. That may be adequate for people exchanging mail locally. As you pointed out, it's not a convenient means of communication when the sender is in another country and he/she might not bother to make a long distance call to resolve the problem. In this case, the message is of little value to the sender; it's the recipient that stands to benefit from it. Sometimes the IP address of the sending mail server is blacklisted because it's from a country or a region commonly associated with illegitimate e-mails. Maybe that's the case here. :-) Even if the postmaster of the receiving server takes all reasonable steps to avoid false positives, it can still happen. The postmaster can either provide an alternative means of communication which is not a burden to the sender or else stick to the belief that his/her mail filtering is perfect and it's up to the sender to jump through hops to get his/her message through. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How I deal with (false positive) IP-address blacklists...
At 1:18 AM -0500 12/9/08, Theodore Tso wrote: This doesn't work for most people, but I had fun composing this response, and coming just a few weeks after people claiming that IP-based blacklists work well, and rarely result in false positives, I felt I just had to share. :-) I don't understand. A site has a *local* blacklist: Delay reason: SMTP error from remote mailer after end of data: host rhun.apana.org.au [64.62.148.172]: 451-sender IP address 69.25.196.31 is locally blacklisted here. If you think 451 this is wrong, please call +61289874478. Why do you think that this is relevant to the earlier discussion? That local administrator could just as easily blocked your site by domain name. As others have pointed out, if the site didn't feel the need to keep local blacklists and instead use more heavily vetted ones, your message would not have been blocked. What are you advocating here? --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How I deal with (false positive) IP-address blacklists...
At 1:18 AM -0500 12/9/08, Theodore Tso wrote: This doesn't work for most people, but I had fun composing this response, and coming just a few weeks after people claiming that IP-based blacklists work well, and rarely result in false positives, I felt I just had to share. :-) I don't understand. A site has a *local* blacklist: Delay reason: SMTP error from remote mailer after end of data: host rhun.apana.org.au [64.62.148.172]: 451-sender IP address 69.25.196.31 is locally blacklisted here. If you think 451 this is wrong, please call +61289874478. Why do you think that this is relevant to the earlier discussion? That local administrator could just as easily blocked your site by domain name. Sadly, it is no less relevant than many of the responses that were posted in the earlier thread. I was and continue to be somewhat appalled by the various types of sloppy thinking that have manifested during this discussion. First and foremost, personal anecdotes are not the best evidence. In fact they are barely evidence at all. For example, let me describe my latest blocked email episode. I run a small server that hosts a few users and some small mailing lists - 1000 members or thereabouts is about the largest list I have. I recently noted a bunch of addresses failing on one of my lists. Investigation revealed that I had run afoul of a local blacklist operated by a small ISP. I rarely bother to pursue such things because good outcomes are rare, but checking out their web site I thought they sounded reasonably clueful (references to rfc-ignorant.org and such), so I decided it was worth pursuing. I contacted them and was informed that while my address was clean, there was another address close by that was emitting spam that they had had to block. I asked them why they couldn't just block the specific address and was told they can only block entire ranges. And the minimum range size for them appears to be so large that the offending address isn't even associated with my ISP! Long story short, I've been screwed by an incompetently implemented local blacklist. Not to belabor the obvious, but this would not have happened had they opted to use, say, an appropriate Spamhaus list. (I checked and found my addres is not listed and the offending address is.) Nor would it have happened had they followed the implementation practices described in the DNSBL documents - they would have been able to block the offending address without blocking me as well. So does this personal experience mean that DNSBLs are a great idea? Of course it doesn't - it's just one case and probably representative of nothing. But the same hoids for all of the other personal anecdotes people have posted. Second, the fact that 10 years ago you set up sendmail for the computer club at your college doesn't make you an expert on modern large scale email systemms administration. The operational concerns for large-scale email setups today are very different from thost that would have applied to small scale setups a few years back. I'm not going to get into the insight real operational experience provides because I also lack the necessary operational experience to have an informed opinion. There are, however, several folks who do have experience with large scale email operations who have posted in this thread and others similar ones here. These are opinions that should be valued, especially when that experience doesn't jibe with your own. And yet the overall response to such postings has IMO been fairly dismissive if not outright condescending. Third, while it may be the case that large ISPs and MSPs appear to many to large, utterly impersonal edifices, the fact of the matter is that people do complain to them when they believe their email has been lost or even delayed. And the cost of handling complaints is considerable, which means that considerable effort goes into trying to minimize the amount of lost mail. (I have responded to or commmented on so many RFPs for improved filtering that cite reduce customer complaints about false positives that I feel entirely justified in making these assertions.) Mechanisms that have high false negative or positive rates are quickly abanndoned in practice, so the fact that many if not most large ISps and MSPS use DNSBLs really does count for something. So the next time you decide to post a message about how your poor Saintly Aunt Millie had a problem sending email to Uncle Harry a few years back and as a result DNSBLs (or whatever the email topic du hour is) suck ass now and forevermore, please do us all a favor and repurpose those electrons and instead send an email to the person you know who took a job at randomlargeisp and now runs their email setup asking for his or her opinion. You might even be surprised at what you hear. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How I deal with (false positive) IP-address blacklists...
Theodore Tso wrote: This doesn't work for most people, but I had fun composing this response, and coming just a few weeks after people claiming that IP-based blacklists work well, and rarely result in false positives, I felt I just had to share. :-) Ted, Evidently you believe that the anecdote you posted proves something, but I am not sure what. Some others have suggested that it proves something which, I strongly suspect, is not what you had in mind. Perhaps you can clarify the purpose of your note. How should it be incorporated into the IETF's deliberations? If you believe that it demonstrates that blacklists do not work well and/or do not rarely result in false positives, perhaps you can document the basis for that assessment. I feel confident that you do not intend a single anecdote, about minor email service participants, to serve as the basis for such a global conclusion about a mechanism that is implemented and relied on by virtually every professionally-run email receiving service on the planet. Thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: How I deal with (false positive) IP-address blacklists...
Second, the fact that 10 years ago you set up sendmail for the computer club at your college doesn't make you an expert on modern large scale email systemms administration. The operational concerns for large-scale email setups today are very different from thost that would have applied to small scale setups a few years back. I'm not going to get into the insight real operational experience provides because I also lack the necessary operational experience to have an informed opinion. To make good standards you need a broad selection of informed opinion from different viewpoints. Why should it not be as simple to set up an IETF standard email system for a small organization as it was 10 years ago? Definitely there are issues of scale that have to be considered, but if the IETF really wanted to have large scale email operators drive new Internet email standards then we would hand the job over to MAAWG. You are right that the quality of the discussion about DNSBLs has not been too good. But the underlying problem seems to be that dissenting voices did not participate in the drafting of the DNSBL document, and therefore the document writers had not found the right level of compromise to get the dissenters on board. Anyone can claim to be a great expert and write a standards document, but the real hard work is in getting a group of people with differing backgrounds and experience to agree with that standards document. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: How I deal with (false positive) IP-address blacklists...
Second, the fact that 10 years ago you set up sendmail for the computer club at your college doesn't make you an expert on modern large scale email systemms administration. The operational concerns for large-scale email setups today are very different from thost that would have applied to small scale setups a few years back. I'm not going to get into the insight real operational experience provides because I also lack the necessary operational experience to have an informed opinion. To make good standards you need a broad selection of informed opinion from different viewpoints. Why should it not be as simple to set up an IETF standard email system for a small organization as it was 10 years ago? You can lament the present-day realities until the cows come home, but the fact of the matter is that it is harder - much harder. I should know, because I was running such a system then, just as I do now. Just as one example - there are many others - back in 1998 there was no need for mandatory spam filtering (I first imposed mandatory filtering on all users on my systems back in 2002), That right there ups the complexity, not to mention the overhead, of operation by about an order of magnitude, and can easily have the effect of pushing the operational issues past what a local IT person with many other responsibilities is able to handle. Definitely there are issues of scale that have to be considered, but if the IETF really wanted to have large scale email operators drive new Internet email standards then we would hand the job over to MAAWG. You're completely missing the point. This issue isn't knowing how to build a large scale email system and I never said it was. Rather, the issue is whether or not people's opinions about the effectiveness of various antispam mechanisms are valid when all they have is a small amount of experience, often quite dated. Maybe it's just me, but I'll take the evidence presented by someone who has access to the operational statistics for a mail system that services 10s of millions of end users and handles thousands of outsourced email setups over someone like myself who runs a tiny little setup any day. You are right that the quality of the discussion about DNSBLs has not been too good. That is far too kind. But the underlying problem seems to be that dissenting voices did not participate in the drafting of the DNSBL document, and therefore the document writers had not found the right level of compromise to get the dissenters on board. Anyone can claim to be a great expert and write a standards document, but the real hard work is in getting a group of people with differing backgrounds and experience to agree with that standards document. You might want to review the actual discussion before making such claims. And while you're at it you might also want to explain how it would be possible to get views that are, to a close first approximation, summed up as DNSBLs are evil incarnate on board. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How I deal with (false positive) IP-address blacklists...
There is one thing I could proof when counting the emails going through the mailer I am responsible for. When we started blocking emails from dynamic addresses we reduced spam by 50%. The gurus would not believe but I could show thenm, when we blocked all but the dynamic addresses we could reduce spam by 50% too. The bad side, we could not show how many legitimate mails did not come through in either case. They were lost. Mailblockers maintained by humans are never perfect. spamhause proofed that when they knowingly blocked atnic.at allthough atnic.at had never sent spam. There is little difference between a mailblocker maintained by humans and a greylist maintained by your own computer except you can correct problems yourself. When I see mailblockers usually blocking all dynamic addresses then I can conlude from my observations that they have at least 50% false positives. There is a minor annoyance with greylists - broken mailers and people with 50 outgoing mailers. Broken mailers are mostly spammers, more than 50%. People with more than 50 outgoing mailers are mostly the source of all that spam. So the greylist is no worse than a mailblocker and it always gives you a second chance. A mailblocker does not. Looking into my exim4 log I can see more than 90% of spam gets lost when some bot on a hitch-hiked machine tries to imitate a mailer. When you try TLS on an incoming mail they all get lost. So why do they setup expensive machines in a colo to run a mailblocker? Money! And you can put those few people with 50 outgoing mailers on your whitelist. Kind regards Peter Dave CROCKER wrote: Theodore Tso wrote: This doesn't work for most people, but I had fun composing this response, and coming just a few weeks after people claiming that IP-based blacklists work well, and rarely result in false positives, I felt I just had to share. :-) Ted, Evidently you believe that the anecdote you posted proves something, but I am not sure what. Some others have suggested that it proves something which, I strongly suspect, is not what you had in mind. Perhaps you can clarify the purpose of your note. How should it be incorporated into the IETF's deliberations? If you believe that it demonstrates that blacklists do not work well and/or do not rarely result in false positives, perhaps you can document the basis for that assessment. I feel confident that you do not intend a single anecdote, about minor email service participants, to serve as the basis for such a global conclusion about a mechanism that is implemented and relied on by virtually every professionally-run email receiving service on the planet. Thanks. d/ -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] http://www.peter-dambier.de/ http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ULA= fd80:4ce1:c66a::/48 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How I deal with (false positive) IP-address blacklists...
[EMAIL PROTECTED] wrote: Why should it not be as simple to set up an IETF standard email system for a small organization as it was 10 years ago? If you go back far enough, New York City was small and friendly. Not much required to build a satisfactory home there. Things have changed. No matter the size of the home, things have changed. Environmental pressures are ignored only at one's serious risk. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: How I deal with (false positive) IP-address blacklists...
Maybe it's just me, but I'll take the evidence presented by someone who has access to the operational statistics for a mail system that services 10s of millions of end users and handles thousands of outsourced email setups over someone like myself who runs a tiny little setup any day. Then the IETF is the wrong place to look for help. The IETF does not give a lot of priority to documenting operational practices. You really should be looking here http://www.maawg.org/about/publishedDocuments And given that MAAWG exists and does a good job of publishing email operational best practices, I wonder why people are so worried that the IETF does not do so. You might want to review the actual discussion before making such claims. And while you're at it you might also want to explain how it would be possible to get views that are, to a close first approximation, summed up as DNSBLs are evil incarnate on board. To begin with, the draft authors could have tried to incorporate those views into the Security Considerations section, since when you scratch the surface of the DNSBLs are evil opinions you will most often find anecodtes about lost or blocked email. Simply ignoring those views will not get you to consensus. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: How I deal with (false positive) IP-address blacklists...
Why should it not be as simple to set up an IETF standard email system for a small organization as it was 10 years ago? If you go back far enough, New York City was small and friendly. Not much required to build a satisfactory home there. Things have changed. No matter the size of the home, things have changed. Environmental pressures are ignored only at one's serious risk. I agree with all of your points. But I also believe that it should be possible to encapsulate the neccessary security features into an Internet email architecture so that people can set up an email server for a small organization in an afternoon, and it will pretty much run on its own. The fact that the current Internet email architecture does not allow for this, and therefore disenfranchises small organizations from running their own email services, does not dissuade me from believing that we could fix the problem if we put some effort into doing so. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How I deal with (false positive) IP-address blacklists...
[EMAIL PROTECTED] wrote: You're completely missing the point. This issue isn't knowing how to build a large scale email system and I never said it was. Rather, the issue is whether or not people's opinions about the effectiveness of various antispam mechanisms are valid when all they have is a small amount of experience, often quite dated. Granted that it's always dangerous to extrapolate from a small sample. But is anybody's experience valid, then? From my perspective, the guys who run these large email systems generally seem to believe that they have to do whatever they're doing, regardless of how much the filtering criteria that they're using have any thing to do with the desirability of the mail to the recipient, and regardless of any particular sender's or recipient's actual experience with having their mail filtered. IOW, It's very easy for both the individual and the mail system operator to find reasons to disregard the other's experience. Who is to say who is right? I certainly don't think that a mail system operator's actions to filter mail without the recipient's consent are inherently justified just because they happen operating a mail system. They do bear some responsibility for their role in this process and in their selection of filtering criteria. -- As for Ted's message, I just thought it was an interesting anecdote, and (as others have pointed out) not particularly relevant to the DNSBL discussion. I didn't see anything wrong with him posting it, and don't understand why it's provoked such a reaction. -- And as for DNSBLs - clearly, there are both good and bad aspects to using third party reputation services as opposed to sites using their own filtering criteria. e.g.: benefits of third party reputation services: - when the number of customers of a reputation service helps defray the cost of maintaining a current and accurate list, and of improving their criteria over time - when the high visibility of a popular reputation service helps keep it honest drawbacks of third party reputation services: - when a widely used reputation service is wrong in a way that affects a large number of sites, whereas when a single site's criteria are wrong it only affects that site's recipients (and arguably the single site is more accountable for its actions). - when the reputation is based on something (like an address or address block) that isn't sufficiently fine-grained to reliably distinguish spam from ham, as compared to a site filter which has access to more criteria and can use the larger set of criteria to filter more accurately. Once again, the crucial issues seem to be transparency, accountability, granularity rather than the reputation reporting mechanism. Which is not to say that the mechanism doesn't also warrant improvement. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How I deal with (false positive) IP-address blacklists...
[EMAIL PROTECTED] wrote: But I also believe that it should be possible to encapsulate the neccessary security features into an Internet email architecture so that people can set up an email server for a small organization in an afternoon, and it will pretty much run on its own. The fact that the current Internet email architecture does not allow for this, I think you are confusing architecture with implementation. You need to talk with product vendors, not protocol architects. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How I deal with (false positive) IP-address blacklists...
Tony, Please re-read what Ned wrote. It was about evidence based on extensive experience, as opposed to evidence based on far less experience. His note had nothing to do with sacrificing smaller operators. It had to do with smaller operators who are more likely to have much less expertise. The thread is about the problem with basing strategic protocol decisions on tiny sample sizes, often numbering one datum. As for the reason for false positives, they are numerous. But the underlying issue is with the inherent requirement for heuristics. That's not due to some operators being big or small and/or insensitive or incompetent. It's the nature of the technical and operational realities. Heuristics produce statistical results and statistics invite a trade-off between Type I and Type II errors. A tradeoff means you can't get either perfect. Some operators (big or small) choose to deal with that fact badly. Others deal with it well. The tenor of the topic, on this list, is that vagaries in operational skill concerning email abuse are somehow different from the vagaries we see with routing, reliability, user interface design problems, and all other manner of real-world uncertainty. It isn't. d/ Tony Hain wrote: [EMAIL PROTECTED] wrote: ... Maybe it's just me, but I'll take the evidence presented by someone who has access to the operational statistics for a mail system that services 10s of millions of end users and handles thousands of outsourced email setups over someone like myself who runs a tiny little setup any day. While large scale is important, small scale setups must not be sacrificed along the way. We must not create a system where a small cartel of players hold the keys to 'interoperability' at the deployment level. Current filtering practice creates way too many false positives already because the large organizations can't afford to bother with identifying the source. My lowly server just handles my wife, myself, and my daughter's business, and way too often I hear complaints about bounces because largeispmailer.com is refusing to accept mail from an insignificant non-member-of-the-club server. By no means do I claim enough knowledge about mail services to offer anything more than the viewpoint of an amateur trying to run a small server. I would agree with the comments along the way that the current state-of-the-art is way too hard, and I am sure my configuration is not correct or complete because I get mail from the process every few hours stating -- error: gpg required but not found! yet every time I try to resolve that I can't figure out what is wrong or if a symbolic link is missing. Even with help from example configs at jck psg, it took a fair amount of time and experimentation to cut over from the previous mta that was being crushed by the spam load. Life is better now, and as of a few hours ago mail from the ietf list is flowing over IPv6, but I know the MX record still needs work because the IPv6 path is being locally redirected. Tony ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How I deal with (false positive) IP-address blacklists...
[EMAIL PROTECTED] wrote: You're completely missing the point. This issue isn't knowing how to build a large scale email system and I never said it was. Rather, the issue is whether or not people's opinions about the effectiveness of various antispam mechanisms are valid when all they have is a small amount of experience, often quite dated. Granted that it's always dangerous to extrapolate from a small sample. But is anybody's experience valid, then? From my perspective, the guys who run these large email systems generally seem to believe that they have to do whatever they're doing, Keith, with all due respect, I haven't exactly seen a flood of well-designed proposals for viable alternatives. Perhaps instead of simply reiterating over and over that these beliefs are false you should instead try coming up with an alternative that demonstrate their falseness. regardless of how much the filtering criteria that they're using have any thing to do with the desirability of the mail to the recipient, Schemes that attempt to assess the desirability of the email to the recipient have been tried - personal whitelists, personal Bayesian filters, etc. etc. In practice they haven't worked all that well, perhaps due to the average user's inability to capably and consistently perform such assessments. and regardless of any particular sender's or recipient's actual experience with having their mail filtered. Well, sure. When you have a million users it's not only difficult to focus on an individual user's needs, it's also totally inappropriate. IOW, It's very easy for both the individual and the mail system operator to find reasons to disregard the other's experience. Who is to say who is right? Absent a working crystal ball there is of course no way to *know* who's right. But consider this: If you have cancer, would you be more comfortable taking that quack nostrum that one guy says cured him or the medication with proven efficacy in a bunch of double blind clinical trials? That one guy *could* be right. But is this a chance you want to take? Like it or not, sample size reallly does matter. But if you really do prefer individual anecdotal evidence, I'll point out that in practically every bogus blocking incident I've seen of late, the fault lies not with an operation like Spamhaus, but with some local yokel who thinks he's come up with the FUSSP. I certainly don't think that a mail system operator's actions to filter mail without the recipient's consent are inherently justified just because they happen operating a mail system. They do bear some responsibility for their role in this process and in their selection of filtering criteria. And from what I've seen most of the ones I deal with - these folks are our main customers - take those responsibilities extremely seriously, if for no other reason than large numbers of complaints are very costly to deal with and will end up getting them fired. And I've seen such firings happen, so please don't bother trying to convince me they don't. As for Ted's message, I just thought it was an interesting anecdote, and (as others have pointed out) not particularly relevant to the DNSBL discussion. I didn't see anything wrong with him posting it, and don't understand why it's provoked such a reaction. It provoked a strong reaction from me because it both reminded me of the appallingly low quality of the previous discourse and seemed like an indication of the resumption of same. And I simply couldn't take another round of it. -- And as for DNSBLs - clearly, there are both good and bad aspects to using third party reputation services as opposed to sites using their own filtering criteria. e.g.: benefits of third party reputation services: - when the number of customers of a reputation service helps defray the cost of maintaining a current and accurate list, and of improving their criteria over time - when the high visibility of a popular reputation service helps keep it honest drawbacks of third party reputation services: - when a widely used reputation service is wrong in a way that affects a large number of sites, whereas when a single site's criteria are wrong it only affects that site's recipients (and arguably the single site is more accountable for its actions). - when the reputation is based on something (like an address or address block) that isn't sufficiently fine-grained to reliably distinguish spam from ham, as compared to a site filter which has access to more criteria and can use the larger set of criteria to filter more accurately. Once again, the crucial issues seem to be transparency, accountability, granularity rather than the reputation reporting mechanism. Which is not to say that the mechanism doesn't also warrant improvement. On this we agree, more or less. But it seems to me that these goals are far more likely to be met with a set of standardized mechanisms than without.
Re: How I deal with (false positive) IP-address blacklists...
Ned Freed wrote: Granted that it's always dangerous to extrapolate from a small sample. But is anybody's experience valid, then? From my perspective, the guys who run these large email systems generally seem to believe that they have to do whatever they're doing, Keith, with all due respect, I haven't exactly seen a flood of well-designed proposals for viable alternatives. Perhaps instead of simply reiterating over and over that these beliefs are false you should instead try coming up with an alternative that demonstrate their falseness. Well, at the risk of over-extrapolating from scant data again, there does seem to be some variation in both practice and and the quality of user experience among mail system operators. So maybe they don't all have to be doing exactly what they're doing now. regardless of how much the filtering criteria that they're using have any thing to do with the desirability of the mail to the recipient, Schemes that attempt to assess the desirability of the email to the recipient have been tried - personal whitelists, personal Bayesian filters, etc. etc. In practice they haven't worked all that well, perhaps due to the average user's inability to capably and consistently perform such assessments. I think we're saying slightly different things. It's one thing to say that attempts to use recipient feedback to tune spam filters on an individual basis has so far not worked well (which is what I take you to be saying, and which also corresponds to my understanding). It's quite another thing to say that the recipient's experience of existing spam filtering systems (however they are tuned) is irrelevant. and regardless of any particular sender's or recipient's actual experience with having their mail filtered. Well, sure. When you have a million users it's not only difficult to focus on an individual user's needs, it's also totally inappropriate. Mumble. It's those millions of individual users' experiences that fundamentally matter. If the test cases don't accurately predict their experiences, then the test cases are wrong. A more defensible statement is that it's not economically feasible to pay staff to deal with each of those individual users on an individual basis, understand their individual problems, and try to fix them on an individual basis. IOW, It's very easy for both the individual and the mail system operator to find reasons to disregard the other's experience. Who is to say who is right? Absent a working crystal ball there is of course no way to *know* who's right. But consider this: If you have cancer, would you be more comfortable taking that quack nostrum that one guy says cured him or the medication with proven efficacy in a bunch of double blind clinical trials? That one guy *could* be right. But is this a chance you want to take? It's an interesting analogy, because the medical profession (at least in the US) also seems to have lost its ability to consider the individual situation of each patient - assuming that individual patients' success rates will closely correspond to those predicted by aggregate statistics, and for which typically, only a small number of variables were considered. Once again, the crucial issues seem to be transparency, accountability, granularity rather than the reputation reporting mechanism. Which is not to say that the mechanism doesn't also warrant improvement. On this we agree, more or less. But it seems to me that these goals are far more likely to be met with a set of standardized mechanisms than without. That's my assumption also. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How I deal with (false positive) IP-address blacklists...
In message [EMAIL PROTECTED], Theodore Tso writes: This doesn't work for most people, but I had fun composing this response, and coming just a few weeks after people claiming that IP-based blacklists work well, and rarely result in false positives, I felt I just had to share. :-) - Ted They didn't say why they had blacklisted that IP so there is no way to determine if it was a false positive or not. That also make the request to phone if the listing was in error pretty hard to determine. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How I deal with (false positive) IP-address blacklists...
On Tue, Dec 09, 2008 at 05:49:02PM +1100, Mark Andrews wrote: They didn't say why they had blacklisted that IP so there is no way to determine if it was a false positive or not. That also make the request to phone if the listing was in error pretty hard to determine. Well, it blocked a legitimate e-mail message, so by definition the rejection was false positive. I've also checked a number of DNSBL's, and no one else seems to have black-listed my IP address, except these jokers. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How I deal with (false positive) IP-address blacklists...
In message [EMAIL PROTECTED], Theodore Tso writes: On Tue, Dec 09, 2008 at 05:49:02PM +1100, Mark Andrews wrote: They didn't say why they had blacklisted that IP so there is no way to determine if it was a false positive or not. That also make the request to phone if the listing was in error pretty hard to determine. Well, it blocked a legitimate e-mail message, so by definition the rejection was false positive. I've also checked a number of DNSBL's, and no one else seems to have black-listed my IP address, except these jokers. - Ted Define legitimate. One that conforms to the RFC's? One that you send? One not containing advertising material? One that does not contain unsolicted advertising material? One about the content of the soil on the moon? One that doesn't discuss the content of the soil on the moon? The only one that can determine if it was a false positive or not is the person that added the entry. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How I deal with (false positive) IP-address blacklists...
On Tue, Dec 09, 2008 at 06:24:11PM +1100, Mark Andrews wrote: Well, it blocked a legitimate e-mail message, so by definition the rejection was false positive. I've also checked a number of DNSBL's, and no one else seems to have black-listed my IP address, except these jokers. Define legitimate. One that conforms to the RFC's? One that you send? One not containing advertising material? One that does not contain unsolicted advertising material? One about the content of the soil on the moon? One that doesn't discuss the content of the soil on the moon? Well, the intended recipient, is a Linux Kernel Developer. He posted a message on the Linux Kernel Mailing List, about Linux Kernel Developement. I responded, on-topic, with a message that had no advertising material, soliticted, or unsolicited. I think that meets the definition of legitimate e-mail, don't you think? It seems pretty clear the recipient probably wnated to receive it, and in this case, an IP address-based blacklist is causing him not to receive the e-mail. It has been made unreliable for him. I also happen to be the founder and program committee chair of the Linyx Kernel Summit, which brings together the top 75 kernel developers to the summit, and for which the competition to receive an invitation based on merit is highly competitive. Heck, some companies pay $25,000 USD and up in order to receive a sponsored invite to the Kernel Summit. Occasionally, I will send an invite to a fellow kernel developer, and it will get bounced due to some bogus false positive spam filter (very often, it tends to be an IP-based filter). If I'm feeling nice, I'll try to route around the brain-damage. If I'm feeling really annoyed, I'll just drop the bounce on the floor, and assume the developer in question didn't really want the invite, or was too stupid to find a reliable ISP/mail handler, so they don't deserve the invite. This happens to be relatively unique position where I have far more power than the recipient, and in many cases they are much more interested in receive e-mails from me than I am in bothering to figure out why some bogus IP-based address filter bounced my mail. Basically, if they would badly want to receive it, and some bogus technology has made e-mail unreliable, I'd consider that a false positive rejection of a legitimate e-mail message --- and in general, it's their problem, not mine. Any attempt I might make to work around the breakage is due to my charity, not any obligation on my part. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
