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
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 wor
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 ma
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
d
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 f
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'
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.
>
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-black
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 c
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
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 wa
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 p
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:
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
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 peo
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
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
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 re
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 spa
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
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 fro
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 badne
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 in
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
> operat
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
> o
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 usi
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 liste
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 (dr
28 matches
Mail list logo
