Re: Last Call: draft-irtf-asrg-blinds (DNS Blacklists and Whitelists)
The DNSBL BCP document has been updated and submitted to the IETF as http://www.ietf.org/internet-drafts/draft-irtf-asrg-bcp-blacklists-05.txt This is not an official IETF last-call, and can't be officially considered as being co-submitted with the last call of the DNSBL protocol specification (draft-irtf-asrg-dnsbl), proposal as it should have been arranged to be. Taken for whatever it's worth, this is only minor typographical revisions to the previous draft (04) that was deemed ready for last-call at the ASRG session at IETF Dublin, discussed through many iterations of the ASRG and elsewhere, and I think covers most if not all of the "Security Considerations" type issues raised with draft-irtf-asrg-dnsbl. While the issues raised mostly aren't listed as "Security Considerations" in the BCP, they comprise much of the base content of the BCP. I'm not exactly sure where this is all going, whether the IRTF or IETF, etc., that will depend on the IETF ADs etc. But I think it worth taking a look at for those interested in the subject matter. I guess further discussion should go to the ASRG mailing list. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Florian Weimer wrote: > I can't sign a thousand million RRsets and serve it in a DoS-resilient > manner, even with John's partitioning idea (which is rather neat, > thanks!). I may have to keep that in mind if I ever DNSSEC our internal composite DNSBL zone, which has probably near 500M IPs listed (both "bad" and "good"). [The zone file is > 500Mbytes] > Macro expansion in the client brings down the number of RRsets to a > challenging, but manageable level. Chris says there's precedent for > that, so I think we can end this subthread (or move the discussion to > some place where the topic of DNSSEC scalability would be more > on-topic). Even more for a client-supplied string being macro-expanded in the client. Eg: no TXT query at all. If I had to guess, I suspect that more than half of clients don't issue a TXT query and synthesize their own error message instead. The vast majority of DNSBLs are arranged so that a single message with macro substitution of IP is sufficient to produce a useful error message, so why wait for a TXT query if you can configure the client to generate its own? Even tho I publish TXT records in our internal DNSBL zone, the filters themselves don't query them. The TXT records are used by administrative tools as part of the FP process because they contain diagnostic information on the entries. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Florian Weimer wrote: > The expectation is that error messages generated from TXT records > contain the actual IP addresses which triggered the DNSBL lookups. As > a result, if you list a /16 (say), you need publish 65,536 different > TXT records. > > Currently, these records are synthesized using a macro capability in > the DNS server. How does that break DNSSEC? A number of DNSBLs merely suggest an error message in their usage instructions, and leave it up to the client to synthesize a combination of the suggested error message and the IP address. Macro expansion in the client (either of supplied TXT or client-configured string) seems common. Of course, they're still only suggestions, and some DNSBL users will generate their own. The worst of all is the clients that don't tell you what the IP was and no other way to remediate issues. There are situations like this which even leave admins scratching their heads. [While the BCP isn't yet on the table w.r.t. the spec (it may be), this issue is covered in the BCP.] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: more bad ideas, was uncooperative DNSBLs, was several messages
John Levine wrote: >> For instance, what would happen if mail servers provided feedback to >> both senders (on a per message basis in the form of NDNs) > > Well, since 95% of all mail is spam, and all the spam has fake return > addresses, you'd increase the amount of bogus NDNs by more than an > order of magnitude. No thanks. > > Incidentally, on a bad day I already get 400,000 NDNs from mail that I > didn't send, just from the minority of MTAs that send NDNs in response > to spam now. This is not a hypothetical problem. Point of order: is NDN "produce bounce" or does it include "reject"? In my response I took NDN to mean "reject". Not bounce. Filters should never bounce (and that would go in a filtering BCP). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: uncooperative DNSBLs, IETF misinformation (was: several messages)
Theodore Tso wrote: > I would also encourage the "how to run a DNSBL responsibly" to be > published at the same time, so that draft-irtf-asrg-dnsbl could > reference the "this is how you do it right" (while acknowledging the > only out of band mechanisms can be used to ensure that a DNSBL > operator is truly following the criteria they claim to be using). In retrospect, putting them up simultaneously might have been a good idea. Neither John nor I thought of that. The latest rev of the BCP is ready for upload, but the IETF web site won't let me until Monday. Come Monday, I'll be uploading and posting pointers in relevant places. The previous iteration of the BCP was by concensus ready for last call at the ASRG session in IETF Dublin. The changes since then are typo corrections and a minor addition as suggested by the ASRG meeting. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: several messages
John C Klensin wrote: > Sigh. > > Rich, you can blame "someone else" all you like, but the reality > here is that > > (1) If the system supporting the DNSBL is following the email > protocols and decides to reject the message or bounce it, rather > than, e.g., assigning a score and moving it into the > user-related mail store, it replies back to the IETF list > manager, not the original sender. That means that the original > sender never finds out that the subscriber didn't get the > message. Indeed, there are other standards and norms that > suggest that telling the sender is a privacy problem. Whoa. You have this almost precisely backwards. In virtually all cases if the recipient's mail server is using a DNSBL, and it rejects an IETF-forwarded list item, it's because ietf.org's _own_ mail server is listed, and the ietf.org list admin is the person most properly informed of that fact. Which they will be by existing standard. In fact, if the DNSBL was widely used and you expected the IETF list to violate email standards and reply to the From:, the IETF list would be mailbombing everyone who submitted an article to it with almost as many copies of their email as there are IETF subscribers, few if any would be able to do anything about it, and the admins (who are most likely to be able to address the DNSBL listing) wouldn't know until someone complained directly to them. >From a different angle, in the use-case at hand (IETF items bouncing for whatever reason), if my email to the list gets bounced by, say, Joe's (any Joe ;-) mail server, who suffers? Not me. Who can fix it? Not me. What's the point of telling me? There isn't one. Not to mention privacy etc. Bouncing to From:/Reply-to is precisely the WRONG thing to do. You won't get argument about that from anyone that I can think of. [Partially because I remember when a MTA's propensity to bounce to the From: blew up the first incarnation of the Usenet Moderator's Mailing list. 15,000 bounces in the first couple hours via dialup. Ouch. It was over a week before the list came back up. I've caught Exchange 2007 doing it under some circumstances (at one of our own customer lists). Had 'em disconnected at their ISP until they fixed their server.] Experience seems to indicate that list owners when presented with persistent/intractable/difficult-to-handle bounces (other than DNSBL listings of their own server) simply consider it to be a problem with the recipient's mail server, unsub, and move on. Many list packages are instrumented for just that. The email standards are quite correct in this space. The reality is that this "problem" is a MUCH bigger issue with non-DNSBL filters that do content analysis. So again: this is NOT a DNSBL/reputation issue, but a filter implementation issue. > (2) If that IETF server gets back a reject (i.e., a reply code, > not an NDN) and follow the letter of the SMTP protocol, all it > knows is that it got a permanent message rejection (5yz code) > for a particular address. Trying to impart better meaning to SMTP protocol returns in terms of filtering is a filter implementation and SMTP standard issue, not DNSBL. Secondly, as I'm sure Al Iverson and others can echo, there's significant amounts of intelligence that can and is be applied to the errors as they exist today, ESPs do it all the time. MAAWG has been trying to work this area and produce some sort of SMTP extension standardish thing (so ESPs can figure out how "permanent" a "permanent" SMTP error is supposed to be and what they should do about it), but has self-barred itself from some of the more obvious and convenient ways of doing this (eg: extensions to the 5.x.x extended SMTP return codes) by a perceived inability to get such suggestions past the IETF. They're probably not wrong for the same reasons that the very notion of DNSBLs is getting the reception here that it is. > If it has logic to count the number > of rejections for a particular address and does so, you've got > exactly the situation Randy posits. The sender doesn't find > out; the subscriber is left to notice a reduction in mail > received and to then try to figure out what happened in what may > be a very hostile environment. Rejects (by DNSBL or any other filter) in no way prevent the recipient also finding out (by quarantine, junk folder, email notification or otherwise) that that email was rejected. Again, this is a filter implementation BCP issue, not an issue specific to a technique (DNSBL or content filter or ...). > (3) If that IETF server gets back an NDN -- either because the > DNSBL system is organized to send NDNs rather than rejecting > messages or because there are relays (including SMTP-handling > firewalls) involved -- things are basically hopeless because the > number of mailing list servers that are able to accept NDN > messages, correlate them with particular addresses on particular > mailing lists, and take action on that basis is, well, small. I
Re: uncooperative DNSBLs, was several messages
Keith Moore wrote: > Dave CROCKER wrote: > >> The difficulty is that the current line of argument is that because some >> DNSBLs are operated badly, DNSBLs are bad. > > I have a strong suspicion that poor design of the DNSBL protocol (and/or > its interface to SMTP and NDNs) encourages more badness than is needed. Step back from DNSBLs. What you are describing is more properly a BCP for the implementation of email filters in general, and is not directly relevant to the protocols involved in any one kind of filtering. These are NOT reputation systems issues. These are filter implementation issues. The problems you ascribe below are equally (or more) applicable to almost all other filtering techniques - whether or not you're relying on external supplied filtering information. The ones that this isn't applicable (such as greylisting, or banner delays for example), are often by their very nature incompatible with your suggestions (eg: you can't quarantine a banner delay FP). As such, such considerations really belong in a entirely different document about filtering in general. Which is a fine charter for a WG, more useful than one on DNSBLs or reputation systems specifically. So, I'm going to attempt to cover your "for instance" from a more general perspective - showing that your "for instance" scenarios are already broadly implemented throughout the industry, but there are problems and caveats that you're not aware of. > For instance, what would happen if mail servers provided feedback to > both senders (on a per message basis in the form of NDNs) They already provide feed back to senders. Most filtering systems supply NDNs with either a reasonably direct explanation of what happened (eg: "we don't allow swear words", or "see http://spamhaus.org/lookup=X";), or provide means by which remediation can be achieved, eg: "If you believe this is in error, please contact [EMAIL PROTECTED] with the following sessionid ". [That's what ours says.] DNSBLs are perhaps the best at supplying suggested text for the NDN (eg: TXT records in the protocol spec.). Other systems aren't so consistent. But remember, it's only a suggestion. The filter implementer need not use it. We don't. On purpose. We have chosen, as a corporate, to not reveal _any_ filtering reasons in NDNs as a security measure, and get the sender to contact us for remediation (via the message I quoted above), and explanation if necessary for remediation. Any BCP that insists on the NDNs being perfectly transparent about "why this email was blocked" is going to be rejected by a large chunk of the industry, DNSBLs or otherwise. You want to know how to get the email blockage fixed. That's a different question than "why was this was blocked". If you can satisfy the former, the latter is seldom necessary. > and recipients > (say, via a web page that listed messages blocked due to DNSBLs)... Many systems, particularly the large ones (eg: all outsourced spam filtering systems, all very large ISP environments etc) provide recipients with one way or another to examine "filtered email", either by tagging, junk folder, web-based quarantine, or summary email notifications - we do the latter two. > in > both cases describing which DNSBL blocked the message and what the > blocking criteria were? Many systems provide direct explanations of the reasons for why the email is in the quarantine or junk folders. Probably becomes "Most" if the user knows how to look. We've explicitly chosen to inhibit displaying the "reason" to the recipient for a particular block for three reasons - security (see above), useability (most users would have difficulty figuring out how to apply the information, so we do it for them), and finally, see below: > What if recipients could disable blocking on a per-DNSBL basis? They often can. Many server-based systems implement per-user customization. However, experience seems to indicate that such functionality is almost never used, and when it is, it's almost always a "all filters on" or "all filters off" choice. Secondly, as a corporate entity (rather than a service provider), it's our email flow, and our ultimate responsibility and liability about what happens on it. In fact, legislation _requires_ us to filter certain things. Therefore, you can't opt out of our filters without a formal security exemption. A BCP requiring per-user opt-out won't be acceptable to the industry. > Assuming that we're going to have reputation services, I'm looking for > ways to make them more accountable/responsible. Your suggestions can't be implemented by a reputation service. Only the filter implementor can, and these suggestions apply equally to all filtering techniques. Doesn't belong in a DNSBL protocol specification. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IP-based reputation services vs. DNSBL (long)
Hallam-Baker, Phillip wrote: > To answer your question about how they got round port 25 blocking, my > guess is that they sent the initial packet out on yet another connection > that was unblocked. Actually, I answered that question - they didn't "get around port 25 blocking". They never sent from the (say AOL dialup) side, only from the high speed side. "three way handshaking" emulation of what's supposed to be "two way", but physically only two (not three) machines. Since they're on the same machine, the timing is not much of an issue. Got high speed spam emission, at the expense of burning (lots of) free AOL low speed access dialup disks. Especially if you pipelined (whether the recipient said it was okay or not) multiple parallel SMTP streams. [The recipient usually has no way of knowing whether you're really waiting for it's SMTP command return codes or not. Which is exemplified by one particular type of HTTP proxy attack. Arrange the entire sending side's SMTP commands in one buffer (eg: a HTTP CONNECT proxy), and send it all at once. Works just fine if you don't care about errors. Which high volume spammers don't.] > I have seen something similar described recently in the context of a > cyber-conflict type attack. Potentially still useful technique, where the economies are different. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: uncooperative DNSBLs, was several messages
Andrew Sullivan wrote: > On Thu, Nov 13, 2008 at 08:18:01AM -0800, Dave CROCKER wrote: >> The difficulty is that the current line of argument is that because some >> DNSBLs are operated badly, DNSBLs are bad. > > I think that's not quite fair. My impression is that there is more > than one line of argument. Here are some different ones that I have > observed in this discussion, some of which seem never to be getting > answers. (Or, sometimes, they seem to be getting answers that are > counter-arguments the the first. I believe philosophers would call > those examples of the straw person fallacy.) > 1. Some DNSBLs are bad, therefore all DNSBLs are bad. (The one you > note, and which is obviously bogus.) Obviously. > 2. DNSBLs are in themselves bad, because there is no way to guarantee > that they won't contain false positives; they are nevertheless > possibly useful, but the trade-offs are inadequeately described in the > current document. If all that's missing is a few sentences in the Security Considerations section, I'm sure that we can get somewhere with that, on the other hand, discussion of those types of tradeoffs probably don't belong in this draft, but a BCP. > 3. DNSBLs are not in themselves bad, but the implementation of them > as described in the current draft (which does describe the current > state of the art in DNSBLs) _is_ bad. The current behaviour and the > desirable behaviour ought to be separated, and one described while the > other is standardized. Behaviour of DNSBL != information transfer protocol. The document at hand only describes the protocol, and should only describe the protocol, and the security considerations should be on the protocol, not the behaviour. "Behaviour" is better described in another document. Like the BCP I'm supposed to finish the .05 revision on ASAP. [If I can stop following this thread maybe I'll get it finished.] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: several messages
der Mouse wrote: >>> It _does_ mean that someone to whom email is important had better do >>> due diligence in selecting DNSBLs - just as someone to whom a car is >>> important had better do due diligence in selecting a mechanic [...] >> I agree with that. But easier still is to setup your own spam traps >> and run your own spamfilter. Which is what I think most actually do. > Not easier for me; not easier for the ISP I work for (I'm part of its > collective postmaster). I, at home, and we, at work, find DNSBLs by > far the lower-cost answer, after all the costs are tallied (dollars > spent, human time, false positives, false negatives, machines, disk > space, network bandwidth, the list of forms costs can take is long). In today's climate, you have to have very large spamtraps to do an effective job in driving your own filters unless you have an atypical spam load. If you have users that are being hit by BOTnets, your spamtrap has to be in the 100s of thousands of emails per day, if not larger, to be able to derive the right information to tune filters to an effective level. We're a large company, and we've been able to, through our legacy domains and "gracious donations" to get our traps up to about 10-20M per day. That alone does a pretty good job. But even we, despite how big our traps are and how well they do, get considerable extra effectiveness by using DNSBLs. At least one of these DNSBLS, via mutterings in the woodworks, has spamtraps that are effectively more than 2 orders of magnitude bigger than ours. Yikes. Someone of the size of AOL or Gmail can do the spamtrap game all by themselves - internally, they usually generate source IP reputation lists (however distributed) in addition to other techniques to use that information. But almost everyone smaller needs much more trap than they can realistically construct themselves. Small sites with usually atypical spam loads can often do just fine with very much smaller data sources. It's amazing how much different the spam profile can be at small sites. But they generally don't work nearly as well once scaled up to larger environments with more representative loadings. As one datapoint to show how uneven spam distribution is: we have 45,000 recipients. Fully half of them get virtually no spam at all. If we segregated those people off on their own mail servers, they wouldn't need filtering. Meanwhile, the other half get lots. One poor sod was getting 4,000-16,000 spams/day for the better part of a year - no useable commonality whatsoever in what he was getting nor where it was coming from. The only explanation for that, ironic as it may be, is that he was on lots of IETF mailing lists for a very long time that got scraped over and over again. The only solution - just what got past the filters at 99%+ effectiveness was overwhelming - was for him to change his email address (actually we all did, the company domain name got changed. Not because of this, but it helped anyway, causing a huge discontinuity in spam volumes.). [Most of the high rollers in our "spam sweepstakes" are long-term IETF mailing list members on the same address... Long-term IEEE list membership is also a big factor.] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: several messages
Randy Presuhn wrote: > Huh? Concrete, real example: I send a message to an IETF mailing list. > A list subscriber's ISP rejects the forwarded message. IETF's mailman > drops the subscriber, because this has been happened multiple times. > I can't notify the subscriber, because their ISP also rejects my email. > My ISP is irrelevant to the scenario, and the (now former) list subscriber > doesn't even know this has happened, or why. That sort of thing is rarely due to a DNSBL issue. DNSBLs are usually on peers. For your email to have been blocked via both the IETF and directly from you, it usually would have had to have been both the IETF and you that was blocked by the list subscriber's ISP. Which one would hope would be a rare circumstance... It was probably a content filter. We whitelist many mailing lists and forwarders by IP, especially those that talk about spam Unless they leak LOTS of real spam (we're talking > 99% spam). And some do. > Another real, concrete example: some (but not all) messages sent via my > employer were tossed because one of my employer's mail servers was > listed on a blacklist. As an employee, I had no alternatives for sending > mail - company policy precluded the use of "webmail" alternatives via > company infrastructure. The duration of that event should have been short (and usually is). And companies do have means to deal with such eventualities. For example, in a situation like that, many people can cope by sending such critical email by non-company infrastructure. Or relax the rules for the duration of the problem. Once or twice we've been inadvertently hit by a similar blacklisting. They've always been resolved very quickly with little harm done. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: several messages
David Romerstein wrote: > On Wed, 12 Nov 2008, Randy Presuhn wrote: > >> Agreed, but if those analogies are correct, they also undermine the argument. >> Neither the email sender nor the recipient (the ones to whom email is most >> important) typically have any voice whatsoever in the selection of the DNSBL. > End recipients *absolutely* have a voice in the DNSbl selection process. > They have the option of voting with their feet if their ISP chooses a > DNSbl that negatively impacts them. Or as in the case with a non-ISP (eg: a corporate environment like us), they _are_ the end recipients. The liability for missed email, for example, is entirely the corporation's. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IP-based reputation services vs. DNSBL (long)
Hallam-Baker, Phillip wrote:
> Agree with your conclusion but your statement is not quite accurate.
I know that. I had composed a footnote outlining split-routing in my
original email, but removed it because it would confuse the issue
precisely for the reasons you yourself outline below, without
invalidating anything I said.
Since you raise it, I'll elaborate.
You said:
> Some spammers have in fact developed schemes that involve spoofing the
> source IP address of TCP sessions, but only where both IP addresses were
> under spammer control.
. Precisely. Both IP addresses are
under spammer control, the listing still has precisely the desired
effect (blocking the undesirable email), and FPs are no more likely than
if the "alleged source" really was the true source.
Now if there were plausible circumstances where, say, infesting a real
MTA with split-routing malware was any more likely or preferable than
infesting a real MTA with non-split-routing spamware, it could be of
concern. But there isn't.
Split-routing requires very intimate and synchronous real-time
bidirectional communications between both IP addresses of the split. I
believe that most if not all implementations were where both IPs were on
the same machine, both IPs were "legitimately held" by the spammer (not
by infection). That scenario is no longer feasible at typical BOT volumes.
> I don't know if it is still widely used but when is was being used the
> disruption caused to the network was cosiderably higher than for normal
> spam as you can expect.
It is not widely used any longer. At best, the technique is of value in
very limited circumstances ("effectively free/super cheap accounts with
associated real IPs", eg: AOL "first month free" disks). Secondly, it
also requires there to be a more "valuable" asset (the true source, a
paid high bandwidth account) that the spammer is trying to protect.
With BOTs, there is no "paid high bandwidth account" to protect, or at
least, not by these means - all parts of the spam-sending exercise, and
much of the immediately visible portions of the web content delivery are
expendable (eg: domain tasting, expendible intermediate proxies, etc).
Secondly, the volumes that spammers need to send to get any return are
too high for this technique to be feasible.
At its height, a number of people noted that the only known mass-use of
this technique was via AOL. The CBL once listed over 20,000 AOL "ipt"
(end-user IPs) that were also outbound port 25 blocked by AOL. Yes,
there was some confusion (including that of AOL admin staff) of how this
was possible, but _not_ because it was interfering with legitimate email
- their non-spamming customers _couldn't_ send email that way anyway.
However, once they understood what the issue was, the fix (block inbound
port 25) was accomplished in very short order. If anything, the
juxtaposition of a CBL listing of the port 25-blocked AOL "split-end"
greatly speeded up resolution of the entire issue - certainly a
lot easier than whack-a-mole of thousands of individual accounts.
We've seen this situation a few times since then in a small way (none in
the last year or longer), but established practise is tending to
eliminate this as spammer-economy-viable (eg: see MAAWG Port 25
considerations document). In fact, I think the AOL experience is one of
the prompters of that document's existance.
Aside from unusual situations like AOL (back then), it is no longer a
useful technique for spammers to exert effort on, and even if it was,
the distinction is moot, because the effect/consequences of a DNSBL
listing of the back-haul of a split-routed connection is identical to a
non-split-route connection.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: several messages
I wouldn't ordinarily reply to this, but Dean makes a number of plausible pronouncements which simply aren't borne out in reality. I'm using this as an educational opportunity for those with insufficient experience in the field to make an informed judgement. Dean Anderson wrote: > I suggest people look at this document: > > http://tools.ietf.org/html/draft-church-dnsbl-harmful-01 That expired over two years ago, and rightfully so. It's filled with a great number of inaccuracies, including statistics that don't even remotely resemble effectiveness and false positive rates as seen by sites with typical mail flows. Not to mention assertions that are entirely at odds with virtually all operators of medium to very large environments. For example, the statistics of "BL3" (CBL) showing an effectiveness rate of 45% and a FP rate (against desired email) of over 2% in a very small sample set. If the CBL FP rate was even as high as .01%, we'd not touch it. Our email flow in production does as many emails as his entire test every few minutes, and the traps are peaking to that many emails per second. [I'm picking on the CBL because I've studied it for a long time. I'm studying it because it's doing an amazingly good job on our mail flow, and our experiences with it seem to be closely reflected by most other sites, including some of the very largest email infrastructures that exist.] Our effectiveness rate at catching _all_ spam exceeds 75% from the CBL alone, with a false positive rate in the 5-6 per million range. On the trap, it's above 90%. That is one of the lowest FP rates of any of the techniques (DNSBL or otherwise) in our arsenal, and is far away the highest effectiveness rate. The non-DNSBL heuristics tend to have worse FPs. In our production environment (300,000 valid emails per day), we have perhaps one false positive due to the CBL per day, and in virtually all cases the CBL is correct - we can see the spewage of spam and viruses from that IP in our own quarantine, it just happens to have one or two valid emails mixed in too. Which we fix (assist with eradicating the infection problem, and forward the intercepted valid email) and move on - no harm (no lost email, at worst delayed), and only good (fixed infection, less junk) accrues from our blocks. > Maybe you should do some math to show the response time of a DNSBL > compared to the re-ip time. Maybe I could, but I don't need to, because over the past 5 years our experience with the CBL (as just one example) indicates that any potential for very short re-ip times versus detection->publication time isn't a significant factor nor is likely to be anytime soon, hence the calculations are moot. >> Many ISPs force DHCP IP-affinity significantly, and it's kinda hard >> for most BOTs to force their cable modem/access router/whatever (which >> is the real holder of the DHCP address) to refresh. > > First, > > Second, > > Third, Our experience indicates that none of them are a significant factor in CBL effectiveness over the past 5 years, and there's no indication that they will become much more significant any time soon. > I'm sure some IPs do stay static for much longer, particularly when the > machine infected has a static ip address in a hosting facility. > > But your premise is limited to residential carriers offering cable or > dsl. What goes against your premise is the efforts by residential > carriers to disrupt server activities by keeping customers from having a > static ip address. Rotating the address faster natually disrupts P2P > services like bit-torrent, etc. So, I'm kind of puzzled that you don't > see this. Actually, that won't disrupt them, unless the forced re-ip rate is sufficiently high to interfere with "normal" desired traffic (like web surfing or email). Most of such tools (like bit-torrent) are inherently immune to re-ip'ing, except insofar as a re-ip might break a transfer mid-stream. Which breaks email and web transfers too, and an ISP's customers would get pretty mad about that. Re-ip'ing would only be a real barrier to those protocols that rely on being able to "call into a reasonably fixed IP" of, say, a torrent leaf node instead of "call out to an advertised muster point". We have 100% inbound blocking of all connection attempts on all protocols. Yet, bit-torrent works here. In other words, re-ip wouldn't stop torrent except by breaking connections mid-stream, which causes destructive interference to the very activity the ISP is contracted to supply to their customers. Residential carriers have a strong incentive to keep the same device on the same IP as long as possible, even across reboots/reconnects - allowing BOTs to re-ip very quickly lands their entire pool in DNSBLs like the CBL at best (worse is local mail admin-applied manual whole-range listings that probably never get reviewed), and worse greatly complicates analysis and remediation. In other words, how do you correlate an IP that's c
Re: several messages
der Mouse wrote: >> But DNSBLs can't solve the problem when spam is sent via botnets. > > That's actually true, but not for the reason you imply. DNSBLs can't > solve the problem _at all_; it's a social level problem and requires a > social level solution. Wnat DNSBLs do is mitigate the damage so that > we have at least middling-usable email while solutions evolve at the > social level. I should also point out that that his original reason (BOTs re-DHCP'ing themselves too quickly for DNSBLs to be effective) simply isn't borne out by experience. Many ISPs force DHCP IP-affinity significantly, and it's kinda hard for most BOTs to force their cable modem/access router/whatever (which is the real holder of the DHCP address) to refresh. But beyond that, it's our experience that most BOTs emit from the same IP for at least a day or two, and it's entirely common to see the same IP emitting from the same BOT for weeks and in some cases for 6 months or longer. Often multiple BOT types at the same time, emitting different campaigns. etc. We are using technology that detects many BOTs (eg: Srizbi, Storm, Cutwail etc) in real time - about 70% of all "infected PC" spam is identifiable in our implementation. The CBL is purported to target the same sorts of things. It's been our experience that if we had been forced to rely on the CBL alone and not our real-time detection, we'd "miss" at most 10% of the BOT spam (ignoring all other detection methods), and usually closer to 2-3%. That's an impressive success rate, and disproves any notion that DNSBLs are inherently too slow for BOTs. [Our sample size is on the order of 20M-50M emails per day. So I don't think we suffer from being too small to infer useful results from.] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IP-based reputation services vs. DNSBL (long)
TS Glassey wrote: > Matthias > Any DNS BL Listing process where those listings are based on complaints > would create this. [spoofed IPs in DNSBLs] Few DNSBL listing processes rely on "complaints" as you put it. Certainly, none of the popular ones use them extensively, and most refuse them. Eg: the CBL explicitly refuses contributions of complaints. Most DNSBL listing processes rely _only_ on the peer address of the connection (either direct, or by header insertion by their own trusted systems). No-one has yet come up with a spam-economy-practical mechanism for spoofing source IP in TCP/IP (SMTP) sessions. There has been much research on the topic, and it all seems to indicate that there isn't one. I'll refer you to papers by Steven Bellovin, Marcus Leech and others. [UDP packet source IPs are trivially forgeable. But you can't send email by UDP packets. TCP/IP source IP is forgeable, but only at extremely high effort levels - few spammers would be satisfied with a throughput rate of a few spams per week (at most) per bot that works only against some destinations, when the return rate is measured in the single digits per million spams. If TCP/IP source spoofing were to become a spammer-practical method, the Internet has vastly bigger problems than flakey email.] The two most effective DNSBLs of all (CBL & PBL, both part of Spamhaus Zen) don't look at headers at all. The former takes its IPs directly from the TCP/IP stack of the MTA receiving the email (eg: getpeername()), and the latter is a policy assertion, largely by the verified owner of the IP ranges in question. IP spoofing is effectively impossible in one, and irrelevant to the second. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Tony Finch wrote: > Note that anti-spam blacklists are distributed by more mechanisms than > just the DNS. Questions of listing policy apply whatever protocol is > used, so they shouldn't be addressed in a document that just describes > a DNS-based query protocol. I have a similar objection the proposal of a WG for "reputation lists". The problem it seems intended to solve is far broader than reputation lists, and is completely orthogonal to a reputation delivery protocol standard. The problems that people ascribe to reputation mechanisms are just as severe in virtually every other type of filtering method. Poorly chosen or implemented content filtering systems have exactly the same problems as poorly chosen or implemented DNSBLs, and have the same implications for "reliability of email". These are SMTP filter signaling protocol issues, and have nothing to do with filtering engine decision mechanisms. The real issue underlying this is standards and practises on how the decision making is implemented _at_ the filter itself. In other words, we need generalized principles of practise how filtering should be signaled through SMTP to enhance reliability, repeatability, and and the ability to identify/resolve problems. I've long been considering the draft of a BCP on how filters should operate. And have written bits and pieces of it in point form. Eg: rejects not bounces, SMTP codes, error texts, C/R, SAV, remediation channels etc. That doesn't belong in a DNSBL protocol specification. It would be entirely missed in a WG about "reputation". It's covered, in part, in the still-draft DNSBL BCP, insofar as they directly relate to details specific to DNSBLs. If a WG were chartered to explore ways to improve filter reliability/interoperability, eg: standardizing filter response mechanisms, I'd participate in that. But that has nothing whatsoever to do with DNSBL protocols - which is nothing more then a delivery mechanism for certain classes of information, the interpretation thereof the choice of who implements whatever uses it. [I use DNSBL protocols for far more than filtering decisions. It works really well to resolve IP addresses into ASNs, allocation ranges, ownership and geolocation information for example.] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Steven M. Bellovin wrote: > On Sun, 09 Nov 2008 23:40:43 -0500 > Tony Hansen <[EMAIL PROTECTED]> wrote: > In some sense, I have more trouble with white lists than black lists. > > My concern is centralization of power. If used properly, white lists > are fine. If used improperly, they're a way to form an email cartel, > forcing organizations to buy email transit from a member of the inner > circle. Hi Steven, long time... Sort of a protection racket. This only works insofar as the mail receivers (the ones who choose to deploy a whitelist) is willing to let them. Receivers are driven, first and foremost, by their users's complaint rates. Receivers will notice increased complaint rates from a whitelist like this, and begin to discount their input. As they also do with FP rates on the blacklists they use. We see that now in take-up rates of various DNSBL/DNSWLs. Much as, say, people realized that TrustE logos didn't mean very much. There's a much larger potential with proprietary reputation systems - the buy-in costs are high, so it eventually becomes impossible for new reputation vendors to get into the act, and receivers are reluctant to switch vendors because they have to put yet another proprietary thingie in their MTAs. [A few years ago, at a MAAWG session, I caused a bit of slack-jawed consternation when I strongly put forth the idea that reputation vendors had to move to open protocols if they wanted acceptance at more than a few of the very largest ISPs that could afford it. I'm glad to report that at least one or two have since seen the light.] In an standard protocol environment, startup costs are minimal, receivers find it very easy to switch or mix-and-match. Same goes with negative reputation. A standardized open protocol greatly reduces the likelyhood of cartelish behaviour. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Keith Moore wrote: > Livingood, Jason wrote: > >> Keith - I encourage you to consult with several very large scale email >> domains around the world to see if they think that DNSxBLs are useful, >> effective, and in widespread use or not. > > Jason - I encourage you to consult with users whose mail isn't getting > delivered, and see whether they think DNSBLs are useful and effective, > or whether their mail is effectively being bounced by third parties who > aren't accountable for their actions. DNSBL operators can and do get sued for their actions. Sometimes rightfully so. Further, accountability both for the block and its remediation, rests mostly with the admin who deploys the filters, whether it be something they've designed themselves, or choose to delegate to someone else (whether it be DNSBL, Brightmail filter downloads or A-V signature downloads etc). Which in our case is _me_. I don't get to blame others for _my_ choices. So, where's this accountability gap you keep talking about? I found out what our users thought of DNSBLs when I accidentally turned off DNSBL queries. We were flooded with hundreds of complaints about the spam. We get _far_ fewer complaints about false positives we have. So the real result of your suggestion is clear. You need to do what Jason suggests. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
John C Klensin wrote: > As a thought experiment, if Nortel or Comcast are developing > these lists and like them, are they willing to assume liability? One would _assume_ you mean "assume liability if we lost a lawsuit", rather than fork out money to anybody who sticks their hand out. Well, of course we do. We wouldn't be doing it if we didn't - we can't wave a magic wand and escape the law. We have MUCH bigger worries than legal liability like you're talking about here. Losing an important sale because of a filter mistake is a far more likely risk than getting sued. So, no lost legitimate email is the absolute overriding priority. Or, are you thinking that a whole new set of law needs to be created to cover the source IP-based version of filtering, and holds DNSBL operators to a higher standard than anyone else? Why? There have been many legal actions already. A few losses, but mostly wins. Note also: e360 vs Comcast. e360 sues Comcast for source-IP blocking them. Case thrown out on summary judgement. Comcast has absolute right to do it explicitly enshrined in the DMCA "hold harmless for good faith blocking of objectionable email" clause. This is probably extensible to the suppliers that ISPs use to do that blocking. Hence, DNSBLs are also immune as long as the plaintiff can't prove bad faith. That case is not entirely over yet, but the final result isn't going to be any different. Comcast's counter to the initial complaint is amazing reading. > If not, what does that say about the model? Legal theory around DNSBLs has already been partially established in case law. Your questions have already had their answers demonstrated in a way that only enhances the model. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-irtf-asrg-bcp-blacklists
John Leslie wrote: > Chris Lewis <[EMAIL PROTECTED]> wrote: >> ... This is why I, Matt Sergeant, and others have been working on >> a DNSBL policy BCP what could be considered a companion document: >> >> http://www.ietf.org/internet-drafts/draft-irtf-asrg-bcp-blacklists-04.txt >> >> I hope to make a few final grammatical changes to the above document in >> the next few days and move it on towards last call. >First, a meta-comment: > >I hope we don't try to make a class of documents called IRTF BCPs. > The intent behind this, I hope, is to work on it in IRTF's ASRG, then > submit it to the IESG as an Individual Sumbission. It's been through at least four iterations on the ASRG, so it already has been worked on there. Extensively. At this point, I want to make the latest revisions (with John L's and my "assigned document handler" or whatever that's called) and have discussions on that. The current BCP draft went through review at the last IETF, and from what I've heard from John Levine, received general acceptance with no significant objection. I have to review the comments and see if they need to be encorporated. My brief glance suggested at most a minor wording change. But there's a couple emails full of minor grammatical tweakage that I have to go through first too. I promised John I'll have r5 up Monday, but I might be a day or two late. I _think_ the "irtf" in the name is a historical accident on my part (I hadn't done this before) and no more - it being much more trouble than it's worth to change a document draft file name and screw up draft numbering. All that will be fixed by the approval/publication process. John can speak to the IRTF vs. ASRG vs. IETF BCP issue. >This is reasonably clearly stated. Whether there is any sort of IETF > consensus about the existence of "proper" use seems to be in question. The thrust of the document is around asserting that the only legitimate judge of "proper use" is the _user_ of the DNSBL, and establishing a framework of principles and guidelines by which the user can make informed choices. The fact that someone else might think there's no legitimate use has no bearing - it's not their mail server - they have no say in email acceptance policy. The BCP is pitched at a level to obviate most issues about, er, currency. It's a distillation of the principles people want to know/should know about/look for in DNSBLs they might think of using, captured over as long as there's been DNSBLs. The document was first started in 2003 (eeek) and has roots much longer ago than that. I don't think it'll obsolete much more quickly than DNSBLs themselves do. DNSBLs won't be going away anytime soon. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
John Levine wrote: >> Today, messages can just disappear on the way to the user's mailbox >> (often at or after that last-hop MTA). They do so without NDNs out >> of fear of blowback, and they do so for two main reasons. ... > You know, DNSBLs make mystery disappearances less likely, not more. > > The DNSBLs that most people use are typically checked at SMTP time, sp > MTAs can give a 5xx rejection using the TXT record from the DNSBL that > identifies why the mail was rejected. Indeed, and more concretely: NDNs aren't inherently bad (blowback). It's "accept then generate NDN" that's inherently bad. Anti-spam techniques that are after the destination's MX should not generate NDNs, because all of it is potentially blowback by definition. The "just disappear" argument more applies to techniques that can't NDN without blowback. Which, includes, for example, ALL client-side filtering no matter what filtering they use, and all server-based "accept-then-analyse" filtering. Not DNSBLs per-se. By far the most common server-based implementations using DNSBLs reject at SMTP time (usually with some sort of remediation information in the error message), which suppresses almost all blowback, yet "you" still find out what happened. In contrast, for example, the most common implementations of (say) content analysis do accept-then-analyse, and should not NDN because it'll be blowback. Full analysis during SMTP time of (say) content and rejecting at SMTP time is considerably rarer (we're one of the rarer ones). In part because older revisions of the SMTP standards weren't very clear about handling of rejections after DATA. We decided to ignore that limitation. In other words, in general you're far more likely to find out about your email not getting through (and how to fix it) if it was a DNSBL hit than most other techniques. It's not intrinsically inherent to DNSBLs, it's just the "overwhelming experience". >> Unlike you, I don't see "overwhelming community consensus for >> this mechanism". > > Aw, come on. There's a billion and a half mailboxes using the > Spamhaus DNSBLs, on systems ranging from giant ISPs down to hobbyist > Linux boxes. All of the very largest email and spam filtering infrastructures use DNSBLs (generally IP-based reputation lists) in one way or another, whether they tell you or not. I said "all" because I meant "all" - that's not hyperbole for "most". ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Keith Moore wrote: > John Levine wrote: > >>> Unlike you, I don't see "overwhelming community consensus for >>> this mechanism". >> Aw, come on. There's a billion and a half mailboxes using the >> Spamhaus DNSBLs, on systems ranging from giant ISPs down to hobbyist >> Linux boxes. > > and there's a billion and a half users whose email is being degraded by > such mechanisms. > > if you ask them whether they want to not receive spam, they'll say yes. > if you ask them whether they want their incoming mail filtered on the > basis of unsubstantiated rumor and unreliable identifiers, they'll say no. Then you go to the next logical step, and turn Spamhaus off, and you ask them whether they want it back on. They'll say yes. They did here (the question was an accidental goof on my part that turned off Spamhaus queries, the answer (trouble tickets about spam filtering not working, despite all the other filtering mechanisms unaffected by the goof) was overwhelming) Secondly, the term "unsubstantiated rumor" - that implies that Spamhaus accepts unsubstantiated allegations from anyone. They don't. "Unsubstantiated rumor" - unsubstantiated by whom? Represented how? I'd contend that Spamhaus's listings are all substantiated by them, but no matter. PSBL, for example, substantiates every listing with a spam sample via their web site. CBL (Spamhaus XBL) entries are substantiated by SMTP transactions from the IP in question, usually with specific identification of the spambot that did it. They may not reveal precise details of their heuristics of how they detected it, nor a sample, but experience indicates that they are right virtually 100% of the time. I don't need 100% full transparency or 100% substantiation, if experience shows I can trust it. And I do. Those that represent 1 1/2 billion mail accounts trust it too. This is also that false dichotomy again: just because a DNSBL might issue "unsubstantiated rumor" doesn't mean that they ALL necessarily do. "Some A does B" != "All A does B". Indeed, I would contend that to most people, the appearance of Miriam Abacha (that will trigger some non-DNSBL-based filters) as being spam sign is unsubstantiated rumor. But that is the basis for other filtering methods. One might reply that the IETF should not standardize the insides of those methods. But who cares? They don't need consistent inter-machine protocols. DNSBLs do. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Keith Moore wrote: > I think you're missing the point. Oh, no, I fully understand the point. In contrast, I think you're relying on false dichotomies. For example: > Better "interoperation" of a facility that degrades the reliability of > email, by encouraging an increased reliance on dubious filtering > criteria and rumors, is not a desirable goal. There is no such thing as a filtering mechanism that is 100% accurate, and hence all are dubious to one degree or another. Every technique relies upon factors that are based on intuition and experience, rather than physical law. A demonstrable assertion that "IP x is demonstrably infected with Srizbi and anything it emits is probably crap" and communicated by DNS is much less dubious than "this combination of random content fragments makes it look like a Nigerian 419, sorta, marginally". Indeed, experience shows that a correctly chosen set of DNSBLs is often not only more effective than other techniques in correctly identifying malicious email, can often have far fewer false positives than just about any other mechanism. It certainly is counterintuitive that "source reputation" might be more accurate than "per email evaluation". But, experience in the field demonstrates the true reality - the current state of the art is that intelligently chosen DNSBLs (the aforementioned BCP is intended to help that) often work much better than complete reliance on the latter. Furthermore, incorrect DNSBL listings are easier to cope with than, say, random combinations of SpamAssassin scores that just happen to zap a desirable email. This is not specific to SA. It's just as applicable to other things like Bayesian. We run DNSBLs and SpamAssassin here on the MXes. The former catches 10 times as much as the latter, FPs less, and is a lot easier to explain and remediate than the latter. We _hate_ SA FPs, because it's so much more difficult to ensure that it doesn't repeat. [The obvious Bayesian/SA remediation (whitelisting email addresses) isn't good enough. Virtually all malicious email is forged. Thus, whitelisting senders leaves you wide open to getting zapped by forgeries.] > Even assuming that there's some benefit in having third-party reputation > services (which IMHO is not well-established), Again, a false dichotomy: DNSBLs are not necessarily third-party, and other perfectly reputable techniques (eg: outsourcing your spam filtering to a spam filtering company or relying on your ISPs filtering) are third party by definition. Indeed, running your own copy of SpamAssassin on your own mail box is just as much giving away "control" of your filtering to a third party with their own evaluations techniques of greater or lesser dubiousness. Is it not third party because you can tweak the rules of SA? You can also locally whitelist around DNSBL entries. The only way you can get away from "third party" is to write your own filters from scratch, and ignore everybody else's heuristics. I generate several DNSBLs for use here only. Why shouldn't there be a standard so that mail server software I buy/lease/license will interoperate with DNSBLs I create? "Not well-established"? You don't seem to have any idea how prevalent the use of DNSBLs is. It's probably the industry's dirty little secret because of the occasional media event. But there have been similar media events about other filtering techniques that aren't 3rd party, nor source reputation. The reality is: almost everybody uses DNSBLs, and ALL of the very big sites do. > use of DNS to communicate > such reputation, and basing such reputation on IP addresses, is itself > very dubious. You may think it dubious, but it is usually more reliable and effective than any other, and its popularity alone means it needs to be standardized. Rejecting the standardization of DNSBL protocols because the entries of a specific DNSBL _might_ be dubious is in itself a dubious position. > The problem isn't just the rumor passing mechanism, but > the mechanism is indeed part of the problem. > > It's not as if we're arguing about whether to standardize a facility > that is widely believed to work well. It is widely believed to work well. That's part of the point. > We're arguing about whether to > standardize a facility that causes problems for everyone. No more so than filtering in general. > Back when I started working with email, getting a message reliably > delivered was something of a black art, because you had to know how to > thread your message through the hodgepodge of Internet, uucp, BITNET, > DECnet, fidonet, and whatnot. That was in some sense understandable > because Internet access was not widely available, and there wasn't > really any common network that everybody could tap into. > > Today, getting a message reliably delivered is once again a black art. > But today, it's not for lack of standards or network connectivity. It's > because so many messages are filtered for dubious reasons, or on
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
As the architect of a large email infrastructure, a senior technical advisor to the Mail Anti-Abuse Working Group, and ASRG member, I find myself disagreeing with the points made by John and Keith that I included at the end. As a consumer (and producer) of DNSBLs, I need technical standards that define DNSBL protocol so I can spec/build/acquire/use software that interoperates correctly and maintains/improves the reliability of our email and email in general. I also want policy predictability in the DNSBLs I use or am likely to encounter when our users send email, but that does not belong in a DNSBL technical standard on protocols. It belongs in a different document. More below. Yes, the very existence of DNSBLs is unfortunate, but they have become an outright necessity for many mail systems. Our (and many other, including all of very largest) mail infrastructures heavily rely on DNSBLs for the majority of their filtering. No other filtering technique deals as effectively with the massive floods of spam and other malicious content that we receive (in some cases well in excess of 90% of all email). Yes, some people honestly believe that the use of DNSBLs for blocking is a bad idea. But those objections fall away when they're used in aggregate scoring systems like SpamAssassin, where they're just one minor factor of many. DNSBLs need to be standardized, whether they block an email, tweak a score a bit like SpamAssassin, or as in some environments, improve an email's likelihood of getting through (eg: whitelists). There are many advanced non-DNSBL techniques that can and do work well in place of DNSBLs on small to medium systems. Unfortunately, they are either considerably less ineffective or are impractical in large to very large systems trying to withstand the full spectrum of email abuse that they have to deal with daily. DNSBLs (locally sourced or otherwise) often make the difference between email remaining useable or becoming unuseable in environments like ours. It is but one tool of many tools. Yet, for many infrastructures, by far the most effective. Virtually every major email system uses DNSBLs in one way or another, whether it's visible or not, whether it's used directly by themselves, or in concert with other mechanisms (eg: scoring). Failing to standardize the technical protocols used by them would be a major mistake. More specific points: 1) There are no technical omissions in the specification that I am aware of. It is a technical specification of the bits on the wire (the protocol), with little else. 2) I presume the "technical omissions" comment was intended to mean a lack of standardization of "how things got on and off DNSBLs". These are not, and should not, be considered technical issues. Specifying how something got on and off a DNSBL would be equivalent to insisting that RFC2822 attempt to standardize how mail readers insert an email address in the To header. RFC2822 specifies the format of To headers, not how they got there. Yes, there are issues about such things, and consistency in some of these areas is desired. But, they do not belong in a technical standard. This is why I, Matt Sergeant, and others have been working on a DNSBL policy BCP what could be considered a companion document: http://www.ietf.org/internet-drafts/draft-irtf-asrg-bcp-blacklists-04.txt I hope to make a few final grammatical changes to the above document in the next few days and move it on towards last call. 3) Making draft-irtf-asrg-dnsbl a standard (and ultimately approving the BCP) serves to improve the consistency and interoperability of DNSBLs, and therefore email itself. Not making it a standard only perpetuates uncertainty on the protocol itself, failure to implement software that interoperates correctly, unpredictable (and some times capricious) failure modes, and ultimately impairs the reliability of email. Case in point: If a DNSBL domain becomes unregistered, and is picked up by a reseller, they usually insert DNS A record wildcards causing web queries to go to a common web page. Or if a DNSBL domain is mispelled by its users, it may collide with a different domain that wildcards A records. Such scenarios aren't rare, they happen frequently. Without this standardization, the implementors of DNSBL clients don't realize that DNSBL queries that return A records outside of 127/8 is an error condition not a positive result. Such mail servers usually end up blocking ALL of their email - concrete examples of where lack of standardization drastically impairs email interoperability. John C Klensin wrote: > Sadly, I have to agree with Keith. While these lists are a > fact of life today, and I would favor an informational document > or document that simply describes how they work and the issues > they raise, standardizing them and formally recommending their > use is not desirable at least without some major changes in our > email model and standards for what gets addresses on
Re: [Asrg] SHEESH!
Vernon Schryver wrote: From: "Chris Lewis" <[EMAIL PROTECTED]> Vernon wrote: I think they should also use the DCC to reject all bulk mail, but that's probably only my bias speaking. That's a _much_ better idea than banning specific character sets or mime. Maybe so or maybe not. Using the DCC to reject all bulk mail would prune a lot of conference announcements and calls for papers. I think that would be a good thing, but I know others disagree with me. Not _inbound_ to the IETF. Only if they spammed it, got DCC reports, and then forwarded to the IETF would it get blocked. Which is what you want, no?
Re: [Asrg] SHEESH!
Vernon Schryver wrote: From: "Chris Lewis" <[EMAIL PROTECTED]> I guess I shouldn't have used the V-word when talking about spam on the IRTF's mailing list about spam. sheesh!--talk about utterly lame and misguided spam filters. But in the case of the V word, it works. ... I wonder if you'd say that if your employer were in the drug industry. Of course not. So? I'd simply not deploy such a filter. Until the IETF has WGs on pharmaceuticals, I don't think we need to worry about the IETF's filtering in this regard. IETF mailing lists are particularly prone to high volumes of spam. I for one am particularly glad that they're moving to filters. Takes a _huge_ load of end-user complaints off _my_ head, as well as those of my colleagues running IETF mailing lists of their own. There are other things the IETF lists should do instead. To start, they should rejectm mail with MIME content headers declaring mail is not English, and specifically reject JP, KR, and GB character sets. The IETF has no foreign language special interest groups? Like on character sets and internationalization? It would be as dumb as a pharmaceutical company banning the V word. They should probably also reject any MIME multipart mail, That would annoy the Mime, multimedia and other specialized WGs would it not? I think they should also use the DCC to reject all bulk mail, but that's probably only my bias speaking. That's a _much_ better idea than banning specific character sets or mime.
Re: [Asrg] SHEESH!
Vernon Schryver wrote: I guess I shouldn't have used the V-word when talking about spam on the IRTF's mailing list about spam. sheesh!--talk about utterly lame and misguided spam filters. But in the case of the V word, it works. The only concern I'd have is whether the rejection message implies that it's far more unnecessarily draconian on other words/phrases. 8+ months of blocking on it, 10's of thousands of rejects, approximately 4 false positives. 5 if Vern had gotten it thru the mailing list. Better than a .01% FP rate. Not bad. IETF mailing lists are particularly prone to high volumes of spam. I for one am particularly glad that they're moving to filters. Takes a _huge_ load of end-user complaints off _my_ head, as well as those of my colleagues running IETF mailing lists of their own. Speaking of which, I should whitelist [EMAIL PROTECTED]
