Re: The internet architecture
On Sat, Dec 06, 2008 at 09:33:36PM +0900, Masataka Ohta <[EMAIL PROTECTED]> wrote a message of 16 lines which said: > The problem to represent a host with raw addresses is that they > can't represent a host with multiple addresses, OK > supporting of which is useful and often required, for example, for > DNS and SMTP clients. "Required"? Neither DNS nor SMTP requires that. I'm not even sure it is good practice. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The internet architecture
On Sat, Dec 06, 2008 at 08:03:45AM +0100, Marc Manthey <[EMAIL PROTECTED]> wrote a message of 87 lines which said: > On Linux (at least on Debian), you need the mDNSResponder package > provided by Apple on the Bonjour downloads page. Unfortunately, > Avahi doesn't yet implement all of the API functions UIA needs. And it is a proprietary protocol, anyway. The IETF protocol on that field is LLMNR (RFC 4795). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The internet architecture
On Fri, Dec 05, 2008 at 12:46:58PM -0500, Andrew Sullivan <[EMAIL PROTECTED]> wrote a message of 39 lines which said: > It seems to me true, from experience and from anecdote, that DNS out > at endpoints has all manner of failure modes that have little to do > with the protocol and a lot to do with decisions that implementers > and operators made, either on purpose or by accident. Indeed, in one of his messages, Keith Moore listed many "problems with DNS" that were completely different in their origin. Almsot none were protocol-related, most were operational but some were not even linked to DNS operations, they were layer 8 and 9 issues (such as the registrar transfer problem in ICANNland) and completely offtopic for the IETF. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The internet architecture
On Mon, Dec 08, 2008 at 11:25:02AM +0100, Marc Manthey <[EMAIL PROTECTED]> wrote a message of 54 lines which said: >> And it is a proprietary protocol, anyway. > > who told you that ? Please tell me what open standard (IETF, ITU, what you want) defines it. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Friday experiment
John C Klensin wrote: While I would favor more enforcement of those rules, I'm not personally convinced that this is enough of a problem by itself and fixing it would make a lot of difference. However, in practice, late agendas are either a problem or they are not a problem. If they are not a problem, we should stop pretending that they are. If they are a problem, then the AD granting the exception, or the entire IESG, should be held accountable by the community for encouraging the problems to occur. We really can't have it both ways, and neither can the WGs or the IESG. ... Indeed. In the past, I had to plan travel, and it least in one case a WG agenda wasn't ready when I needed to decide about how long to stay, so I decided not to attend the meeting. So it has been a problem for me at least one :-). BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The internet architecture
Stephane Bortzmeyer wrote: >>The problem to represent a host with raw addresses is that they >>can't represent a host with multiple addresses, > OK >>supporting of which is useful and often required, for example, for >>DNS and SMTP clients. > "Required"? Neither DNS nor SMTP requires that. I'm not even sure it > is good practice. If an SMTP or DNS server has multiple addresses, clients are required, practically (many servers are behind firewalls) or, for DNS, officially by RFC1035, to try all the IP addresses of the server, which is a form of an applicatin layer end to end multihoming. That DNS is an intelligent intermediate system is blessing rather than a curse, because it enables many to many mapping between hostnames and IP addresses, which is essensial for end to end multihoming to reduce the number of the global routing table entries. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The internet architecture
On Mon, Dec 08, 2008 at 09:06:54PM +0900, Masataka Ohta <[EMAIL PROTECTED]> wrote a message of 25 lines which said: > If an SMTP or DNS server has multiple addresses, clients are > required, practically (many servers are behind firewalls) or, for > DNS, officially by RFC1035, to try all the IP addresses of the > server, Yes, SMTP requires to try all the IP addresses of the MX. But I thought you said that it was required for a MX to have several addresses, which is quite different. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The internet architecture
Am 08.12.2008 um 10:11 schrieb Stephane Bortzmeyer: On Sat, Dec 06, 2008 at 08:03:45AM +0100, Marc Manthey <[EMAIL PROTECTED]> wrote a message of 87 lines which said: On Linux (at least on Debian), you need the mDNSResponder package provided by Apple on the Bonjour downloads page. Unfortunately, Avahi doesn't yet implement all of the API functions UIA needs. And it is a proprietary protocol, anyway. who told you that ? http://www.ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00087.html some references http://files.dns-sd.org/draft-cheshire-dnsext-nbp.txt http://files.dns-sd.org/draft-sekar-dns-llq.txt http://files.dns-sd.org/draft-sekar-dns-ul.txt http://files.dns-sd.org/draft-cheshire-nat-pmp.txt Marc -- Les Enfants Terribles - WWW.LET.DE Marc Manthey 50672 Köln - Germany Hildeboldplatz 1a Tel.:0049-221-3558032 Mobil:0049-1577-3329231 mail: [EMAIL PROTECTED] PGP/GnuPG: 0x1ac02f3296b12b4d jabber :[EMAIL PROTECTED] IRC: #opencu freenode.net twitter: http://twitter.com/macbroadcast web: http://www.let.de Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNS query reliability (was Re: The internet architecture)
On Sat, Dec 06, 2008 at 06:23:02AM -0800, Dave CROCKER <[EMAIL PROTECTED]> wrote a message of 37 lines which said: > One could imagine producing a BCP about common DNS implementation and > operation errors or, more positively, recommendations for implementation > and operation. > > One could equally imagine some group actively pursuing improvements to > the major implementations (and operations) that have problems. > > I seem to recall seeing small forays in this direction, in the past. Indeed, there are many efforts to improve the DNS usage. In IETFland, there are RFC 1912, 2182, 4472, 4641, 5358 and many Internet-Drafts. Outside IETF, there are efforts such as http://www.zonecheck.fr/";>registries like AFNIC that require a successful technical test of the name servers before every delegation ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The internet architecture
On Mon, Dec 08, 2008 at 10:37:36AM +0100, Stephane Bortzmeyer wrote: > DNS" that were completely different in their origin. Almsot none were > protocol-related, most were operational but some were not even linked > to DNS operations, they were layer 8 and 9 issues (such as the > registrar transfer problem in ICANNland) and completely offtopic for > the IETF. Well, to the extent that the real-world application of the protocol -- even several layers up -- turns out to be more difficult than simple reading of the protocol specification would suggest, we have a problem that is _not_ off-topic for the IETF. That problem is how to make this very flexible protocol safe for use in the network that actually exists. There is a tendency among those of us who are familiar with DNS to say, "Well, that's not what you're supposed to do," when we hear the horror stories people have about DNS problems. But if we really want people to use names instead of addresses all the time, then we need to ask ourselves why, in spite of the built-in resilience of DNS, relying on DNS often makes an application less resilient. If the explanation turns out to be exclusively things like the layer 8 and 9 issues you're talking about, then let's work on fixing them (or come up with a tech fix to route around that damage). I suspect, however, that we'll find ambiguities in the specifications that make certain kinds of implementations hard. We should fix that, too (and dnsext is trying). A -- Andrew Sullivan [EMAIL PROTECTED] Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The internet architecture
Andrew Sullivan wrote: we need to ask ourselves why, in spite of the built-in resilience of DNS, relying on DNS often makes an application less resilient. If the explanation turns out to be exclusively things like the layer 8 and 9 issues you're talking about, then let's work on fixing them (or come up with a tech fix to route around that damage). I suspect, however, that we'll find ambiguities in the specifications that make certain kinds of implementations hard. We should fix that, too (and dnsext is trying). Andrew, An easy reaction to your note is "yes, of course you are correct", but it might be worth a small amount of additional consideration: This is an infrastructure service that has demonstrated a long history of utility and a long history of problems. Some of the problems have more impact than others. I'm not sure there is any consensus about which ones, but trying to do a rough rand-ordering could focus effort to be more efficient (and more useful.) What we have been missing is any sort of systematic consideration of those problems. Which are major and which are minor (for some definitions of major and minor)? Where should community effort be put, to make substantial improvements in DNS utility? There is the usual danger of fragmented effort, with uncoordinated, local optimizations that ultimately do not have the desired benefit. I take your note as highlighting the potential disparity between the DNS reality seen by experts, versus the DNS reality seen in the larger and less expert wild. Besides motivating analysis of what is wrong, we need to apply that perspective at a systemic level to the effort at making improvements, so that fixes by experts result in real, systems-level improvements. In all likelihood, the biggest impact on DNS reliability will turn out to come from relatively straightforward changes in administration and operation. But there does not seem to be all that much effort in this direction and it seems likely that a well-placed and well-touted BCP -- and perhaps some tools to test for conformance to it -- could help more than a protocol improvement... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Review of draft-ietf-nfsv4-pnfs-block-10
Christian,
Thank you for doing this review.
On the volume identification offset:
> - Section 2.2.1 ("Volume Identification") specifies two methods for
>identifying a position on a disk: by positive offset starting at
the
>beginning of the disk, and by negative offset starting at the end
of
>the disk. The second method is limited to implementations where
>server and client have the same understanding of the disk size.
This
>method could be generalized: If you defined an offset, positive or
>negative, to be in the context of the disk size as seen by the
>client, then you may potentially also support implementations where
>server and clients have a different understanding of the disk size.
>The authors may consider this.
I would prefer not to do this. It's fairly easy to make a mistake in
this environment that has the client looking in the wrong place for
the volume identification, risking a false positive, and unpleasant
results. Beyond this, removing the requirement that server and client
have the same understanding of the disk size may create situations
in which different clients have different ideas of the disk size; that
seems like needless complexity, so all clients need to have the same
understanding of disk size, and adding the server to that understanding
is a small and reasonable step in pursuit of robustness.
As Hannes has already pointed out, there's quite a bit of crash
detection and recovery material in the main NFSv4.1 draft, including
descriptions of how to recover layouts in general (layouts are among
the resources that a client can reclaim during a grace period after
server restart). Hence this draft only adds material specific to
the block/volume layout. We'll add a sentence or two in order to
explain this and point to the material in the main NFSv4.1 draft.
We'll expand the first uses of the four acronyms.
Thanks,
--David
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
[EMAIL PROTECTED]Mobile: +1 (978) 394-7754
> -Original Message-
> From: Christian Vogt [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 04, 2008 7:42 AM
> To: IETF Discussion Mailing List
> Cc: Black, David; fridella, stephen; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Review of draft-ietf-nfsv4-pnfs-block-10
>
> I was asked by the IESG to review the "pNFS Block/Volume Layout"
> specification [draft-ietf-nfsv4-pnfs-block-10], and I am sharing my
> review on this list. The specification is overall in good shape and
> should proceed for publication soon. I do suggest addressing the
> following comments, though, before forwarding the document to the RFC
> Editor.
>
> Technical:
>
> - Section 2.2.1 ("Volume Identification") specifies two methods for
>identifying a position on a disk: by positive offset starting at
the
>beginning of the disk, and by negative offset starting at the end
of
>the disk. The second method is limited to implementations where
>server and client have the same understanding of the disk size.
This
>method could be generalized: If you defined an offset, positive or
>negative, to be in the context of the disk size as seen by the
>client, then you may potentially also support implementations where
>server and clients have a different understanding of the disk size.
>The authors may consider this.
>
> - Section 2.4 ("Crash Recovery Issues") specifies recovery procedures
>that a client could initiate following a server crash. These
>procedures apply in one specific condition, which is defined at the
>beginning of the section ("When the server crashes while the client
>holds a writable layout, and the client has written data to blocks
>covered by the layout, and the blocks are still in the
>PNFS_BLOCK_INVALID_DATA state, [then]..."). The section should
also
>consider other conditions. It may be sufficient to explain why
only
>the described condition requires recovery.
>
> - Section 2.4 ("Crash Recovery Issues") does not explain how a client
>detects a server crash. The section should briefly explain this.
It
>may be sufficient to mention that crash detection is specified in a
>related document, or that it is implementation-specific.
>
> Editorial:
>
> - The specification uses undefined acronyms in a couple of places,
>including in the title. Those should be spelled out when mentioned
>the first time. Search for "pNFS", "SAN", "XDR", "LUN" to find the
>relevant places in the specification.
>
> Best regards,
> - Christian
>
>
>
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: secdir review of draft-raj-dhc-tftp-addr-option-04
I find the claim that attacks are easier to do with "VoIP
Configuration Server Address" than the "TFTP Server Name" to be pretty
dubious. All the devices I am aware of that use either option also get
the DNS server from DHCP. If I can attack the DHCP response, I can
probably get a DNS server running on the network and point the device
at the alternative DNS server. If one is more secure than the other,
it's not by much.
That said, I think this security discussion is going the wrong
direction. What is common practice, and what I think this should
suggest, is that DHCP can be spoofed in some cases. The correct thing
to do is to secure the object that is retrieved via tftp. One do
things such as make sure it is signed such that the phone can verify
it contains authorized data from correct source and if it contains any
private data, like SIP passwords, that it is encrypted. There are
ways to mitigate DHCP spoofing but discussion of those is outside
scope of this draft.
Suggesting the Auth option is a total non starter in every case I am
aware of where this is used because the important thing is for this
scheme to work when a new phone arrives without the administrator
having to take the phone out of the box and enter a credential on the
phone - the operational expense of something like this is just too
high. Multiple manufactures resolve this by including factory
installed public/private key pairs and certificates that bind the
serial number of the phone and making sure the serial number of the
phone is on a bar code on the outside of the box. The admin can then
barcode scan the box, associate it with a given user, print a label
for that user, ship the phone to that user, and when the user boots
it, provide user specific data for the phone as well as replace the
manufacture certificates with ones where the manufacture is not in the
trust chain. Similar things are done for residential voice where the
user enters the serial number of the phone and their credit care on
the service providers web site and the service provider never has to
touch the phone. They can ship from distributors to end users with no
intermediate provisioning steps. One of the uses of this is firmload
upgrades and many vendors have existing methods to check that code is
appropriately signed.
Many phones from more vendors than just Cisco support variants of the
above. The key things is that one can, and many do, implement secure
systems even in environments where tftp is not secure.
Cullen, in my IETF participant role
PS. I am not aware of a single device that implements or uses this
option that does not implement DNS. Certainly there are devices that I
am not aware of but does anyone else have an example of one? A more
relevant concern might be that you want the phones to get their
configuration from a differnt server than the diskless sun
workstations and a separate option makes this a bit easier.
On Dec 3, 2008, at 4:29 AM, Ralph Droms (rdroms) wrote:
Jari - I agree that mentioning security issues, pointing to the
Security Considerations in RFC 2131 and citing RFC 3118, is
appropriate.
Responding to Richard...
On Dec 2, 2008, at Dec 2, 2008,5:35 PM, Richard Johnson wrote:
> Ok, maybe I'm not understanding what's being suggested or maybe I'm
> simply reading the existing text in a different way. Here's the
> contents of the draft's "Security Considerations" section:
>
>> A rogue DHCP Server could use this option in order to coerce a
>> Client
>> into downloading configuration from an alternate Configuration
>> Server
>> and thus gain control of the device's configuration. This is
more
>> easily done with the VoIP Configuration Server Address option
>> than it
>> was with the "TFTP Server Name" option, because in the latter
case
>> the attack would need to control DNS responses as well as
inserting
>> the rogue DHCP option information. If this is a concern, then
>> either
>> DHCP Authentication may be used, or the "TFTP Server Name" option
>> may
>> be used instead.
>>
>> Message authentication in DHCP for intradomain use where the out-
>> of-
>> band exchange of a shared secret is feasible is defined in
>> [RFC3118].
>> Potential exposures to attack are discussed in section 7 of the
>> DHCP
>> protocol specification in [RFC2131].
>>
>> Other out-of-band methods of verifying the validity of the VoIP
>> Configuration Server Address, such as certificates of trust,
>> could be
>> used to mitigate some security concerns.
>
> So, it only mentions option 66 ("TFTP Server Name" option) by
> comparison and in order to point out the relative levels of security
> involved. It has no "suggestion to use option 66".
>
> The text already has an "explanation about why the use of this
> option without authentication might be problematic". As a matter of
> fact, it seems rather explicit on the matter.
I sugges
Re: [secdir] secdir review of draft-raj-dhc-tftp-addr-option-04
--On Sunday, December 07, 2008 12:18:37 PM -0700 Cullen Jennings <[EMAIL PROTECTED]> wrote: I find the claim that attacks are easier to do with "VoIP Configuration Server Address" than the "TFTP Server Name" to be pretty dubious. Me too. That said, I think this security discussion is going the wrong direction. What is common practice, and what I think this should suggest, is that DHCP can be spoofed in some cases. The correct thing to do is to secure the object that is retrieved via tftp. I'm inclined to agree with this, in principle. In practice, that requires either preconfiguration, which sort of defeats the point of using DHCP, or a closed system like firmware updates signed by a device manufacturer, where not only the network but also the user and DHCP server operator are untrusted. If we're talking about an option which will only ever be used to tell phones where to download new firmware, then this is fine. If we're talking about an option which will be used by network operators to provide configuration to phones (in order to avoid manual configuration), or in general to provide a TFTP server address for whatever is the next step in the boot process, then "secure the object" sounds like good advice but IMHO is less practical than "configure your network to prevent DHCP spoofing". There are ways to mitigate DHCP spoofing but discussion of those is outside scope of this draft. I agree that discussion of how to mitigate DHCP spoofing is out of scope. However, I think recommending that operators do so is appropriate. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Review of draft-ietf-nfsv4-pnfs-block-10
Hi David - I would prefer not to do this. It's fairly easy to make a mistake in this environment that has the client looking in the wrong place for the volume identification, risking a false positive, and unpleasant results. Beyond this, removing the requirement that server and client have the same understanding of the disk size may create situations in which different clients have different ideas of the disk size; that seems like needless complexity, so all clients need to have the same understanding of disk size, and adding the server to that understanding is a small and reasonable step in pursuit of robustness. I don't have a strong opinion on whether you add full support for negative disk offsets despite potential implementation difficulties, or whether you prohibit such support in order to avoid implementation bugs. Personally, I would go for the former option -- and add text that warns about related implementation challenges. But I won't complain if you choose the latter option, of course. As Hannes has already pointed out, there's quite a bit of crash detection and recovery material in the main NFSv4.1 draft, including descriptions of how to recover layouts in general (layouts are among the resources that a client can reclaim during a grace period after server restart). Hence this draft only adds material specific to the block/volume layout. We'll add a sentence or two in order to explain this and point to the material in the main NFSv4.1 draft. Right, a reference to the document that contains the necessary background information is all that's necessary here. We'll expand the first uses of the four acronyms. Perfect. - Christian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
How I deal with (false positive) IP-address blacklists...
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 --- Begin Message --- Hi there. Your mailer appears to have my one of the addressed used by primary mailhub, 69.25.196.31 (it reverse-resolves to www.church-of-our-saviour.org.). Its primary ip address and hostname is thunk.org, 69.25.196.29. You can see who I am here: http://thunk.org/tytso If you use any amount of Linux on your systems, I am the first North American Linux Kernel developer, and the maintainer of e2fsprogs, the filesystem utilities for ext2/ext3/ext4. This bounce took place because I replied to some user who apparently has a mailbox on gondor.apana.org.au, on the Linux Kernel Mailing List. The way I see things, I provde *way* more services to your users than you do to me, so I don't see any reason to place an international phone call to get my IP address un-blacklisted. If one of your users or one of your staff members needs my help to fix a Linux kernel problem, or to unscramble an ext2/3/4 filesystem, or an invite to the some future Linux Kernel Summit, and they can't receive my e-mail, that is *your* problem, not mine. I've arranged to make sure this gets routed via an mit.edu mailhub, but that's about all I plan to do to resolve this problem. Your move. Best regards, Theodore Y. Ts'o Linux Foundation Fellow and Chief Platform Strategist STSM, IBM Linux Technology Center Medford, Massachusetts (617) 245-5616 (781) 391-2699 (fax) (781) 526-0121 (cell) --- Begin Message --- This message was created automatically by mail delivery software. A message that you sent has not yet been delivered to one or more of its recipients after more than 24 hours on the queue on thunker.thunk.org. The message identifier is: 1L9Ulw-0001Yz-O5 The date of the message is:Sun, 7 Dec 2008 20:18:51 -0500 The subject of the message is: Re: Runaway loop with the current git. The address to which the message has not yet been delivered is: [EMAIL PROTECTED] 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. No action is required on your part. Delivery attempts will continue for some time, and this warning may be repeated at intervals if the message remains undelivered. Eventually the mail delivery software will give up, and when that happens, the message will be returned to you. --- End Message --- --- End Message --- ___ 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
