Comcast's new email-blocking policy
Philip J. Koenig
Comcast seems to have gotten increasingly draconian in their
email blocking policies as of late. Apparently many people
are now seeing a message of the sort included below when
sending email to accounts @comcast.net:
> ----- The following addresses had permanent fatal errors -----
> <some...@comcast.net>
>
> ----- Transcript of session follows -----
> ... while talking to gateway-s.comcast.net
> >>> MAIL From:<some...@example.com>
> <<< 550 Comcast does not support the direct connection to
> its mail servers from residential IPs. Your mail should be
> sent to comcast.net users through your ISP. Please contact
> your ISP or mail administrator for more information.
Apparently in what I have seen in some usenet discussions, it
is a great big mystery how Comcast determines what is a
"residential" address and what is not. Apparently this is not
based on SPF records or some sort of RBL list like the old
MAPS/Kelkea "DUL" - it seems it is another sad case of "shoot
first and ask questions later".
Does anyone have specific experience with this blocking and
perhaps have a relatively direct contact address/phone for
someone at Comcast to gripe at, or at the very least, get
whitelisted?
--
* Few people are capable of expressing with equanimity opinions which *
* differ from the prejudices of their social environment. Most people are *
* even incapable of forming such opinions. -- Albert Einstein *
* *
* To send email, remove numbers and spaces: pjkusenet64 @ ekahuna27 . com *
* Simple answers are for simple minds. Try a new way of looking at things. *
DMF
>> ----- The following addresses had permanent fatal errors -----
>> <some...@comcast.net>
>>
>> ----- Transcript of session follows -----
>> ... while talking to gateway-s.comcast.net
>> >>> MAIL From:<some...@example.com>
>> <<< 550 Comcast does not support the direct connection to
>> its mail servers from residential IPs. Your mail should be
>> sent to comcast.net users through your ISP. Please contact
>> your ISP or mail administrator for more information.
Its not clear to me what useage would generate this reply.
If I am a residential user (presumably not on comcast) I
would be using the SMTP server native to the network
that I am on... under what circumstance would I directly
connect to Comcast mail servers to send mail unless I was
a Comcast user? TIA.
Regards,
David
Philip J. Koenig
9dnZ4...@inreach.com>, DMF writes...
Email servers (otherwise known as "MTAs" or "MX's) connect
to each other to transfer email. If you are a Yahoo end-
user sending an email to someone at Comcast, you relay email
through Yahoo's MTA, which then relays it to Comcast's MTA.
The problem is that the site in question runs their own
mail server (MTA), and Comcast now thinks that their MTA
is "rogue" because (in their sole determination it resides
in "residential address space". (it doesn't) What makes
matters worse is Comcast apparently will not publicly divulge
exactly how they come to such a determination.
There is an issue with the reverse DNS hostname for the
IP in question, which may "appear" to Comcast as being
"residential", but once again these sorts of methods,
as can be seen in this example, often run the risk of
throwing out legitimate email by being over-zealous.
The site in question has been sending to Comcast for a long
time using that IP, the only thing that has changed recently
is Comcast's policy. Going to see if changing the DNS PTR
record has any positive effect. I certainly don't have
much affinity for these "shoot first and ask questions
later" sorts of system administration policies, where
someone decides to block your email traffic for some
proprietary reason that they won't publicly reveal, and
forces you to go to them to get whitelisted after discovering
some number of messages were returned undelivered.
John Navas
In <MPG.1eadce426...@News.Individual.Net> on Mon, 17 Apr 2006
17:10:13 -0700, Philip J. Koenig <See_email_@ddress_below.This_one_is.invalid>
wrote:
>Comcast seems to have gotten increasingly draconian in their
>email blocking policies as of late. Apparently many people
>are now seeing a message of the sort included below when
>sending email to accounts @comcast.net:
>
>> ----- The following addresses had permanent fatal errors -----
>> <some...@comcast.net>
>>
>> ----- Transcript of session follows -----
>> ... while talking to gateway-s.comcast.net
>> >>> MAIL From:<some...@example.com>
>> <<< 550 Comcast does not support the direct connection to
>> its mail servers from residential IPs. Your mail should be
>> sent to comcast.net users through your ISP. Please contact
>> your ISP or mail administrator for more information.
>
>Apparently in what I have seen in some usenet discussions, it
>is a great big mystery how Comcast determines what is a
>"residential" address and what is not. Apparently this is not
>based on SPF records or some sort of RBL list like the old
>MAPS/Kelkea "DUL" - it seems it is another sad case of "shoot
>first and ask questions later".
>
>Does anyone have specific experience with this blocking and
>perhaps have a relatively direct contact address/phone for
>someone at Comcast to gripe at, or at the very least, get
>whitelisted?
I've not seen this particular problem, but I nonetheless urge everyone I know
on Comcast to switch to a decent email service (like GMail).
--
Best regards,
John Navas <http://NavasGroup.com/>
JC Dill
<See_email_@ddress_below.This_one_is.invalid> wrote:
>Apparently in what I have seen in some usenet discussions, it
>is a great big mystery how Comcast determines what is a
>"residential" address and what is not. Apparently this is not
>based on SPF records or some sort of RBL list like the old
>MAPS/Kelkea "DUL"
Does the IP of the mail server appear in any of these DUL lists:
<http://wiki.openrbl.org/wiki/Category:DUL>
Does the IP of the mail server have a reverse DNS that is just the IP
address, perhaps in reverse notation, or does it have reverse DNS that
indicates it's not a dynamic allocated IP?
jc
--
"The nice thing about a mare is you get to ride a lot
of different horses without having to own that many."
~ Eileen Morgan of The Mare's Nest, PA
John Navas
In <4bni42hnaurgb69de...@4ax.com> on Fri, 21 Apr 2006 15:40:56
-0700, JC Dill <jcd...@gmail.com> wrote:
>On Mon, 17 Apr 2006 17:10:13 -0700, Philip J. Koenig
><See_email_@ddress_below.This_one_is.invalid> wrote:
>
>>Apparently in what I have seen in some usenet discussions, it
>>is a great big mystery how Comcast determines what is a
>>"residential" address and what is not. Apparently this is not
>>based on SPF records or some sort of RBL list like the old
>>MAPS/Kelkea "DUL"
>
>Does the IP of the mail server appear in any of these DUL lists:
>
><http://wiki.openrbl.org/wiki/Category:DUL>
>
>Does the IP of the mail server have a reverse DNS that is just the IP
>address, perhaps in reverse notation, or does it have reverse DNS that
>indicates it's not a dynamic allocated IP?
None of which are at all meaningful (except to out-of-control self-appointed
anit-spam missionaries).
Philip J. Koenig
<4bni42hnaurgb69de...@4ax.com>, JC Dill writes...
> On Mon, 17 Apr 2006 17:10:13 -0700, Philip J. Koenig
> <See_email_@ddress_below.This_one_is.invalid> wrote:
>
> >Apparently in what I have seen in some usenet discussions, it
> >is a great big mystery how Comcast determines what is a
> >"residential" address and what is not. Apparently this is not
> >based on SPF records or some sort of RBL list like the old
> >MAPS/Kelkea "DUL"
>
> Does the IP of the mail server appear in any of these DUL lists:
>
> <http://wiki.openrbl.org/wiki/Category:DUL>
>
> Does the IP of the mail server have a reverse DNS that is just the IP
> address, perhaps in reverse notation, or does it have reverse DNS that
> indicates it's not a dynamic allocated IP?
Apparently Comcast is using a simplistic set of rules
to parse the PTR record, and apparently if it contains
(as in this case) a string "dsl", they assume it's a
"residential" or "dynamic" address. (despite the fact
that this particular connection is T-1 class symmetric
1.5 Mbps SDSL, which very few residences use, in part
because it typically costs 20 times what they would
otherwise pay for garden-variety ADSL)
Pretty stupid tactic, but luckily in this case the fix (after
getting some input and making a guess about what it was that
Comcast was doing) was easy by changing the PTR record. Too
bad so much legitimate traffic will get caught in the crossfire
as people once again are forced to adapt to silly ISP email
blocking tactics. (why Comcast can't use a much more tried-
and-true method like the old MAPS DUL, which only contains IP
address space submitted by ISPs as _truly_ dynamic or
residential) is beyond me.
FYI, the hostname in the PTR record that Comcast didn't like
was in the following format:
111-222-333-444.dsl.[isp].net
John Navas
In <MPG.1eb7936df...@News.Individual.Net> on Tue, 25 Apr 2006
03:01:51 -0700, Philip J. Koenig <See_email_@ddress_below.This_one_is.invalid>
wrote:
>...Too
>bad so much legitimate traffic will get caught in the crossfire
>as people once again are forced to adapt to silly ISP email
>blocking tactics. (why Comcast can't use a much more tried-
>and-true method like the old MAPS DUL, which only contains IP
>address space submitted by ISPs as _truly_ dynamic or
>residential) is beyond me.
Perhaps because that list isn't terribly good.
Javier
Are you suggesting that non dynamic/residential addresses are listed in
the MAPS' DUL?
-jav
John Navas
In <e2ljvr$1pdk$1...@stationair.kjsl.com> on Tue, 25 Apr 2006 12:51:23 -0400,
Javier <jav...@invalid.invalid> wrote:
In a word, yes. Also that many aren't.
JC Dill
<See_email_@ddress_below.This_one_is.invalid> wrote:
>Apparently Comcast is using a simplistic set of rules
>to parse the PTR record, and apparently if it contains
>(as in this case) a string "dsl", they assume it's a
>"residential" or "dynamic" address.
This is not uncommon.
>(despite the fact
>that this particular connection is T-1 class symmetric
>1.5 Mbps SDSL, which very few residences use, in part
>because it typically costs 20 times what they would
>otherwise pay for garden-variety ADSL)
They had no way to know which of the addresses in this block were
ordinary DSL addresses (which should never send email "direct-to-MX")
and which weren't.
>Pretty stupid tactic, but luckily in this case the fix (after
>getting some input and making a guess about what it was that
>Comcast was doing) was easy by changing the PTR record.
Bingo.
> Too
>bad so much legitimate traffic will get caught in the crossfire
Very little legitimate email will get caught by this type of
filtering.
Most people who have DSL lines either aren't sending email directly
but rather using their ISPs mail server, or they have enough clue to
change the PTR record to indicate that this is an IP address used by
someone with clue, and thus legitimately configured with a mail
server.
>as people once again are forced to adapt to silly ISP email
>blocking tactics. (why Comcast can't use a much more tried-
>and-true method like the old MAPS DUL, which only contains IP
>address space submitted by ISPs as _truly_ dynamic or
>residential) is beyond me.
Because those lists are not comprehensive enough. Too many DSL IPs
aren't being voluntarily entered by the ISPs. so other ISPs resort to
making educated guesses so that they can have more complete IP blocks.
*Usually* these additional blocks are generated by looking at the IPs
that actually send spam.
>FYI, the hostname in the PTR record that Comcast didn't like
>was in the following format:
>
>111-222-333-444.dsl.[isp].net
The order of events probably went something like this:
A) Use the MAPS DUL.
B) Examine the spam that evades the DUL filter. Look at the IP
address of any computer sending "direct-to-MX".
C) Notice much spam spewing from IPs with PTR records that look like:
111-222-333-444.dsl.[isp].net
D) Add filter for IP addresses that fit that rule
E) Block lots of additional spam (spewing from trojan compromised
computers on DSL lines).
F) Get rare complaints that legitimate email is being blocked.
Explain to legitimate DSL mail server admins that they need to change
the PTR on their IP so that it can be differentiated from their less
clueful (and often trojan infected) IP block neighbors who have no
business sending direct-to-MX email.
Comcast apparently didn't do a very good job on step F, but I'm sure
their own customers are very happy about the good job Comcast is doing
on steps A-E.
Javier
Can you provide a list of non dyn/home addresses that are listed in DUL?
I will then forward it to the appropriate party.
Thanks.
-jav
John Navas
In <ooqs42ppqlch3khs7...@4ax.com> on Tue, 25 Apr 2006 11:54:38
-0700, JC Dill <jcd...@gmail.com> wrote:
>A) Use the MAPS DUL.
>
>B) Examine the spam that evades the DUL filter. Look at the IP
>address of any computer sending "direct-to-MX".
>
>C) Notice much spam spewing from IPs with PTR records that look like:
>
> 111-222-333-444.dsl.[isp].net
>
>D) Add filter for IP addresses that fit that rule
>
>E) Block lots of additional spam (spewing from trojan compromised
>computers on DSL lines).
>
>F) Get rare complaints that legitimate email is being blocked.
>Explain to legitimate DSL mail server admins that they need to change
>the PTR on their IP so that it can be differentiated from their less
>clueful (and often trojan infected) IP block neighbors who have no
>business sending direct-to-MX email.
>
>Comcast apparently didn't do a very good job on step F, but I'm sure
>their own customers are very happy about the good job Comcast is doing
>on steps A-E.
Actually not. Lots of spam still gets through, and too many legitimate mails
don't. The apparent problem is that Comcast is satisfied with "good enough"
rather than "high quality". I've switched a number of unhappy Comcast
customers to better mail services (e.g., Google Mail).
John Navas
In <e2lruc$1rqi$1...@stationair.kjsl.com> on Tue, 25 Apr 2006 15:07:08 -0400,
Javier <jav...@invalid.invalid> wrote:
>Can you provide a list of non dyn/home addresses that are listed in DUL?
>I will then forward it to the appropriate party.
Sorry, but I have neither the time nor the interest to get involved that kind
of pointless exercise.
Philip J. Koenig
news.ops.worldnet.att.net>, John Navas writes...
I can believe that a lot of residential/dynamic addresses
are not in there because the owners of the address space
didn't bother to submit them to the operators of the DUL.
But the other allegation is not as easy to believe. What
makes you think this?
Certainly that list is probably 100 times less likely to
generate false-positives than Comcast's really dumb
practice of making guesses based on a PTR record.
Javier
> [POSTED TO ba.internet - REPLY ON USENET PLEASE]
>
> In <e2lruc$1rqi$1...@stationair.kjsl.com> on Tue, 25 Apr 2006 15:07:08 -0400,
> Javier <jav...@invalid.invalid> wrote:
>
>> Can you provide a list of non dyn/home addresses that are listed in DUL?
>> I will then forward it to the appropriate party.
>
> Sorry, but I have neither the time nor the interest to get involved that kind
> of pointless exercise.
It wouldn't have been pointless, had you provided the data it would've
been sent to the right person who would've followed up and added the
addresses to the DUL.
I'm now left to believe that you made an assertion without data to back
it up.
-jav
John Navas
In <e2lsmh$1s4v$1...@stationair.kjsl.com> on Tue, 25 Apr 2006 15:20:02 -0400,
Javier <jav...@invalid.invalid> wrote:
>John Navas wrote:
>>
>> In <e2lruc$1rqi$1...@stationair.kjsl.com> on Tue, 25 Apr 2006 15:07:08 -0400,
>> Javier <jav...@invalid.invalid> wrote:
>>
>>> Can you provide a list of non dyn/home addresses that are listed in DUL?
>>> I will then forward it to the appropriate party.
>>
>> Sorry, but I have neither the time nor the interest to get involved that kind
>> of pointless exercise.
>
>It wouldn't have been pointless, had you provided the data it would've
>been sent to the right person who would've followed up and added the
>addresses to the DUL.
I disagree. As I've explained a number of times in the past, I think the DUL
as it currently exists is a pointless exercise in general, and fixing only
some of the entries, which would still take a considerable amount of time and
effort, isn't going to change that even if the input would have been taken
seriously, which I doubt.
>I'm now left to believe that you made an assertion without data to back
>it up.
I think that's both childish and unwarranted, but you are of course welcome to
take whatever leap you want.
John Navas
In <MPG.1eb8150aa...@News.Individual.Net> on Tue, 25 Apr 2006
12:14:58 -0700, Philip J. Koenig <See_email_@ddress_below.This_one_is.invalid>
wrote:
>On Tue, 25 Apr 2006 18:45:27 GMT, in article <b7u3g.1261$xX5.713@bgtnsc05-
>news.ops.worldnet.att.net>, John Navas writes...
>
>> In <e2ljvr$1pdk$1...@stationair.kjsl.com> on Tue, 25 Apr 2006 12:51:23 -0400,
>> Javier <jav...@invalid.invalid> wrote:
>>
>> >John Navas wrote:
>> >>
>> >> In <MPG.1eb7936df...@News.Individual.Net> on Tue, 25 Apr 2006
>> >> 03:01:51 -0700, Philip J. Koenig <See_email_@ddress_below.This_one_is.invalid>
>> >> wrote:
>> >>
>> >>> ...Too
>> >>> bad so much legitimate traffic will get caught in the crossfire
>> >>> as people once again are forced to adapt to silly ISP email
>> >>> blocking tactics. (why Comcast can't use a much more tried-
>> >>> and-true method like the old MAPS DUL, which only contains IP
>> >>> address space submitted by ISPs as _truly_ dynamic or
>> >>> residential) is beyond me.
>> >>
>> >> Perhaps because that list isn't terribly good.
>> >
>> >Are you suggesting that non dynamic/residential addresses are listed in
>> >the MAPS' DUL?
>>
>> In a word, yes. Also that many aren't.
>
>I can believe that a lot of residential/dynamic addresses
>are not in there because the owners of the address space
>didn't bother to submit them to the operators of the DUL.
>But the other allegation is not as easy to believe. What
>makes you think this?
Bounced mail.
>Certainly that list is probably 100 times less likely to
>generate false-positives than Comcast's really dumb
>practice of making guesses based on a PTR record.
Perhaps, but that's not enough to make it a good system.
Philip J. Koenig
<ooqs42ppqlch3khs7...@4ax.com>, JC Dill writes...
> On Tue, 25 Apr 2006 03:01:51 -0700, Philip J. Koenig
> <See_email_@ddress_below.This_one_is.invalid> wrote:
>
> >Apparently Comcast is using a simplistic set of rules
> >to parse the PTR record, and apparently if it contains
> >(as in this case) a string "dsl", they assume it's a
> >"residential" or "dynamic" address.
>
> This is not uncommon.
It might be common, but it's still pretty dumb. You
can have extremely effective anti-spam measures without
resorting to that sort of nonsense.
> >(despite the fact
> >that this particular connection is T-1 class symmetric
> >1.5 Mbps SDSL, which very few residences use, in part
> >because it typically costs 20 times what they would
> >otherwise pay for garden-variety ADSL)
>
> They had no way to know which of the addresses in this block were
> ordinary DSL addresses
There are plenty of ways of knowing. (if they were so inclined)
It just isn't as trivial and quick as they would like so that
it can be done during an SMTP handshake the way they would
prefer.
I would also like to know what definition you are using for
"ordinary DSL address".
> (which should never send email "direct-to-MX")
Says who? I've been doing so for probably at least 5 years
now, and before that over ISDN. Methinks someone is thinking
more than a bit too simplistically here.
> and which weren't.
>
> >Pretty stupid tactic, but luckily in this case the fix (after
> >getting some input and making a guess about what it was that
> >Comcast was doing) was easy by changing the PTR record.
>
> Bingo.
Nothing like burdening the victim with the fix.
> > Too
> >bad so much legitimate traffic will get caught in the crossfire
>
> Very little legitimate email will get caught by this type of
> filtering.
I have a very hard time believing that. What's more, I also know
for a fact that you do not have to resort to such tactics to have
a superbly accurate antispam system. It really comes down to, in
my opinion, laziness and cost on the part of those who use such
tactics.
> Most people who have DSL lines either aren't sending email directly
> but rather using their ISPs mail server, or they have enough clue to
> change the PTR record to indicate that this is an IP address used by
> someone with clue, and thus legitimately configured with a mail
> server.
Up until a few weeks ago, the definition of "clue" in regards to
at least one particularly large US ISP changed dramatically. I
don't see anywhere in the RFC's where operators of MX hosts are
admonished not to ever allow a PTR record for an MX to contain
a string resembling "dsl". If you know otherwise, please advise.
> >as people once again are forced to adapt to silly ISP email
> >blocking tactics. (why Comcast can't use a much more tried-
> >and-true method like the old MAPS DUL, which only contains IP
> >address space submitted by ISPs as _truly_ dynamic or
> >residential) is beyond me.
>
> Because those lists are not comprehensive enough. Too many DSL IPs
> aren't being voluntarily entered by the ISPs. so other ISPs resort to
> making educated guesses so that they can have more complete IP blocks.
Translation: they want a quick, easy and cheap system. (they
probably also don't want to pay for the usage of the DUL either.
What a surprise.)
> *Usually* these additional blocks are generated by looking at the IPs
> that actually send spam.
For some reason that doesn't sound particularly plausible in this
case.
> >FYI, the hostname in the PTR record that Comcast didn't like
> >was in the following format:
> >
> >111-222-333-444.dsl.[isp].net
>
> The order of events probably went something like this:
>
> A) Use the MAPS DUL.
>
> B) Examine the spam that evades the DUL filter. Look at the IP
> address of any computer sending "direct-to-MX".
>
> C) Notice much spam spewing from IPs with PTR records that look like:
>
> 111-222-333-444.dsl.[isp].net
>
> D) Add filter for IP addresses that fit that rule
>
> E) Block lots of additional spam (spewing from trojan compromised
> computers on DSL lines).
>
> F) Get rare complaints that legitimate email is being blocked.
> Explain to legitimate DSL mail server admins that they need to change
> the PTR on their IP so that it can be differentiated from their less
> clueful (and often trojan infected) IP block neighbors who have no
> business sending direct-to-MX email.
>
> Comcast apparently didn't do a very good job on step F, but I'm sure
> their own customers are very happy about the good job Comcast is doing
> on steps A-E.
A lot of people are pretty desperate these days to block
junkmail, and a lot of Comcast's customers aren't particularly
sophisticated internet users, so those factors contributing
to Comcast's customers being "happy" about their status-quo
doesn't exactly represent a particularly compelling argument
for what they're doing.
Another fun fact: guess which network is the largest global
source of zombie-originated spam? Comcast.
http://tqmcube.com/zombies.php
Javier
> [POSTED TO ba.internet - REPLY ON USENET PLEASE]
>
> In <e2lsmh$1s4v$1...@stationair.kjsl.com> on Tue, 25 Apr 2006 15:20:02 -0400,
> Javier <jav...@invalid.invalid> wrote:
>
>> John Navas wrote:
>>> In <e2lruc$1rqi$1...@stationair.kjsl.com> on Tue, 25 Apr 2006 15:07:08 -0400,
>>> Javier <jav...@invalid.invalid> wrote:
>>>
>>>> Can you provide a list of non dyn/home addresses that are listed in DUL?
>>>> I will then forward it to the appropriate party.
>>> Sorry, but I have neither the time nor the interest to get involved that kind
>>> of pointless exercise.
>> It wouldn't have been pointless, had you provided the data it would've
>> been sent to the right person who would've followed up and added the
>> addresses to the DUL.
>
> I disagree. As I've explained a number of times in the past, I think the DUL
> as it currently exists is a pointless exercise in general, and fixing only
> some of the entries, which would still take a considerable amount of time and
> effort, isn't going to change that even if the input would have been taken
> seriously, which I doubt.
What evidence do you have that it wouldn't have been taken seriously?
And when you say considerable time and effort, do you mean on your part?
I'm assuming you already have the evidence of incorrectly bounced email
due to the wrong addresses being listed in the DUL, do you have to pull
backups, or do you have the evidence readily available? If so, just post
the relevant bits here.
>> I'm now left to believe that you made an assertion without data to back
>> it up.
>
> I think that's both childish and unwarranted, but you are of course welcome to
> take whatever leap you want.
It isn't a leap, John. Provide the data, and it will go to the right
folks. Otherwise, what am I left to believe?
-jav
Rahul Dhesi
>(why Comcast can't use a much more tried-
>and-true method like the old MAPS DUL, which only contains IP
>address space submitted by ISPs as _truly_ dynamic or
>residential) is beyond me.
There are several lists of dial-up IP blocks, and I doubt that any of
them is complete.
ISPs who truly care about making it easy for others to block their
dynamic IP space have already proposed, and adopted, a standard PTR
naming scheme. Then a single pattern match against something like
*.DYNAMIC-IP.*
suffices and no DNS traffic, or repeated updates of a text list, will be
needed.
But since this has not happened, Comcast is presumably resorting to an
ad hoc list. See, for example:
http://www.jammconsulting.com/jamm/dnsbl.jsp
Anybody who REALLY objects to such ad hoc strategies (as opposed to
merely wanting to waste time on Usenet) should take the lead and propose
an Internet naming standard for PTR records for dynamic IP blocks, and
persuade ISPs to adopt the standard. I predict an uphill battle, but
you might end up with your name on an RFC of historic importance.
--
Rahul
John Navas
In <e2luat$1tmn$1...@stationair.kjsl.com> on Tue, 25 Apr 2006 15:47:57 -0400,
Javier <jav...@invalid.invalid> wrote:
>John Navas wrote:
>> I disagree. As I've explained a number of times in the past, I think the DUL
>> as it currently exists is a pointless exercise in general, and fixing only
>> some of the entries, which would still take a considerable amount of time and
>> effort, isn't going to change that even if the input would have been taken
>> seriously, which I doubt.
>
>What evidence do you have that it wouldn't have been taken seriously?
Prior experience with MAPS.
>And when you say considerable time and effort, do you mean on your part?
Yes.
>I'm assuming you already have the evidence of incorrectly bounced email
>due to the wrong addresses being listed in the DUL, do you have to pull
>backups, or do you have the evidence readily available?
I would have to go back and search records, which might well involve archives
and/or backups. The bigger problem is that the exercise would be pointless.
My relatively small number of examples isn't enough to do any real good in the
overall context, certainly not enough to justify the time and effort, a bit
like trying to shovel off somebody else's driveway with a teaspoon.
>If so, just post
>the relevant bits here.
Even if I had it handy, I wouldn't do that, in part because it would be a
breach of privacy.
>>> I'm now left to believe that you made an assertion without data to back
>>> it up.
>>
>> I think that's both childish and unwarranted, but you are of course welcome to
>> take whatever leap you want.
>
>It isn't a leap, John. Provide the data, and it will go to the right
>folks. Otherwise, what am I left to believe?
Whatever you wish.
Javier
>> the relevant bits here.
>
> Even if I had it handy, I wouldn't do that, in part because it would be a
> breach of privacy.
Relevant bits, as in the IP address that you believe to be
dialup/dynamic/home use. How is that a breach of privacy?
-jav
John Navas
In <e2m9mh$231s$1...@stationair.kjsl.com> on Tue, 25 Apr 2006 19:00:33 -0400,
Javier <jav...@invalid.invalid> wrote:
If you really don't now see how that is a privacy issue, I doubt that anything
I could say would change your mind. ;)
Javier
Please do explain how posting an IP address, and nothing else but an IP
address, is a breach of privacy?
-jav
John Navas
In <e2mkju$26an$1...@stationair.kjsl.com> on Tue, 25 Apr 2006 22:06:54 -0400,
Javier <jav...@invalid.invalid> wrote:
>John Navas wrote:
>>
>> In <e2m9mh$231s$1...@stationair.kjsl.com> on Tue, 25 Apr 2006 19:00:33 -0400,
>> Javier <jav...@invalid.invalid> wrote:
>>
>>>>> If so, just post
>>>>> the relevant bits here.
>>>> Even if I had it handy, I wouldn't do that, in part because it would be a
>>>> breach of privacy.
>>> Relevant bits, as in the IP address that you believe to be
>>> dialup/dynamic/home use. How is that a breach of privacy?
>>
>> If you really don't now see how that is a privacy issue, I doubt that anything
>> I could say would change your mind. ;)
>
>Please do explain how posting an IP address, and nothing else but an IP
>address, is a breach of privacy?
Surely you know that it can be possible to match/trace an IP address back to
the person using it and/or personally identifying data, but then again maybe
not. Many of my clients expect me to maintain the strictest anonymity (for
good reason).
ka...@sonic.net
<spamf...@navasgroup.com> wrote:
<usual net pomposity deleted so as not to insult the intelligence of
regulars>
>Even if I had it handy, I wouldn't do that, in part because it would be a
>breach of privacy.
Ahh, the old privacy canard. I thought you'd forgotten it
since you used it over a year ago to avoid backing up equally
meaningless claims.
You're sooo easy.
John Navas
In <oi4u42pbip0cusvla...@4ax.com> on Tue, 25 Apr 2006 23:28:04
-0700, ka...@sonic.net wrote:
> You're sooo easy.
You're sooo predictable. And childish. Have a nice day.
Philip J. Koenig
in article <jJu3g.1360$xX5...@bgtnsc05-news.ops.worldnet.att.net>,
spamf...@navasgroup.com (John Navas) writes...
That would imply that someone using the DUL has blacklisted
an IP that appears in the DUL. Presumably that IP is running
an MTA. There are 2 issues here:
1) Since the DUL only uses address-space submitted to it by
the owners of the address-space, the fault for the inaccuracy
is likely to be the owner of that address-space, if they
mistakenly submitted it. (unless you are asserting poor
database-administration on the part of MAPS/Kelkea/Trend
Micro, which is not nearly as plausible to me) Thus this
leans toward suggesting that the blocked sender really has
an issue with their own ISP.
2) The entity at the receiving end using the DUL has chosen
to do so, and the beef on that side is with the operator
of the destination MTA. There could be a *slight* chance
that they have a technical problem which mistakenly blocks
IPs that are not actually on the DUL, but once again the
issue here is with those who run the destination MTA.
> >Certainly that list is probably 100 times less likely to
> >generate false-positives than Comcast's really dumb
> >practice of making guesses based on a PTR record.
>
> Perhaps, but that's not enough to make it a good system.
I would agree that using only the DUL as a spam-mitigation
system would not only create a certain degree of false-
positives, it would also not likely do a very good job
of blocking spam overall.
If however it was simply used as part of an overall spam
scoring system (ie as just one moderately-weighted input
to a spam-assassin-type system), then it might be useful.
Certainly far more useful than Comcast's "PTR beauty
contest" system.
Philip J. Koenig
in article <e2m29f$7n7$1...@blue.rahul.net>,
c.c....@XReXXComca.usenet.us.com (Rahul Dhesi) writes...
> Philip J. Koenig <See_email_@ddress_below.This_one_is.invalid> writes:
>
> >(why Comcast can't use a much more tried-
> >and-true method like the old MAPS DUL, which only contains IP
> >address space submitted by ISPs as _truly_ dynamic or
> >residential) is beyond me.
>
> There are several lists of dial-up IP blocks, and I doubt that any of
> them is complete.
I know this.
> ISPs who truly care about making it easy for others to block their
> dynamic IP space have already proposed, and adopted, a standard PTR
> naming scheme. Then a single pattern match against something like
>
> *.DYNAMIC-IP.*
>
> suffices and no DNS traffic, or repeated updates of a text list, will be
> needed.
"Something like" or "exactly like"? Where is this ad-hoc
"standard" published?
> But since this has not happened, Comcast is presumably resorting to an
> ad hoc list.
I would consider anything "ad-hoc" (including the example above)
if it is not codified in RFCs.
> See, for example:
>
> http://www.jammconsulting.com/jamm/dnsbl.jsp
Talk about low-standards, just look at the list of
countries (and even entire continents!) that those
people block in their entirety:
Carribean Islands
Central America
China
Hong Kong
Korea
Mexico
Japan
Russia and the former Soviet republics
Singapore
South America
Taiwan
Thailand
Vietnam
Impressive! I wonder if they have any bridges they
want to sell?
Getting back to specifics, those PTR pattern-matching lists
suffer from the same problems of all such lists, which is
that they are never completely accurate, and sometimes
wildly inaccurate.
> Anybody who REALLY objects to such ad hoc strategies (as opposed to
> merely wanting to waste time on Usenet)
To address your comment about wasting time, my starting this
thread has been very useful to me because partly due to
responses here and partly due to my research elsewhere, I was
able to quickly resolve the problem in a "reasonably satisfactory"
way. (despite having received initially bad advice from the
customer's ISP)
I hope that others have similiarly benefitted since by all
indications this new Comcast policy has had some strong
impacts, and since Comcast apparently will not reveal
any specifics, we are left to educate ourselves and/or
reverse-engineer their tactics without their help.
> should take the lead and propose an Internet naming
> standard for PTR records for dynamic IP blocks, and
> persuade ISPs to adopt the standard. I predict an
> uphill battle, but you might end up with your name
> on an RFC of historic importance.
I would never be that person because I have consistently
opposed blocking email traffic via such mistake-prone
methods, particularly when they are part of an insidious
creeping movement to blacklist application after application
from innocent users, essentially punishing the victims
without making the kinds of real changes that will truly
address the problem of easily-exploitable technologies.
Guess you'll have to do it yourself Rahul.
Rahul Dhesi
>> ISPs who truly care about making it easy for others to block their
>> dynamic IP space have already proposed, and adopted, a standard PTR
>> naming scheme....
>"Something like" or "exactly like"? Where is this ad-hoc
>"standard" published?
The answer was in the very next sentence that you quoted:
>> But since this has not happened...
--
Rahul
Javier
Gee whiz. I'd forgotten about the special range of IP addresses reserved
for Those People.
Let me guess... those highly anonymous clients of yours have one in the
range... hang on... let me think... somewhere between 0.0.0.0 and
255.255.255.255?
Oh my gosh, I hope I didn't breach anyone's security.
-jav
John Navas
In <e2nkjs$2g45$1...@stationair.kjsl.com> on Wed, 26 Apr 2006 07:14:22 -0400,
Javier <jav...@invalid.invalid> wrote:
>John Navas wrote:
>> Surely you know that it can be possible to match/trace an IP address back to
>> the person using it and/or personally identifying data, but then again maybe
>> not. Many of my clients expect me to maintain the strictest anonymity (for
>> good reason).
>
>Gee whiz. I'd forgotten about the special range of IP addresses reserved
>for Those People.
>
>Let me guess... those highly anonymous clients of yours have one in the
>range... hang on... let me think... somewhere between 0.0.0.0 and
>255.255.255.255?
>
>Oh my gosh, I hope I didn't breach anyone's security.
There's that politeness again. Or do you think polite is a synonym for
sarcastic?
The IP addresses of these MTAs might indeed reveal information about these
clients. If you really don't know that, then you have much less knowledge of
security than I've been giving you credit for. And it's not up to me in any
event -- I'd have to first get permission from the affected clients. Since
I see no value in the exercise, particularly for them, it's unlikely that I'd
get that permission. Thus it's a non-started, even if I had the time and
interest, which I don't.
Feel free to have the last word on this -- I'm done.
John Navas
In <MPG.1eb8c86c9...@corp.supernews.com> on Wed, 26 Apr 2006
01:00:20 -0700, Philip J. Koenig <See_email_@ddress_below.This_one_is.invalid>
wrote:
>On Tue, 25 Apr 2006 19:26:07 GMT,
>in article <jJu3g.1360$xX5...@bgtnsc05-news.ops.worldnet.att.net>,
>spamf...@navasgroup.com (John Navas) writes...
>> Bounced mail.
>
>That would imply that someone using the DUL has blacklisted
>an IP that appears in the DUL. Presumably that IP is running
>an MTA. There are 2 issues here:
>
>1) Since the DUL only uses address-space submitted to it by
> the owners of the address-space, ...
Not in my experience.
>2) The entity at the receiving end using the DUL has chosen
> to do so, and the beef on that side is with the operator
> of the destination MTA. ...
I disagree.
Javier
> [POSTED TO ba.internet - REPLY ON USENET PLEASE]
>
> In <e2nkjs$2g45$1...@stationair.kjsl.com> on Wed, 26 Apr 2006 07:14:22 -0400,
> Javier <jav...@invalid.invalid> wrote:
>
>> John Navas wrote:
>
>>> Surely you know that it can be possible to match/trace an IP address back to
>>> the person using it and/or personally identifying data, but then again maybe
>>> not. Many of my clients expect me to maintain the strictest anonymity (for
>>> good reason).
>> Gee whiz. I'd forgotten about the special range of IP addresses reserved
>> for Those People.
>>
>> Let me guess... those highly anonymous clients of yours have one in the
>> range... hang on... let me think... somewhere between 0.0.0.0 and
>> 255.255.255.255?
>>
>> Oh my gosh, I hope I didn't breach anyone's security.
>
> There's that politeness again. Or do you think polite is a synonym for
> sarcastic?
I was being sarcastic because I felt it was warranted.
> Feel free to have the last word on this -- I'm done.
I doubt it.
-jav
Philip J. Koenig
in article <JNM3g.48113$az4....@bgtnsc04-news.ops.worldnet.att.net>,
> In <MPG.1eb8c86c9...@corp.supernews.com> on Wed, 26 Apr 2006
> 01:00:20 -0700, Philip J. Koenig <See_email_@ddress_below.This_one_is.invalid>
> wrote:
>
> >On Tue, 25 Apr 2006 19:26:07 GMT,
> >in article <jJu3g.1360$xX5...@bgtnsc05-news.ops.worldnet.att.net>,
> >spamf...@navasgroup.com (John Navas) writes...
>
> >> Bounced mail.
> >
> >That would imply that someone using the DUL has blacklisted
> >an IP that appears in the DUL. Presumably that IP is running
> >an MTA. There are 2 issues here:
> >
> >1) Since the DUL only uses address-space submitted to it by
> > the owners of the address-space, ...
>
> Not in my experience.
I stand corrected on that point, as it appears that MAPS has
changed their position on nominations to the DUL since the
time when I was following it more closely. They do in fact
add non-ISP-submitted IPs, although they do not do it without
human intervention, according to this:
http://www.mail-abuse.com/nominats_dul.html
> >2) The entity at the receiving end using the DUL has chosen
> > to do so, and the beef on that side is with the operator
> > of the destination MTA. ...
>
> I disagree.
If it is determined that there is an inaccurate listing in
the DUL, obviously the issue is with the DUL database itself.
However if the DUL is accurate and traffic is blocked on the
receiving side from an IP not on the DUL, then obviously the
faulty party is the administrator of the receiving MTA.
linuxnut
> Surely you know that it can be possible to match/trace an IP address back to
> the person using it and/or personally identifying data, but then again maybe
> not. Many of my clients expect me to maintain the strictest anonymity (for
> good reason).
Do they surf through anonymizers, and proxies? Because just surfing the
web, sending an e-mail or making ANY kind of net connection will get
their IP logged somewhere.
Expecting your IP address to be secret information is just silly.
-Steve
--
"Knowing others is wisdom, knowing your self is Enlightenment." - Lao-Tzu
|C8H10N4O2|
--
Philip J. Koenig
in article <e2ne0q$1v0$1...@blue.rahul.net>,
c.c....@XReXXComca.usenet.us.com (Rahul Dhesi) writes...
You're not making sense. Above you say they've "adopted"
this "standard PTR naming scheme". Did they or did they
not adopt an ad-hoc scheme prior to an RFC being published
on this?
linuxnut
> [POSTED TO ba.internet - REPLY ON USENET PLEASE]
> In <oi4u42pbip0cusvla...@4ax.com> on Tue, 25 Apr 2006 23:28:04
> -0700, ka...@sonic.net wrote:
> > You're sooo easy.
> You're sooo predictable. And childish. Have a nice day.
"Pot..Kettle..Black.."
John Navas
In <444fbd34$0$1602$742e...@news.sonic.net> on 26 Apr 2006 18:34:28 GMT,
linuxnut <linu...@sonic.net> wrote:
>John Navas <spamf...@navasgroup.com> wrote:
>> Surely you know that it can be possible to match/trace an IP address back to
>> the person using it and/or personally identifying data, but then again maybe
>> not. Many of my clients expect me to maintain the strictest anonymity (for
>> good reason).
>
>Do they surf through anonymizers, and proxies? Because just surfing the
>web, sending an e-mail or making ANY kind of net connection will get
>their IP logged somewhere.
>
>Expecting your IP address to be secret information is just silly.
Straw man. The source of the problem is in fact that IP addresses aren't
secret, so disclosing them is thus a privacy/security issue.
Since you're having so much trouble grasping this, I'll make it simple: Guess
any of the entities that might be affected. You can't of course. But if
I published the IP addresses you might well be able to do that, and use the IP
addresses to deduce other information about them. Got it now?
John Navas
In <MPG.1eb957733...@corp.supernews.com> on Wed, 26 Apr 2006
11:10:38 -0700, Philip J. Koenig <See_email_@ddress_below.This_one_is.invalid>
wrote:
>On Wed, 26 Apr 2006 15:59:37 GMT,
>in article <JNM3g.48113$az4....@bgtnsc04-news.ops.worldnet.att.net>,
>spamf...@navasgroup.com (John Navas) writes...
>
>> In <MPG.1eb8c86c9...@corp.supernews.com> on Wed, 26 Apr 2006
>> 01:00:20 -0700, Philip J. Koenig <See_email_@ddress_below.This_one_is.invalid>
>> wrote:
>> >1) Since the DUL only uses address-space submitted to it by
>> > the owners of the address-space, ...
>>
>> Not in my experience.
>
>I stand corrected on that point, as it appears that MAPS has
>changed their position on nominations to the DUL since the
>time when I was following it more closely. They do in fact
>add non-ISP-submitted IPs, although they do not do it without
>human intervention, according to this:
>
>http://www.mail-abuse.com/nominats_dul.html
You shouldn't take anything like that at face value. Such statements are
often incorrect in general to at least some degree, sometimes because they are
out of date, sometimes because they are more the ideal than the reality,
sometimes out of ignorance, sometimes because they are deliberately
disingenuous -- you get the idea.
>> >2) The entity at the receiving end using the DUL has chosen
>> > to do so, and the beef on that side is with the operator
>> > of the destination MTA. ...
>>
>> I disagree.
>
>If it is determined that there is an inaccurate listing in
>the DUL, obviously the issue is with the DUL database itself.
>However if the DUL is accurate and traffic is blocked on the
>receiving side from an IP not on the DUL, then obviously the
>faulty party is the administrator of the receiving MTA.
I know it to be flawed, both in concept and in implementation, and think the
instigator/promulator always bears some of the responsibility for the
consequences of its use in any event -- it's at best disingenuous for such
persons to claim otherwise.
Philip J. Koenig
in article <ptQ3g.4647$xX5....@bgtnsc05-news.ops.worldnet.att.net>,
> [POSTED TO ba.internet - REPLY ON USENET PLEASE]
>
> In <MPG.1eb957733...@corp.supernews.com> on Wed, 26 Apr 2006
> 11:10:38 -0700, Philip J. Koenig <See_email_@ddress_below.This_one_is.invalid>
> wrote:
>
> >On Wed, 26 Apr 2006 15:59:37 GMT,
> >in article <JNM3g.48113$az4....@bgtnsc04-news.ops.worldnet.att.net>,
> >spamf...@navasgroup.com (John Navas) writes...
> >
> >> In <MPG.1eb8c86c9...@corp.supernews.com> on Wed, 26 Apr 2006
> >> 01:00:20 -0700, Philip J. Koenig <See_email_@ddress_below.This_one_is.invalid>
> >> wrote:
>
> >> >1) Since the DUL only uses address-space submitted to it by
> >> > the owners of the address-space, ...
> >>
> >> Not in my experience.
> >
> >I stand corrected on that point, as it appears that MAPS has
> >changed their position on nominations to the DUL since the
> >time when I was following it more closely. They do in fact
> >add non-ISP-submitted IPs, although they do not do it without
> >human intervention, according to this:
> >
> >http://www.mail-abuse.com/nominats_dul.html
>
> You shouldn't take anything like that at face value.
Likewise I don't think it's useful to immediately discount
such statements either. MAPS has a history of pretty good
credibility on that stuff, unlike most of the other list
operators.
> >If it is determined that there is an inaccurate listing in
> >the DUL, obviously the issue is with the DUL database itself.
> >However if the DUL is accurate and traffic is blocked on the
> >receiving side from an IP not on the DUL, then obviously the
> >faulty party is the administrator of the receiving MTA.
>
> I know it to be flawed, both in concept and in implementation, and think the
> instigator/promulator always bears some of the responsibility for the
> consequences of its use in any event -- it's at best disingenuous for such
> persons to claim otherwise.
This does not change the fact that in a particular instance, if
traffic had been blocked from an IP that was not actually on the
DUL, then the complaint should be with the administrator of the
receiving MTA, not the operators of the DUL for this specific
case.
If you wish to make it clear that you oppose any implementation
of the DUL of any kind, that's a separate issue and not really
relevant to blocked traffic if it is shown not to have been due
to a DUL listing.
Philip J. Koenig
in article <NlQ3g.49176$az4....@bgtnsc04-news.ops.worldnet.att.net>,
spamf...@navasgroup.com (John Navas) writes...
I am supporting JN on this. Expecting someone to publicly
publish the IP addresses of specific hosts affected by security
issues is unreasonable and dangerous in this era.
Javier suggested JN could give him the info and he would make
sure if it was wrongly listed it would be removed. If that
were done privately it would be much less an issue than posting
it on a forum which is spidered daily by spammers and scammers
looking for systems and users to exploit. (not to mention plain-
old vindictive folks who have nothing better to do than try to
ruin someone else's day)
John Navas
In <MPG.1eb977718...@corp.supernews.com> on Wed, 26 Apr 2006
13:27:02 -0700, Philip J. Koenig <See_email_@ddress_below.This_one_is.invalid>
wrote:
>On Wed, 26 Apr 2006 20:11:01 GMT,
>in article <ptQ3g.4647$xX5....@bgtnsc05-news.ops.worldnet.att.net>,
>spamf...@navasgroup.com (John Navas) writes...
>>
>> In <MPG.1eb957733...@corp.supernews.com> on Wed, 26 Apr 2006
>> 11:10:38 -0700, Philip J. Koenig <See_email_@ddress_below.This_one_is.invalid>
>> wrote:
>> >I stand corrected on that point, as it appears that MAPS has
>> >changed their position on nominations to the DUL since the
>> >time when I was following it more closely. They do in fact
>> >add non-ISP-submitted IPs, although they do not do it without
>> >human intervention, according to this:
>> >
>> >http://www.mail-abuse.com/nominats_dul.html
>>
>> You shouldn't take anything like that at face value.
>
>Likewise I don't think it's useful to immediately discount
>such statements either. MAPS has a history of pretty good
>credibility on that stuff, unlike most of the other list
>operators.
Better than some others, but from what I know I wouldn't call it "pretty good
credibility."
>> I know it to be flawed, both in concept and in implementation, and think the
>> instigator/promulator always bears some of the responsibility for the
>> consequences of its use in any event -- it's at best disingenuous for such
>> persons to claim otherwise.
>
>This does not change the fact that in a particular instance, if
>traffic had been blocked from an IP that was not actually on the
>DUL, then the complaint should be with the administrator of the
>receiving MTA, not the operators of the DUL for this specific
>case.
>
>If you wish to make it clear that you oppose any implementation
>of the DUL of any kind, that's a separate issue and not really
>relevant to blocked traffic if it is shown not to have been due
>to a DUL listing.
I disagree on both counts.
John Navas
In <MPG.1eb9789ba...@corp.supernews.com> on Wed, 26 Apr 2006
13:32:02 -0700, Philip J. Koenig <See_email_@ddress_below.This_one_is.invalid>
wrote:
>On Wed, 26 Apr 2006 20:02:53 GMT,
>in article <NlQ3g.49176$az4....@bgtnsc04-news.ops.worldnet.att.net>,
>spamf...@navasgroup.com (John Navas) writes...
>> Since you're having so much trouble grasping this, I'll make it simple: Guess
>> any of the entities that might be affected. You can't of course. But if
>> I published the IP addresses you might well be able to do that, and use the IP
>> addresses to deduce other information about them. Got it now?
>
>I am supporting JN on this. Expecting someone to publicly
>publish the IP addresses of specific hosts affected by security
>issues is unreasonable and dangerous in this era.
>
>Javier suggested JN could give him the info and he would make
>sure if it was wrongly listed it would be removed. If that
>were done privately it would be much less an issue than posting
>it on a forum which is spidered daily by spammers and scammers
>looking for systems and users to exploit. (not to mention plain-
>old vindictive folks who have nothing better to do than try to
>ruin someone else's day)
From the point of view of my clients, turning that information to someone
whose trustworthiness can't be assured isn't meaningfully better than just
publishing it. For all they know, he might then publish it, or otherwise
misuse it.
linuxnut
> Straw man. The source of the problem is in fact that IP addresses aren't
> secret, so disclosing them is thus a privacy/security issue.
Yeah, right.
> Since you're having so much trouble grasping this, I'll make it simple: Guess
> any of the entities that might be affected. You can't of course. But if
> I published the IP addresses you might well be able to do that, and use the IP
> addresses to deduce other information about them. Got it now?
Nope. Unless they are hiding the fact that they are your client. Maybe
that's it? Are they ashamed of you?
linuxnut
> On Wed, 26 Apr 2006 20:02:53 GMT,
> publish the IP addresses of specific hosts affected by security
> issues is unreasonable and dangerous in this era.
Affected by security issues? I believe the thread was to post a list of
IP address that are on a DUL that shouldn't be.. Thats not a security
issue.
> Javier suggested JN could give him the info and he would make
> sure if it was wrongly listed it would be removed. If that
> were done privately it would be much less an issue than posting
> it on a forum which is spidered daily by spammers and scammers
> looking for systems and users to exploit. (not to mention plain-
> old vindictive folks who have nothing better to do than try to
> ruin someone else's day)
Sure, I see your point here. But I don't feel posting IP addresses is a
security risk. I could make up numbers like 245.132.16.5 , Am I now
putting this person at risk for something? I don't think so.
Rahul Dhesi
>> >> ISPs who truly care about making it easy for others to block their
>> >> dynamic IP space have already proposed, and adopted, a standard PTR
>> >> naming scheme....
>>
>> >"Something like" or "exactly like"? Where is this ad-hoc
>> >"standard" published?
>>
>> The answer was in the very next sentence that you quoted:
>>
>> >> But since this has not happened...
>You're not making sense. Above you say they've "adopted"
>this "standard PTR naming scheme". Did they or did they
>not adopt an ad-hoc scheme prior to an RFC being published
>on this?
Which part of "since this has not happened" is unclear?
Philip, you are shooting from the hip without reading a posting in its
entirety, and then trying to recover.
You did something similar with the URL I posted:
http://www.jammconsulting.com/jamm/dnsbl.jsp
Instead of reading the whole thing, you went off on a tangent after
reading just a little of that web page (the part that had nothing to do
with why I posted it), and you completely failed to notice the
PTR-matching patterns later on on the same web page.
--
Rahul
ka...@sonic.net
In the words of our government, "What do they have to hide?"
John Navas
In <squv4210clrla77l3...@4ax.com> on Wed, 26 Apr 2006 16:00:11
-0700, ka...@sonic.net wrote:
Confidential information.
ka...@sonic.net
<spamf...@navasgroup.com> wrote:
>[POSTED TO ba.internet - REPLY ON USENET PLEASE]
>
>In <squv4210clrla77l3...@4ax.com> on Wed, 26 Apr 2006 16:00:11
>-0700, ka...@sonic.net wrote:
>
>>On Wed, 26 Apr 2006 02:22:40 GMT, John Navas
>><spamf...@navasgroup.com> wrote:
>
>>>Surely you know that it can be possible to match/trace an IP address back to
>>>the person using it and/or personally identifying data, but then again maybe
>>>not. Many of my clients expect me to maintain the strictest anonymity (for
>>>good reason).
>>
>> In the words of our government, "What do they have to hide?"
>
>Confidential information.
A non-answer.
JC Dill
<See_email_@ddress_below.This_one_is.invalid> wrote:
>On Tue, 25 Apr 2006 11:54:38 -0700, in article
><ooqs42ppqlch3khs7...@4ax.com>, JC Dill writes...
>
>> On Tue, 25 Apr 2006 03:01:51 -0700, Philip J. Koenig
>> <See_email_@ddress_below.This_one_is.invalid> wrote:
>>
>> >Apparently Comcast is using a simplistic set of rules
>> >to parse the PTR record, and apparently if it contains
>> >(as in this case) a string "dsl", they assume it's a
>> >"residential" or "dynamic" address.
>>
>> This is not uncommon.
>
>It might be common, but it's still pretty dumb. You
>can have extremely effective anti-spam measures without
>resorting to that sort of nonsense.
It's not nonsense. It blocks a LOT of spam and very little non-spam.
>There are plenty of ways of knowing. (if they were so inclined)
>It just isn't as trivial and quick as they would like so that
>it can be done during an SMTP handshake the way they would
>prefer.
They don't have time to do anything more time-intensive. You OTOH,
can spend a small amount of time to change the PTR of your IP address
and avoid these types of blocks.
>I would also like to know what definition you are using for
>"ordinary DSL address".
Anything with a default PTR that identifies it as being part of a DSL
block with default addressing.
>> (which should never send email "direct-to-MX")
>
>Says who? I've been doing so for probably at least 5 years
>now, and before that over ISDN. Methinks someone is thinking
>more than a bit too simplistically here.
Anyone who doesn't have enough clue to get the PTR changed shouldn't
be running a mail server, on a DSL address or elsewhere.
>Nothing like burdening the victim with the fix.
You move into a bad neighborhood, it's your problem. You put your
mail server on an IP block next to a bunch of lusers who have no
business sending "direct-to-mx" email, so it's YOUR problem to
identify that your IP is run by someone with clue and that the email
you send is being sent by a legitimate mail server, not a trojan
compromised PC like the email being sent "direct-to-mx" by your IP
neighbors.
>> > Too
>> >bad so much legitimate traffic will get caught in the crossfire
>>
>> Very little legitimate email will get caught by this type of
>> filtering.
>
>I have a very hard time believing that.
Too bad. It IS a common way spam is being sent today, and blocking
this type of email blocks a lot of spam with very very few false
positives.
> What's more, I also know
>for a fact that you do not have to resort to such tactics to have
>a superbly accurate antispam system. It really comes down to, in
>my opinion, laziness and cost on the part of those who use such
>tactics.
They run their network with more cost effective measures than you
think ideal? Too bad for you. Their network, their rules.
>> Most people who have DSL lines either aren't sending email directly
>> but rather using their ISPs mail server, or they have enough clue to
>> change the PTR record to indicate that this is an IP address used by
>> someone with clue, and thus legitimately configured with a mail
>> server.
>
>Up until a few weeks ago, the definition of "clue" in regards to
>at least one particularly large US ISP changed dramatically. I
>don't see anywhere in the RFC's where operators of MX hosts are
>admonished not to ever allow a PTR record for an MX to contain
>a string resembling "dsl". If you know otherwise, please advise.
Their network, their rules. They get to decide what IPs they will let
connect to their mail server. They don't need an RFC to "allow" them
to filter out connections based on IPs or PTRs.
>> >as people once again are forced to adapt to silly ISP email
>> >blocking tactics. (why Comcast can't use a much more tried-
>> >and-true method like the old MAPS DUL, which only contains IP
>> >address space submitted by ISPs as _truly_ dynamic or
>> >residential) is beyond me.
>>
>> Because those lists are not comprehensive enough. Too many DSL IPs
>> aren't being voluntarily entered by the ISPs. so other ISPs resort to
>> making educated guesses so that they can have more complete IP blocks.
>
>Translation: they want a quick, easy and cheap system. (they
>probably also don't want to pay for the usage of the DUL either.
>What a surprise.)
Your translation is bullshit. As noted above, the lists ARE NOT
COMPREHENSIVE ENOUGH and adding IPs using this formula is A) very
effective and B) produces very low false positive rates.
You are just whining because you didn't know to change your PTR. Your
ignorance isn't something everyone else is supposed to work around.
>> *Usually* these additional blocks are generated by looking at the IPs
>> that actually send spam.
>
>For some reason that doesn't sound particularly plausible in this
>case.
Are you really stupid, or do you just play stupid on ba.internet?
When a trojan compromised PC *anywhere* in your ISPs DSL system with
an IP such as 111-222-333-444.dsl.[isp].net sent spam, examining that
spam would trigger the addition of 111-222-333-444.dsl.[isp].net rules
to the netblock filter. (Actually, the rule added would probably be
111-222-333-444.dsl.*, applying to ALL ISPs and not just to your ISP.)
Said filter would then block all further spam emiting from this one
trojan compromised PC as well as future spam emiting from other trojan
compromised PCs in neighboring IPs and similar IPs at other ISPs.
>A lot of people are pretty desperate these days to block
>junkmail, and a lot of Comcast's customers aren't particularly
>sophisticated internet users, so those factors contributing
>to Comcast's customers being "happy" about their status-quo
>doesn't exactly represent a particularly compelling argument
>for what they're doing.
They are making their customers happy. If this serves Comcast and
Comcast's customers well, then who are you to whine?
>Another fun fact: guess which network is the largest global
>source of zombie-originated spam? Comcast.
>
>http://tqmcube.com/zombies.php
That doesn't surprise me in the least. They are focusing their
efforts on protecting their customers, not on protecting the rest of
the net. Other networks block "direct-to-mx" emiting from Comcast.
Such is the state of fighting spam today.
jc
--
"The nice thing about a mare is you get to ride a lot
of different horses without having to own that many."
~ Eileen Morgan of The Mare's Nest, PA
Javier
> be running a mail server, on a DSL address or elsewhere.
I claim to have enough clues to run my own MTA, but Bellsouth won't set
the PTR record for the IP address statically assigned to me [1] to
reflect a hostname of my choice. The invoked reason: service not
available for home accounts.
-jav
[1] I wish I could tell you what the IP address is, but it's classified
information.
JC Dill
wrote:
>> Anyone who doesn't have enough clue to get the PTR changed shouldn't
>> be running a mail server, on a DSL address or elsewhere.
>
>I claim to have enough clues to run my own MTA, but Bellsouth won't set
>the PTR record for the IP address statically assigned to me [1] to
>reflect a hostname of my choice. The invoked reason: service not
>available for home accounts.
Which means that they don't want you running a mail server (or perhaps
*any* server, check the TOS/AUP) on that IP, and that you should be
sending your outbound email via their mail server.
Mike Hunt
> On Thu, 27 Apr 2006 15:22:40 -0400, Javier <jav...@invalid.invalid>
> wrote:
>
>>> Anyone who doesn't have enough clue to get the PTR changed shouldn't
>>> be running a mail server, on a DSL address or elsewhere.
>>
>>I claim to have enough clues to run my own MTA, but Bellsouth won't set
>>the PTR record for the IP address statically assigned to me [1] to
>>reflect a hostname of my choice. The invoked reason: service not
>>available for home accounts.
>
> Which means that they don't want you running a mail server (or perhaps
> *any* server, check the TOS/AUP) on that IP, and that you should be
> sending your outbound email via their mail server.
My ISP allows mail servers (and other servers) and do not require users to
use their mail server. They will not give me a PTR change unless I use
them as a registrar, which I don't.
--
This is my .sig
Javier
> On Thu, 27 Apr 2006 15:22:40 -0400, Javier <jav...@invalid.invalid>
> wrote:
>
>>> Anyone who doesn't have enough clue to get the PTR changed shouldn't
>>> be running a mail server, on a DSL address or elsewhere.
>> I claim to have enough clues to run my own MTA, but Bellsouth won't set
>> the PTR record for the IP address statically assigned to me [1] to
>> reflect a hostname of my choice. The invoked reason: service not
>> available for home accounts.
>
> Which means that they don't want you running a mail server (or perhaps
> *any* server, check the TOS/AUP) on that IP, and that you should be
> sending your outbound email via their mail server.
I checked the TOS/AUP already, and talked to their service department.
Servers are OK, they just don't want to change the PTR record.
It's not that big of a deal for me, I just relay through my server
colocated at Layer42. I was just illustrating that not being able to
change the PTR record doesn't necessarily equates to lack of clues.
-jav
Philip J. Koenig
$742e...@news.sonic.net>, linuxnut writes...
> Philip J. Koenig <See_email_@ddress_below.this_one_is.invalid> wrote:
> > On Wed, 26 Apr 2006 20:02:53 GMT,
> > I am supporting JN on this. Expecting someone to publicly
> > publish the IP addresses of specific hosts affected by security
> > issues is unreasonable and dangerous in this era.
>
> Affected by security issues? I believe the thread was to post a list of
> IP address that are on a DUL that shouldn't be.. Thats not a security
> issue.
The phrase "security issues" is not probably the best phrase
to have used - in reality the host(s) in question are affected
by mail delivery problems - which may or may not have been
related to some sort of security issue.
> > Javier suggested JN could give him the info and he would make
> > sure if it was wrongly listed it would be removed. If that
> > were done privately it would be much less an issue than posting
> > it on a forum which is spidered daily by spammers and scammers
> > looking for systems and users to exploit. (not to mention plain-
> > old vindictive folks who have nothing better to do than try to
> > ruin someone else's day)
>
> Sure, I see your point here. But I don't feel posting IP addresses is a
> security risk. I could make up numbers like 245.132.16.5 , Am I now
> putting this person at risk for something? I don't think so.
Actually you are. Once upon a time, it was standard practice
to publish email addresses in clear text on web pages. Today
no webmaster in their right mind does such a thing because
the email address is immediately spidered/harvested/sold to
spammers and scammers.
While IP addresses are "public" as a general pool of resources,
the mapping of IP address to individual is not necessarily
public. Posting someone's IP address to a public forum is
not entirely unlike posting someone's credit-card or license
plate number. In the case of a license plate, sure it's a
piece of data that's "public" in the sense that we see these
things out in public all the time. What we often don't see
(and the owners often like to protect) is the association of
the number to a specific person or entity. Once that association
is established, the door opens to all sorts of potentially
exploitive actions.
Philip J. Koenig
<sfs052hmvebeclfk7...@4ax.com>, writes...
Apparently none of you have ever been an IRC user, or have
otherwise been the target of a malicious internet attack
of any kind.
Given how easy it is to get on the wrong side of some
miscellaneous malicious party on the 'net (although it's
easier for some than others :-), how tempting it might be
to aggravate someone in return by bringing down or breaking
into the internet host of one of the person's clients or
associates? I'm not sure why I have to explain this..
Philip J. Koenig
$742e...@news.sonic.net>, linuxnut writes...
> John Navas <spamf...@navasgroup.com> wrote:
> > [POSTED TO ba.internet - REPLY ON USENET PLEASE]
>
> > In <oi4u42pbip0cusvla...@4ax.com> on Tue, 25 Apr 2006 23:28:04
> > -0700, ka...@sonic.net wrote:
>
> > > You're sooo easy.
>
> > You're sooo predictable. And childish. Have a nice day.
>
> "Pot..Kettle..Black.."
Due to the frequency of usage in this forum, I recommend
the new, racy acronym "PKB" as a cool way to save a few
electrons. :-)
Philip J. Koenig
<n712525ftoha853fq...@4ax.com>, JC Dill writes...
> On Tue, 25 Apr 2006 12:45:09 -0700, Philip J. Koenig
> <See_email_@ddress_below.This_one_is.invalid> wrote:
>
> >On Tue, 25 Apr 2006 11:54:38 -0700, in article
> ><ooqs42ppqlch3khs7...@4ax.com>, JC Dill writes...
> >
> >> On Tue, 25 Apr 2006 03:01:51 -0700, Philip J. Koenig
> >> <See_email_@ddress_below.This_one_is.invalid> wrote:
> >>
> >> >Apparently Comcast is using a simplistic set of rules
> >> >to parse the PTR record, and apparently if it contains
> >> >(as in this case) a string "dsl", they assume it's a
> >> >"residential" or "dynamic" address.
> >>
> >> This is not uncommon.
> >
> >It might be common, but it's still pretty dumb. You
> >can have extremely effective anti-spam measures without
> >resorting to that sort of nonsense.
>
> It's not nonsense. It blocks a LOT of spam and very little non-spam.
And I guarantee you that the Brightmail system that I administer
does a far better job of both. Why would you suspect Comcast prefers
their method instead? (hint: cost and ease, as I said before)
> >There are plenty of ways of knowing. (if they were so inclined)
> >It just isn't as trivial and quick as they would like so that
> >it can be done during an SMTP handshake the way they would
> >prefer.
>
> They don't have time to do anything more time-intensive. You OTOH,
> can spend a small amount of time to change the PTR of your IP address
> and avoid these types of blocks.
I just love these "burden the victim" tactics.
> >I would also like to know what definition you are using for
> >"ordinary DSL address".
>
> Anything with a default PTR that identifies it as being part of a DSL
> block with default addressing.
And what would the rules for that be, and where is it written?
Furthermore, you are changing the terms here. Comcast claims
it is blocking "residential IPs" (says right in the bounce
message), and they were clearly wrong in this case. Why should
innocent sites suffer for bad judgement on the part of the
recipient site?
What ever happened to "Be conservative in what you send, be
liberal in what you receive"? (I know, I know - "in this day
and age, bla bla bla". I will modify Jon Postel's law to say
"Do not be unnecessarily conservative in what you receive",
which is perfectly applicable to modern life on the 'net)
> >> (which should never send email "direct-to-MX")
> >
> >Says who? I've been doing so for probably at least 5 years
> >now, and before that over ISDN. Methinks someone is thinking
> >more than a bit too simplistically here.
>
> Anyone who doesn't have enough clue to get the PTR changed shouldn't
> be running a mail server, on a DSL address or elsewhere.
Oftentimes users do not have control or influence over the
in-arpa zone for their IP, and that simple fact does not
make them a spammer with no business running an MTA.
> >Nothing like burdening the victim with the fix.
>
> You move into a bad neighborhood, it's your problem. You put your
> mail server on an IP block next to a bunch of lusers who have no
> business sending "direct-to-mx" email, so it's YOUR problem to
> identify that your IP is run by someone with clue and that the email
> you send is being sent by a legitimate mail server, not a trojan
> compromised PC like the email being sent "direct-to-mx" by your IP
> neighbors.
When such "laws" are codified in the RFC's, I'll give more
credence to them. Prior to that, I'll consider blocking
on such a basis rogue behaviour.
> >> > Too
> >> >bad so much legitimate traffic will get caught in the crossfire
> >>
> >> Very little legitimate email will get caught by this type of
> >> filtering.
> >
> >I have a very hard time believing that.
>
> Too bad. It IS a common way spam is being sent today, and blocking
> this type of email blocks a lot of spam with very very few false
> positives.
Better methodologies exist, but apparently Comcast is either
too lazy or too cheap to use them.
> > What's more, I also know
> >for a fact that you do not have to resort to such tactics to have
> >a superbly accurate antispam system. It really comes down to, in
> >my opinion, laziness and cost on the part of those who use such
> >tactics.
>
> They run their network with more cost effective measures than you
> think ideal? Too bad for you. Their network, their rules.
They are interfering with legitimate traffic originating from
legitimate senders all over the 'net, and as such it becomes
a public issue.
> >> Most people who have DSL lines either aren't sending email directly
> >> but rather using their ISPs mail server, or they have enough clue to
> >> change the PTR record to indicate that this is an IP address used by
> >> someone with clue, and thus legitimately configured with a mail
> >> server.
> >
> >Up until a few weeks ago, the definition of "clue" in regards to
> >at least one particularly large US ISP changed dramatically. I
> >don't see anywhere in the RFC's where operators of MX hosts are
> >admonished not to ever allow a PTR record for an MX to contain
> >a string resembling "dsl". If you know otherwise, please advise.
>
> Their network, their rules. They get to decide what IPs they will let
> connect to their mail server. They don't need an RFC to "allow" them
> to filter out connections based on IPs or PTRs.
Technically, spamming is not prohibited by RFC's either, but it
is widely believed to be anti-social behaviour and a detriment
to the 'net as a whole. While Comcast's ill-conceived email
blocking measures are not overall as damaging, they still fall
into that class as far as I'm concerned.
There are ISPs that block entire continents from sending SMTP
to them, but no "large" ISPs do this because when you become
large you inevitably learn that you will alienate a significant
portion of your userbase if you resort to such tactics. I
simply think Comcast has gone over the line with this one.
> >> >as people once again are forced to adapt to silly ISP email
> >> >blocking tactics. (why Comcast can't use a much more tried-
> >> >and-true method like the old MAPS DUL, which only contains IP
> >> >address space submitted by ISPs as _truly_ dynamic or
> >> >residential) is beyond me.
> >>
> >> Because those lists are not comprehensive enough. Too many DSL IPs
> >> aren't being voluntarily entered by the ISPs. so other ISPs resort to
> >> making educated guesses so that they can have more complete IP blocks.
> >
> >Translation: they want a quick, easy and cheap system. (they
> >probably also don't want to pay for the usage of the DUL either.
> >What a surprise.)
>
> Your translation is bullshit. As noted above, the lists ARE NOT
> COMPREHENSIVE ENOUGH and adding IPs using this formula is A) very
> effective and B) produces very low false positive rates.
How is it that you appear to consider that the various DNS BL's
constitute the entire constellation of spam mitigation measures
available to ISPs? Yeah, lots of the DNS BL's are crap, but
that doesn't prove a whole hell of a lot since DNS BL's are
pretty much what operators use when they don't want to make a
significant investment in a more sophisticated antispam system.
> You are just whining because you didn't know to change your PTR. Your
> ignorance isn't something everyone else is supposed to work around.
Your obnoxious characterization of my position (apparently, just
because I disagree with you on some points which often are disagreed
upon by reasonable people), use of nasty language and ad-hominem
doesn't do you any credit either.
> >> *Usually* these additional blocks are generated by looking at the IPs
> >> that actually send spam.
> >
> >For some reason that doesn't sound particularly plausible in this
> >case.
>
> Are you really stupid, or do you just play stupid on ba.internet?
See above.
> When a trojan compromised PC *anywhere* in your ISPs DSL system with
> an IP such as 111-222-333-444.dsl.[isp].net sent spam, examining that
> spam would trigger the addition of 111-222-333-444.dsl.[isp].net rules
> to the netblock filter.
#1, the host in question was not trojaned
#2, the host in question had not, to our knowledge, been
the source of any spam. (nor was it was not on anyone
else's DNS BL that I can find, other than triggering
Comcast's bounce prior to when the PTR record was changed)
> (Actually, the rule added would probably be
> 111-222-333-444.dsl.*, applying to ALL ISPs and not just to your ISP.)
Brilliant idea, Not. TTBOWTBW again. (Throwing The Baby Out With
The Bathwater)
> Said filter would then block all further spam emiting from this one
> trojan compromised PC as well as future spam emiting from other trojan
> compromised PCs in neighboring IPs and similar IPs at other ISPs.
As well as a fair bit of legitimate traffic. Why not simply
block all credit cards with numbers starting with "4454" when
the credit-card processor discovers a single fraudulent
transaction from a card number beginning with that integer?
Too bad for the millions of legitimate card-holders.. they're
just "whiners"!
> >A lot of people are pretty desperate these days to block
> >junkmail, and a lot of Comcast's customers aren't particularly
> >sophisticated internet users, so those factors contributing
> >to Comcast's customers being "happy" about their status-quo
> >doesn't exactly represent a particularly compelling argument
> >for what they're doing.
>
> They are making their customers happy. If this serves Comcast and
> Comcast's customers well, then who are you to whine?
When their procedures interfere with legitimate communications.
I would make the same complaint if SBC decided that all phone
numbers starting with the number "3" were illegitimate and
started blocking all calls from such numbers to their
subscribers.
> >Another fun fact: guess which network is the largest global
> >source of zombie-originated spam? Comcast.
> >
> >http://tqmcube.com/zombies.php
>
> That doesn't surprise me in the least. They are focusing their
> efforts on protecting their customers, not on protecting the rest of
> the net. Other networks block "direct-to-mx" emiting from Comcast.
> Such is the state of fighting spam today.
How quickly you come to Comcast's defense on such matters,
even to go so far to "excuse" them for being the biggest
source of zombie-spam in the world!
First off, when did it become acceptable as an ISP to ignore
spam EMANATING from your network, and only care about SPAM
ENTERING your network?? Amazing!
Secondly - how pray-tell, do you suppose all that zombie-spam
on port 25 finds its way out of their network in the first
place? Do they not have any port 25 egress filtering? Do
they not monitor outgoing bulk mail sent through their own
MTA's? Sounds pretty damn irresponsible to me, by both
conventional and modern 'net wisdom.
Philip J. Koenig
<1252nba...@corp.supernews.com>, Mike Hunt writes...
Please stop spewing reality, some can't handle it.
Philip J. Koenig
@blue.rahul.net>, Rahul Dhesi writes...
> Philip J. Koenig <See_email_@ddress_below.This_one_is.invalid> writes:
>
> >> >> ISPs who truly care about making it easy for others to block their
> >> >> dynamic IP space have already proposed, and adopted, a standard PTR
> >> >> naming scheme....
> >>
> >> >"Something like" or "exactly like"? Where is this ad-hoc
> >> >"standard" published?
> >>
> >> The answer was in the very next sentence that you quoted:
> >>
> >> >> But since this has not happened...
>
>
> >You're not making sense. Above you say they've "adopted"
> >this "standard PTR naming scheme". Did they or did they
> >not adopt an ad-hoc scheme prior to an RFC being published
> >on this?
>
> Which part of "since this has not happened" is unclear?
>
> Philip, you are shooting from the hip without reading a posting in its
> entirety, and then trying to recover.
This is what I was responding to:
> ISPs who truly care about making it easy for others to
> block their dynamic IP space have already proposed, and
> adopted, a standard PTR naming scheme. Then a single
> pattern match against something like
>
>
> *.DYNAMIC-IP.*
>
>
> suffices and no DNS traffic, or repeated updates of a text
> list, will be needed.
>
>
> But since this has not happened, Comcast is presumably resorting
> to an ad hoc list. See, for example:
>
>
> http://www.jammconsulting.com/jamm/dnsbl.jsp
Please explain to me where in those sentences that you make it
clear that the string starting with "ISPs who truly care..."
was simply hypothetical? I read the string starting with "But
since this has not happened.." as applying to an actual RFC
being written. Mea Culpa if I read that wrong, it was not
particularly clear to me.
> You did something similar with the URL I posted:
>
> http://www.jammconsulting.com/jamm/dnsbl.jsp
>
> Instead of reading the whole thing, you went off on a tangent after
> reading just a little of that web page (the part that had nothing to do
> with why I posted it), and you completely failed to notice the
> PTR-matching patterns later on on the same web page.
Wrong. I saw the PTR matching patterns, and thought 1) how absurd
it was that someone was trying to maintain a list like that which
could never be particularly accurate, and 2) that the attitude and
philosophy of the maintainer of that list as evidenced by their
other email-blocking practices (entire continents!) reflected
very poorly on their overall credibility, particularly their
likely committment to "accuracy".
Bottom line, an email blocklist maintained by someone who
has no problem blocking email from entire continents doesn't
have much credibility with me, and I hope for any other
reasonable person who knows much about the issues. If
Comcast used such a list I think it would reflect even more
poorly on them than their own ill-advised "PTR beauty contest"
system.
Graham Freeman
> Actually you are. Once upon a time, it was standard practice
> to publish email addresses in clear text on web pages. Today
> no webmaster in their right mind does such a thing because
> the email address is immediately spidered/harvested/sold to
> spammers and scammers.
I think you're over-stating things. I never munge addresses, since I
refuse to allow spammers and their ilk ruin the utility of email for me.
I don't receive noticably more spam at the published addresses than I do
at the unpublished ones. Harvesting from web sites is just one method
used by spammers - dictionary attacks and other email identification
methods are in widespread use as well.
-G
Philip J. Koenig
<Pine.LNX.4.64.06...@enhance.cernio.com>, Graham Freeman writes...
My experience is vastly different. I have many email
addresses, some of which have been used publicly in
certain different ways, some of which have never been
used publicly.
The ones which have not been used publicly see ZERO spam
traffic. And I mean absolutely zero, as in not a single
spam message over multiple-year periods.
There are some addresses that have been used to post
essentially a *single* posting on a public webpage, and
they end up getting spammed regularly.
Whether or not a person philosophically "feels better" not
consciously restricting the public distribution of an email
address because to them it feels like "giving in to spammers",
the simple fact is that in general, publicizing an email
address is almost guaranteed to get it spammed.
Now if we all had highly-effective anti-spam systems, that
wouldn't be such a big problem perhaps, but unfortunately
lots of people don't.
I am often quite saddened by what the spammers and scammers
have done to the internet - not necessarily always just from
their direct actions, but even worse because of how certain
entities manage to stifle in ever more expanding ways the
promise of the 'net by portraying it as a "dangerous
neighborhood" - essentially exploiting the image of rampant
danger to clamp down on the free dissemination of information
which has always been, to me, such an exciting aspect about
the 'net.
Sigh, indeed.
Rahul Dhesi
>Mea Culpa if I read that wrong, it was not
>particularly clear to me.
Youa Culpa.
--
Rahul
ka...@sonic.net
<See_email_@ddress_below.This_one_is.invalid> wrote:
>On 26 Apr 2006 18:36:18 GMT, in article <444fbda2$0$1602
>$742e...@news.sonic.net>, linuxnut writes...
>
>> John Navas <spamf...@navasgroup.com> wrote:
>> > [POSTED TO ba.internet - REPLY ON USENET PLEASE]
>>
>> > In <oi4u42pbip0cusvla...@4ax.com> on Tue, 25 Apr 2006 23:28:04
>> > -0700, ka...@sonic.net wrote:
>>
>> > > You're sooo easy.
>>
>> > You're sooo predictable. And childish. Have a nice day.
>>
>> "Pot..Kettle..Black.."
>
>
>Due to the frequency of usage in this forum, I recommend
>the new, racy acronym "PKB" as a cool way to save a few
>electrons. :-)
You should also join HSOA (Help Stamp Out Acronyms).
JC Dill
<See_email_@ddress_below.This_one_is.invalid> wrote:
>I just love these "burden the victim" tactics.
The victim here is not you, it is Comcast which has been bombarded
with spam from your IP neighbors, and Comcast's users which have said
"filter that stuff so we don't get it in our inboxes".
Comcast is taking care of their customers first and foremost. They
(and their customers) consider a few false positives to be OK. The
customers don't want to spend more for a "better" solution, they think
this works just fine.
You think Comcast is being cheap because they won't pay for a more
expensive filtering solution. Comcast thinks YOU are being cheap
because you are trying to send email from an IP block that is
overwhelmingly full of clueless people who have no business sending
direct-to-MX email from their dynamic IPs. You want Comcast to spend
millions to implement better filtering, Comcast wants you to take a
few minutes to establish that you have clue by getting your IP to use
a non-dynamic-PTR.
IMHO you are being very unreasonable.
JC Dill
<See_email_@ddress_below.This_one_is.invalid> wrote:
>
>> >I would also like to know what definition you are using for
>> >"ordinary DSL address".
>>
>> Anything with a default PTR that identifies it as being part of a DSL
>> block with default addressing.
>
>And what would the rules for that be, and where is it written?
Comcast isn't under any obligation to disclose this. But this system
is widely used by network and mail server admins, google and learn.
>Furthermore, you are changing the terms here. Comcast claims
>it is blocking "residential IPs" (says right in the bounce
>message), and they were clearly wrong in this case. Why should
>innocent sites suffer for bad judgement on the part of the
>recipient site?
Your IP is in a block they identified as being a residential IP block,
based on the PTR. This block might contain both residential and
business IPs. Have you asked your provider? If so, your beef is with
your provider mixing residential and business IPs in a single block
using the same PTR addressing scheme.
>> >> (which should never send email "direct-to-MX")
>> >
>> >Says who? I've been doing so for probably at least 5 years
>> >now, and before that over ISDN. Methinks someone is thinking
>> >more than a bit too simplistically here.
>>
>> Anyone who doesn't have enough clue to get the PTR changed shouldn't
>> be running a mail server, on a DSL address or elsewhere.
>
>Oftentimes users do not have control or influence over the
>in-arpa zone for their IP, and that simple fact does not
>make them a spammer with no business running an MTA.
Your argument that this is inconvenient for some is like the old
argument that closing open relay mail servers would be inconvenient.
The net has changed, open relays are no longer feasible. Putting a
mail server on an IP that identifies itself as being part of a generic
DSL block is the same type of problem. The days when you can do that
and not get blocked are ending. You have to adapt to the changing
face of the net.
>When such "laws" are codified in the RFC's, I'll give more
>credence to them. Prior to that, I'll consider blocking
>on such a basis rogue behaviour.
You are spitting into the wind here. ISPs big and small are (and will
continue) blocking using this method.
My research found that the first RFC to describe closing open relays
was in ~2000, about 4 years after ISPs started closing open relays
following the abuse by Spamford and company.
>Better methodologies exist, but apparently Comcast is either
>too lazy or too cheap to use them.
Better DSL lines exist (that make it easier for you to have a
non-dynamic-ID-PTR) , but many DSL users are too lazy or too cheap to
use them and persist in trying to run mail servers on cheap DSL lines
that are IDd as being part of a block that consists of mainly Dynamic
and Home DSL user.
Pot, Kettle, Black
>They are interfering with legitimate traffic originating from
>legitimate senders all over the 'net, and as such it becomes
>a public issue.
No it doesn't. They serve their users with their rules. Their users
are happy with the cost/benefit.
>Technically, spamming is not prohibited by RFC's either,
You seem to have a basic misunderstanding of what RFCs are about.
They are merely a way to describe a standard so that those who *want*
to use the standard can, knowing that others will use it the same way.
RFCs do not define the only "rules" that networks can use to decide
when and how to exchange traffic with other networks.
Many RFCs today are written after the fact, codifying practices that
are already in place.
>How is it that you appear to consider that the various DNS BL's
>constitute the entire constellation of spam mitigation measures
>available to ISPs?
I never said that.
DNS BLs are but one of the many tools large ISPs use to help filter
out spam.
> Yeah, lots of the DNS BL's are crap, but
>that doesn't prove a whole hell of a lot since DNS BL's are
>pretty much what operators use when they don't want to make a
>significant investment in a more sophisticated antispam system.
Most ISPs use DNS BLs as a front line, and then have other filtering
methods they use after they accept the email. The primary reason is
that rejecting email before delivery is much less CPU, disk, and
network intensive than accepting it and then filtering.
>Your obnoxious characterization of my position
Your position is "I want a big ISP to change their rules because it's
inconvenient for me. I want them to spend a lot more money which
benefits me (a non customer) and pass that costs onto their customer."
Your position is selfish, and useless because the big ISPs don't care
about your wants.
>(apparently, just
>because I disagree with you on some points which often are disagreed
>upon by reasonable people),
I've been fighting this fight against spam for a long long time. Most
people, when faced with the problem you were faced with, once they
understood why the large ISPs filter in this fashion go "oh, OK, that
makes sense. I'll change my PTR. Thanks!" You didn't do that. You
kept whining.
Very few people involved in the fight to block/stop spam agree with
your position. Most people readily understand why this type of
blocking makes sense, doing the greatest good for the greatest number
at the lowest cost possible and providing reasonable work arounds for
the few who are inconvenienced.
>> When a trojan compromised PC *anywhere* in your ISPs DSL system with
>> an IP such as 111-222-333-444.dsl.[isp].net sent spam, examining that
>> spam would trigger the addition of 111-222-333-444.dsl.[isp].net rules
>> to the netblock filter.
>
>
>#1, the host in question was not trojaned
That Does Not Matter. It is in a bad neighborhood.
>#2, the host in question had not, to our knowledge, been
> the source of any spam. (nor was it was not on anyone
> else's DNS BL that I can find, other than triggering
> Comcast's bounce prior to when the PTR record was changed)
That Does Not Matter. It is in a bad neighborhood.
>> (Actually, the rule added would probably be
>> 111-222-333-444.dsl.*, applying to ALL ISPs and not just to your ISP.)
>
>Brilliant idea, Not. TTBOWTBW again. (Throwing The Baby Out With
>The Bathwater)
These rules throw out a LOT more spam than they generate false
positives. ISP customer by-and-large are VERY happy to have these
types of rules implemented to help stop spam and are willing to deal
with the occasional problem such as when someone like you has
difficulty emailing them.
There is no TTBOWTBW here.
>> Said filter would then block all further spam emiting from this one
>> trojan compromised PC as well as future spam emiting from other trojan
>> compromised PCs in neighboring IPs and similar IPs at other ISPs.
>
>As well as a fair bit of legitimate traffic.
No, as well as almost NO legitimate traffic, which is why such rules
are used.
I've said this before, and you seem to be ignoring it. Please pay
attention. This is an important fact and if you disagree with it as a
FACT then go find some data to back up your position.
> Why not simply
>block all credit cards with numbers starting with "4454" when
>the credit-card processor discovers a single fraudulent
>transaction from a card number beginning with that integer?
Because such a rule would generate a large number of false positives.
This filter that ISPs are using generates very few false positives.
>Too bad for the millions of legitimate card-holders.. they're
>just "whiners"!
There are no "millions of DSL users" inconvenienced by these filters.
99.999% of DSL users on dynamic-addressed and/or default PTRd IPs use
their ISPs mail server and are thus not inconvenienced by these
filters *at* *all*.
>> >A lot of people are pretty desperate these days to block
>> >junkmail, and a lot of Comcast's customers aren't particularly
>> >sophisticated internet users, so those factors contributing
>> >to Comcast's customers being "happy" about their status-quo
>> >doesn't exactly represent a particularly compelling argument
>> >for what they're doing.
>>
>> They are making their customers happy. If this serves Comcast and
>> Comcast's customers well, then who are you to whine?
>
>When their procedures interfere with legitimate communications.
Their network, their rules. They feel that the rare interference is
acceptable because these rules filter out a LOT of spam.
>> >Another fun fact: guess which network is the largest global
>> >source of zombie-originated spam? Comcast.
>> >
>> >http://tqmcube.com/zombies.php
>>
>> That doesn't surprise me in the least. They are focusing their
>> efforts on protecting their customers, not on protecting the rest of
>> the net. Other networks block "direct-to-mx" emiting from Comcast.
>> Such is the state of fighting spam today.
>
>
>How quickly you come to Comcast's defense on such matters,
I'm not defending them, I'm explaining how they (and other large ISPs)
operate.
If a friend asked me "should I get Comcast?", I'd say NO. I strongly
believe that Comcast is a horrible ISP, for a multitude of reasons.
But how I feel about their business has no bearing on what I wrote
above. I was simply describing how things are.
>even to go so far to "excuse" them for being the biggest
>source of zombie-spam in the world!
I did no such thing. I said I wasn't surprised, that is not the same
thing as excusing their behavior.
>First off, when did it become acceptable as an ISP to ignore
>spam EMANATING from your network, and only care about SPAM
>ENTERING your network?? Amazing!
Unfortunately, it's very common today on the Internet.
>Secondly - how pray-tell, do you suppose all that zombie-spam
>on port 25 finds its way out of their network in the first
>place? Do they not have any port 25 egress filtering?
Probably not. :-( This is also unfortunately very common with big
ISPs today.
>Do
>they not monitor outgoing bulk mail sent through their own
>MTA's? Sounds pretty damn irresponsible to me, by both
>conventional and modern 'net wisdom.
I agree.
Unfortunately, the other large networks (who are best able to affect
this type of behavior) don't have much higher ground on which to speak
about "how it should be done". All of them have their sins, none of
them are in a very good position to cast the first stone at others for
their alleged failure to Do The Right Thing.
John Navas
In <MPG.1ebb35768...@News.Individual.Net> on Thu, 27 Apr 2006
21:10:08 -0700, Philip J. Koenig <See_email_@ddress_below.This_one_is.invalid>
wrote:
>Actually you are. Once upon a time, it was standard practice
>to publish email addresses in clear text on web pages. Today
>no webmaster in their right mind does such a thing because
>the email address is immediately spidered/harvested/sold to
>spammers and scammers.
That's conventional wisdom of self-annointed cognoscenti, but I've not seen a
significant actual problem from web-posted email addresses in tests I've run.
Addresses tend to get compromised in other ways, either by naively entering
them in software and/or website registrations, by the results of dictionary
attacks, by inside selling of email address lists, by malware harvesting on
infected computers, and the like.
>While IP addresses are "public" as a general pool of resources,
>the mapping of IP address to individual is not necessarily
>public. Posting someone's IP address to a public forum is
>not entirely unlike posting someone's credit-card or license
>plate number. In the case of a license plate, sure it's a
>piece of data that's "public" in the sense that we see these
>things out in public all the time. What we often don't see
>(and the owners often like to protect) is the association of
>the number to a specific person or entity. Once that association
>is established, the door opens to all sorts of potentially
>exploitive actions.
Yep.
John Navas
In <MPG.1ebb670d3...@News.Individual.Net> on Fri, 28 Apr 2006
00:41:39 -0700, Philip J. Koenig <See_email_@ddress_below.This_one_is.invalid>
wrote:
>On Fri, 28 Apr 2006 00:20:21 -0700, in article
><Pine.LNX.4.64.06...@enhance.cernio.com>, Graham Freeman writes...
>
>> On Thu, 27 Apr 2006, Philip J. Koenig wrote:
>>
>> > Actually you are. Once upon a time, it was standard practice
>> > to publish email addresses in clear text on web pages. Today
>> > no webmaster in their right mind does such a thing because
>> > the email address is immediately spidered/harvested/sold to
>> > spammers and scammers.
>>
>> I think you're over-stating things. I never munge addresses, since I
>> refuse to allow spammers and their ilk ruin the utility of email for me.
>> I don't receive noticably more spam at the published addresses than I do
>> at the unpublished ones. Harvesting from web sites is just one method
>> used by spammers - dictionary attacks and other email identification
>> methods are in widespread use as well.
I agree.
>My experience is vastly different. I have many email
>addresses, some of which have been used publicly in
>certain different ways, some of which have never been
>used publicly.
>
>The ones which have not been used publicly see ZERO spam
>traffic. And I mean absolutely zero, as in not a single
>spam message over multiple-year periods.
Since you have your own domain, you may not get many dictionary attacks, and
you probably haven't had insiders selling lists of your addresses. ;)
I also suspect you haven't used these addresses very much, because I've had
several addresses compromised by correspondents whose computers got infected
by harvesting malware, which is a very real problem.
>There are some addresses that have been used to post
>essentially a *single* posting on a public webpage, and
>they end up getting spammed regularly.
My own webpage addresses get relatively little spam.
>Whether or not a person philosophically "feels better" not
>consciously restricting the public distribution of an email
>address because to them it feels like "giving in to spammers",
>the simple fact is that in general, publicizing an email
>address is almost guaranteed to get it spammed.
Not necessarily.
John Navas
In <MPG.1ebb670d3...@News.Individual.Net> on Fri, 28 Apr 2006
00:41:39 -0700, Philip J. Koenig <See_email_@ddress_below.This_one_is.invalid>
wrote:
>Now if we all had highly-effective anti-spam systems, that
>wouldn't be such a big problem perhaps, but unfortunately
>lots of people don't.
Highly-effective anti-spam systems are in fact widely deployed by many (most?)
email providers.
John Navas
In <n712525ftoha853fq...@4ax.com> on Thu, 27 Apr 2006 11:18:32
-0700, JC Dill <jcd...@gmail.com> wrote:
>On Tue, 25 Apr 2006 12:45:09 -0700, Philip J. Koenig
><See_email_@ddress_below.This_one_is.invalid> wrote:
>
>>On Tue, 25 Apr 2006 11:54:38 -0700, in article
>><ooqs42ppqlch3khs7...@4ax.com>, JC Dill writes...
>>
>>> On Tue, 25 Apr 2006 03:01:51 -0700, Philip J. Koenig
>>> <See_email_@ddress_below.This_one_is.invalid> wrote:
>>>
>>> >Apparently Comcast is using a simplistic set of rules
>>> >to parse the PTR record, and apparently if it contains
>>> >(as in this case) a string "dsl", they assume it's a
>>> >"residential" or "dynamic" address.
>>>
>>> This is not uncommon.
>>
>>It might be common, but it's still pretty dumb. You
>>can have extremely effective anti-spam measures without
>>resorting to that sort of nonsense.
>
>It's not nonsense. It blocks a LOT of spam and very little non-spam.
It all depends on what you mean by "very little", and whether you are speaking
only for yourself or presuming to speak for everyone else. From my own point
of view, and that of many of my friends, clients, and associates, it actually
blocks way too much non-spam. So please feel free to use it yourself, but
don't presume to speak for the rest of us.
>>There are plenty of ways of knowing. (if they were so inclined)
>>It just isn't as trivial and quick as they would like so that
>>it can be done during an SMTP handshake the way they would
>>prefer.
>
>They don't have time to do anything more time-intensive.
With all due respect, that's a cop out -- you're now arguing efficiency rather
than effectiveness.
>You OTOH,
>can spend a small amount of time to change the PTR of your IP address
>and avoid these types of blocks.
Maybe yes, maybe no, but there's no good reason to do that outside of an
Internet Standard, Draft, or RFC that endorses the practice. The relevant
document in this case is RFC 2505 "Anti-Spam Recommendations for SMTP MTAs",
which discusses the pros and cons of FQDN checks, and which doesn't support
your contention.
>Anyone who doesn't have enough clue to get the PTR changed shouldn't
>be running a mail server, on a DSL address or elsewhere.
No offense, but that's the usual rubbish from self-annointed cognoscenti that
lack real clue themselves.
>>Nothing like burdening the victim with the fix.
>
>You move into a bad neighborhood, it's your problem. ...
Arrogant rubbish.
>>> Very little legitimate email will get caught by this type of
>>> filtering.
>>
>>I have a very hard time believing that.
>
>Too bad. It IS a common way spam is being sent today, and blocking
>this type of email blocks a lot of spam with very very few false
>positives.
To you, but not to many others, who find the false positive rate unacceptable.
Again, do whatever works for you, but don't presume to tell others what to do.
>> What's more, I also know
>>for a fact that you do not have to resort to such tactics to have
>>a superbly accurate antispam system. It really comes down to, in
>>my opinion, laziness and cost on the part of those who use such
>>tactics.
>
>They run their network with more cost effective measures than you
>think ideal? Too bad for you. Their network, their rules.
More of the usual rubbish from self-annointed cognoscenti that lack real clue
themselves. The Internet is run by consensus, not by vigilantes.
>>Up until a few weeks ago, the definition of "clue" in regards to
>>at least one particularly large US ISP changed dramatically. I
>>don't see anywhere in the RFC's where operators of MX hosts are
>>admonished not to ever allow a PTR record for an MX to contain
>>a string resembling "dsl". If you know otherwise, please advise.
>
>Their network, their rules. They get to decide what IPs they will let
>connect to their mail server. They don't need an RFC to "allow" them
>to filter out connections based on IPs or PTRs.
That's chaos. The Internet is run by consensus, not by vigilantes.
>>Translation: they want a quick, easy and cheap system. (they
>>probably also don't want to pay for the usage of the DUL either.
>>What a surprise.)
>
>Your translation is bullshit. ...
I think it's right on the money.
>You are just whining because you didn't know to change your PTR. Your
>ignorance isn't something everyone else is supposed to work around.
You have that backwards. Others aren't required to conform to your notion of
how the Internet should work. That's why we have the IETF, and the
RFC/Standards process. If you really think your idea is so great, then follow
the accepted procedures and see if it flies.
>>> *Usually* these additional blocks are generated by looking at the IPs
>>> that actually send spam.
>>
>>For some reason that doesn't sound particularly plausible in this
>>case.
>
>Are you really stupid, or do you just play stupid on ba.internet?
>
>When a trojan compromised PC *anywhere* in your ISPs DSL system with
>an IP such as 111-222-333-444.dsl.[isp].net sent spam, examining that
>spam would trigger the addition of 111-222-333-444.dsl.[isp].net rules
Not necessarily -- there are more intelligent ways to deal with the issue.
>to the netblock filter. (Actually, the rule added would probably be
>111-222-333-444.dsl.*, applying to ALL ISPs and not just to your ISP.)
That would be reckless and unwarranted.
>Said filter would then block all further spam emiting from this one
>trojan compromised PC as well as future spam emiting from other trojan
>compromised PCs in neighboring IPs and similar IPs at other ISPs.
At a great cost in collateral damage. In other words, a bad idea.
>>A lot of people are pretty desperate these days to block
>>junkmail, and a lot of Comcast's customers aren't particularly
>>sophisticated internet users, so those factors contributing
>>to Comcast's customers being "happy" about their status-quo
>>doesn't exactly represent a particularly compelling argument
>>for what they're doing.
>
>They are making their customers happy. If this serves Comcast and
>Comcast's customers well, then who are you to whine?
Assumes facts not in evidence. In fact there are many Comcast customers happy
with blocked legitimate email.
>>Another fun fact: guess which network is the largest global
>>source of zombie-originated spam? Comcast.
>>
>>http://tqmcube.com/zombies.php
>
>That doesn't surprise me in the least. They are focusing their
>efforts on protecting their customers, not on protecting the rest of
>the net. Other networks block "direct-to-mx" emiting from Comcast.
>Such is the state of fighting spam today.
Pretty pathetic. Not worthy of defense.
John Navas
In <2sc252trdjlv2b4p1...@4ax.com> on Thu, 27 Apr 2006 14:12:22
-0700, JC Dill <jcd...@gmail.com> wrote:
>On Thu, 27 Apr 2006 15:22:40 -0400, Javier <jav...@invalid.invalid>
>wrote:
>
>>> Anyone who doesn't have enough clue to get the PTR changed shouldn't
>>> be running a mail server, on a DSL address or elsewhere.
>>
>>I claim to have enough clues to run my own MTA, but Bellsouth won't set
>>the PTR record for the IP address statically assigned to me [1] to
>>reflect a hostname of my choice. The invoked reason: service not
>>available for home accounts.
>
>Which means that they don't want you running a mail server (or perhaps
>*any* server, ...
Not necessarily -- PTR service may simply not be provided.
John Navas
In <04u5525n0oc6suhvt...@4ax.com> on Fri, 28 Apr 2006 23:50:38
-0700, JC Dill <jcd...@gmail.com> wrote:
>On Thu, 27 Apr 2006 22:04:22 -0700, Philip J. Koenig
><See_email_@ddress_below.This_one_is.invalid> wrote:
>>> Anything with a default PTR that identifies it as being part of a DSL
>>> block with default addressing.
>>
>>And what would the rules for that be, and where is it written?
>
>Comcast isn't under any obligation to disclose this. But this system
>is widely used by network and mail server admins, google and learn.
Not really. RFC and learn.
>>Furthermore, you are changing the terms here. Comcast claims
>>it is blocking "residential IPs" (says right in the bounce
>>message), and they were clearly wrong in this case. Why should
>>innocent sites suffer for bad judgement on the part of the
>>recipient site?
>
>Your IP is in a block they identified as being a residential IP block,
>based on the PTR.
There is no such Standard, much less an RFC.
>>Oftentimes users do not have control or influence over the
>>in-arpa zone for their IP, and that simple fact does not
>>make them a spammer with no business running an MTA.
>
>Your argument that this is inconvenient for some is like the old
>argument that closing open relay mail servers would be inconvenient.
>The net has changed, open relays are no longer feasible. Putting a
>mail server on an IP that identifies itself as being part of a generic
>DSL block is the same type of problem. The days when you can do that
>and not get blocked are ending. You have to adapt to the changing
>face of the net.
Only when endorsed by accepted practice.
>>When such "laws" are codified in the RFC's, I'll give more
>>credence to them. Prior to that, I'll consider blocking
>>on such a basis rogue behaviour.
>
>You are spitting into the wind here. ISPs big and small are (and will
>continue) blocking using this method.
Not really.
>My research found that the first RFC to describe closing open relays
>was in ~2000, about 4 years after ISPs started closing open relays
>following the abuse by Spamford and company.
RFC 2505 "Anti-Spam Recommendations for SMTP MTAs" (Best Current Practice)
actually dates from February 1999, predating much of the implementation of
those practices. More to the point, no subsequent recommendations have been
promulgated.
>>Better methodologies exist, but apparently Comcast is either
>>too lazy or too cheap to use them.
>
>Better DSL lines exist (that make it easier for you to have a
>non-dynamic-ID-PTR) , but many DSL users are too lazy or too cheap to
>use them and persist in trying to run mail servers on cheap DSL lines
>that are IDd as being part of a block that consists of mainly Dynamic
>and Home DSL user.
Even if true (which it often isn't), that's irrelevant -- nowhere is it
written that they should have to conform to your ideas. They should only need
to conform to relevant Standards and Practices.
>>They are interfering with legitimate traffic originating from
>>legitimate senders all over the 'net, and as such it becomes
>>a public issue.
>
>No it doesn't. They serve their users with their rules. Their users
>are happy with the cost/benefit.
Many of them actually aren't.
>>Technically, spamming is not prohibited by RFC's either,
>
>You seem to have a basic misunderstanding of what RFCs are about.
>They are merely a way to describe a standard so that those who *want*
>to use the standard can, knowing that others will use it the same way.
>RFCs do not define the only "rules" that networks can use to decide
>when and how to exchange traffic with other networks.
>
>Many RFCs today are written after the fact, codifying practices that
>are already in place.
When those RFCs fail to endorse a practice, or when a practice runs contrary
to RFCs, as in this case, then that practice shouldn't be used.
>> Yeah, lots of the DNS BL's are crap, but
>>that doesn't prove a whole hell of a lot since DNS BL's are
>>pretty much what operators use when they don't want to make a
>>significant investment in a more sophisticated antispam system.
>
>Most ISPs use DNS BLs as a front line, and then have other filtering
>methods they use after they accept the email. The primary reason is
>that rejecting email before delivery is much less CPU, disk, and
>network intensive than accepting it and then filtering.
In other words, efficiency, not effectiveness. How nice. Not.
>>Your obnoxious characterization of my position
>
>Your position is "I want a big ISP to change their rules because it's
>inconvenient for me. I want them to spend a lot more money which
>benefits me (a non customer) and pass that costs onto their customer."
>
>Your position is selfish, and useless because the big ISPs don't care
>about your wants.
Nonsense. We just expect them to conform to Internet Standards and Practices,
and not create problems by going off on their own.
>>(apparently, just
>>because I disagree with you on some points which often are disagreed
>>upon by reasonable people),
>
>I've been fighting this fight against spam for a long long time. Most
>people, when faced with the problem you were faced with, once they
>understood why the large ISPs filter in this fashion go "oh, OK, that
>makes sense. I'll change my PTR. Thanks!" You didn't do that. You
>kept whining.
Only in your terms. There are many that find your kind of attitude offensive.
>Very few people involved in the fight to block/stop spam agree with
>your position. Most people readily understand why this type of
>blocking makes sense, doing the greatest good for the greatest number
>at the lowest cost possible and providing reasonable work arounds for
>the few who are inconvenienced.
I disagree.
>>#1, the host in question was not trojaned
>
>That Does Not Matter. It is in a bad neighborhood.
Meaningless.
>>#2, the host in question had not, to our knowledge, been
>> the source of any spam. (nor was it was not on anyone
>> else's DNS BL that I can find, other than triggering
>> Comcast's bounce prior to when the PTR record was changed)
>
>That Does Not Matter. It is in a bad neighborhood.
Meaningless.
>>Brilliant idea, Not. TTBOWTBW again. (Throwing The Baby Out With
>>The Bathwater)
>
>These rules throw out a LOT more spam than they generate false
>positives.
It's important that they *not* generate false positives, not just that you
think the rate is OK.
>ISP customer by-and-large are VERY happy to have these
>types of rules implemented to help stop spam and are willing to deal
>with the occasional problem such as when someone like you has
>difficulty emailing them.
I disagree -- most people I know get very upset when legitimate email is
blocked.
>>> Said filter would then block all further spam emiting from this one
>>> trojan compromised PC as well as future spam emiting from other trojan
>>> compromised PCs in neighboring IPs and similar IPs at other ISPs.
>>
>>As well as a fair bit of legitimate traffic.
>
>No, as well as almost NO legitimate traffic, which is why such rules
>are used.
Simply not true.
>I've said this before, and you seem to be ignoring it. Please pay
>attention. This is an important fact and if you disagree with it as a
>FACT then go find some data to back up your position.
It's not a "fact" -- it's your unsupported contention.
>> Why not simply
>>block all credit cards with numbers starting with "4454" when
>>the credit-card processor discovers a single fraudulent
>>transaction from a card number beginning with that integer?
>
>Because such a rule would generate a large number of false positives.
>This filter that ISPs are using generates very few false positives.
In your opinion. Not in the opinion of other. Don't presume to speak for the
rest of us.
>>Too bad for the millions of legitimate card-holders.. they're
>>just "whiners"!
>
>There are no "millions of DSL users" inconvenienced by these filters.
>99.999% of DSL users on dynamic-addressed and/or default PTRd IPs use
>their ISPs mail server and are thus not inconvenienced by these
>filters *at* *all*.
Actually there are many users hurt (not "inconvenienced") by these filters, as
I know from having to deal with the fallout.
>>When their procedures interfere with legitimate communications.
>
>Their network, their rules. They feel that the rare interference is
>acceptable because these rules filter out a LOT of spam.
That's not how the Internet works.
>>How quickly you come to Comcast's defense on such matters,
>
>I'm not defending them, I'm explaining how they (and other large ISPs)
>operate.
How you think they operate. This practice is actually unusual
>>Do
>>they not monitor outgoing bulk mail sent through their own
>>MTA's? Sounds pretty damn irresponsible to me, by both
>>conventional and modern 'net wisdom.
>
>I agree.
>
>Unfortunately, the other large networks (who are best able to affect
>this type of behavior) don't have much higher ground on which to speak
>about "how it should be done". All of them have their sins, none of
>them are in a very good position to cast the first stone at others for
>their alleged failure to Do The Right Thing.
That doesn't justify this kind of vigilantism.
John Navas
In <e2sj41$ebk$1...@blue.rahul.net> on Fri, 28 Apr 2006 08:18:09 +0000 (UTC),
c.c....@XReXXComca.usenet.us.com (Rahul Dhesi) wrote:
Wasn't clear to me either. Communication only works when the communicator is
concerned about the delivery of the message. Simply sending is a pointless
exercise.
Gandalf Parker
news:BZw5g.15878$Fs1...@bgtnsc05-news.ops.worldnet.att.net:
> [POSTED TO ba.internet - REPLY ON USENET PLEASE]
>
> In <MPG.1ebb35768...@News.Individual.Net> on Thu, 27 Apr
> 2006 21:10:08 -0700, Philip J. Koenig
> <See_email_@ddress_below.This_one_is.invalid> wrote:
>
>>Actually you are. Once upon a time, it was standard practice
>>to publish email addresses in clear text on web pages. Today
>>no webmaster in their right mind does such a thing because
>>the email address is immediately spidered/harvested/sold to
>>spammers and scammers.
>
> That's conventional wisdom of self-annointed cognoscenti, but I've not
> seen a significant actual problem from web-posted email addresses in
> tests I've run. Addresses tend to get compromised in other ways,
> either by naively entering them in software and/or website
> registrations, by the results of dictionary attacks, by inside selling
> of email address lists, by malware harvesting on infected computers,
> and the like.
Pros and Cons. Its like the fact that telnet isnt a danger anymore in any
tests that are done.
It used to be that you could go to a search engine and do a search on the
@ sign. Now no decent search engine will return anything on that search.
Also any search for mailto: tends to only gives you pages about mailto.
But there are still harvesters out there that run specifically in
violation of accepted harvester rules for obvious malicious purposes. I
havent run a MalHarvester check in quite awhile though (hits on a page
that is behind a robot.txt, etc) so even that might be old tactics that
have been dropped. But of course, like telnet, if recommendations started
putting it back in use then it would also go back into abuse. Come to
think of it, for the same reasons. Plain text.
Cry about "security thru obscurity" all you want but it is a factor.
(sorry, didnt mean to jump in on the local Cecil and Ebert entertainment)
Gandalf Parker
--
Jesus loves me this I know
cause the internet told me so
little kids to him belong
but dont give out your address at home
Gandalf Parker
contributed wisdom to
news:MPG.1ebb670d3...@News.Individual.Net:
> On Fri, 28 Apr 2006 00:20:21 -0700, in article
> <Pine.LNX.4.64.06...@enhance.cernio.com>, Graham Freeman
> writes...
>
>> On Thu, 27 Apr 2006, Philip J. Koenig wrote:
>>
>> I think you're over-stating things. I never munge addresses, since I
>> refuse to allow spammers and their ilk ruin the utility of email for
>> me. I don't receive noticably more spam at the published addresses
>> than I do at the unpublished ones. Harvesting from web sites is just
>> one method used by spammers - dictionary attacks and other email
>> identification methods are in widespread use as well.
>
> My experience is vastly different. I have many email
> addresses, some of which have been used publicly in
> certain different ways, some of which have never been
> used publicly.
>
> The ones which have not been used publicly see ZERO spam
> traffic. And I mean absolutely zero, as in not a single
> spam message over multiple-year periods.
At some level I would have to consider that to be luck. Or maybe you are
tighter with the concept of "publicly" than I am. I also have a wide
range of addresses for varied levels of public use, and I have had good
luck with it. But it only takes one elist you are on to be suddenly
compromised by an exploit, or one friend with you in their address book
who gets caught on some windows crack, or for that matter just one friend
who includes you in a mass sending to all of their friends with the
latest joke they heard.
But an address CAN be kept clean. My best results have been to create
super-secret addresses which I read, funnel all of my junk addresses to
that, and never hit "reply" but cut-n-paste replies in a totally seperate
program (seperate OS in fact since I tend to read in linux and reply in
windows).
Of course, having my own server with any address for dozens of my domains
does help also :)
> Now if we all had highly-effective anti-spam systems, that
> wouldn't be such a big problem perhaps, but unfortunately
> lots of people don't.
Have you banged your head on the latest efforts yet? I had an email of
mine refused by AOL recently. I found that my DNS records were expected
to have special txt lines added. And apparently there are 3 different
methods of that being pursued. *sigh* my latest server os install changed
all of the accepted default programs for things like email, ftp, dns.
Time to relearn everything. Just having had my mid-century birthday has
me feeling like Im past relearning all this crap.
> I am often quite saddened by what the spammers and scammers
> have done to the internet - not necessarily always just from
> their direct actions, but even worse because of how certain
> entities manage to stifle in ever more expanding ways the
> promise of the 'net by portraying it as a "dangerous
> neighborhood" - essentially exploiting the image of rampant
> danger to clamp down on the free dissemination of information
> which has always been, to me, such an exciting aspect about
> the 'net.
>
> Sigh, indeed.
Internet is a long list of great ideas that were abused until it got shut
down for everyone.
Gandalf Parker
--
I remember when we didnt even have to lock our doors. We could leave our
keys out in plain sight. Any stranger was welcome to get a feed off of
us, or give us something to mail.
Ahh the old days of the Internet.
Philip J. Koenig
<grt552dco6nfrhf02...@4ax.com>, JC Dill writes...
> On Thu, 27 Apr 2006 22:04:22 -0700, Philip J. Koenig
> <See_email_@ddress_below.This_one_is.invalid> wrote:
>
> >I just love these "burden the victim" tactics.
>
> The victim here is not you, it is Comcast which has been bombarded
> with spam from your IP neighbors,
On what basis do you make this wild presumption?
> and Comcast's users which have said
> "filter that stuff so we don't get it in our inboxes".
And this one?
> Comcast is taking care of their customers first and foremost. They
> (and their customers) consider a few false positives to be OK. The
> customers don't want to spend more for a "better" solution, they think
> this works just fine.
That may be, but any large entity on the 'net also has a responsibility
to the rest of the world to act in accordance with accepted principles.
This is at the heart of what you love to crusade about, the spam problem.
The entire foundation of an "anti-spam crusader's crusade" to persuade,
cajole, and even threaten ISPs into compliance with certain "good
practices" revolves specifically around the premise that an ISP is just
as responsible to the "community as a whole" as they are to their own
users. Why this obvious and constantly-touted orthodoxy of the 'net
all the sudden goes out the window when it comes to over-zealous tactics
on the other side of the fence doesn't exactly reflect very well on
the credibility of those giving entities like Comcast a "get out of jail
free card" when they take the "kill the spammer" mentality too far.
> You think Comcast is being cheap because they won't pay for a more
> expensive filtering solution. Comcast thinks YOU are being cheap
Shaky presumption #1
> because you are trying to send email from an IP block that is
> overwhelmingly full of clueless people who have no business sending
> direct-to-MX email from their dynamic IPs.
Proven shaky presumption #2
> You want Comcast to spend
> millions to implement better filtering, Comcast wants you to take a
> few minutes to establish that you have clue by getting your IP to use
> a non-dynamic-PTR.
Comcast is being lazy, plain-and-simple.
> IMHO you are being very unreasonable.
This POV can seemingly only be harbored by those who feel that
"the spam war" singularly justifies lowering the standard of
responsibility to others on the net, as if to adopt the same
frame-of-mind that the spammers themselves have poisoned the
'net with. "The first casualty of war is the truth".
Philip J. Koenig
<04u5525n0oc6suhvt...@4ax.com>, JC Dill writes...
> On Thu, 27 Apr 2006 22:04:22 -0700, Philip J. Koenig
> <See_email_@ddress_below.This_one_is.invalid> wrote:
>
> >
> >> >I would also like to know what definition you are using for
> >> >"ordinary DSL address".
> >>
> >> Anything with a default PTR that identifies it as being part of a DSL
> >> block with default addressing.
> >
> >And what would the rules for that be, and where is it written?
>
> Comcast isn't under any obligation to disclose this. But this system
> is widely used by network and mail server admins, google and learn.
We've been through this already, oh pompous one. The simple fact
is, there is no "standard".
> >Furthermore, you are changing the terms here. Comcast claims
> >it is blocking "residential IPs" (says right in the bounce
> >message), and they were clearly wrong in this case. Why should
> >innocent sites suffer for bad judgement on the part of the
> >recipient site?
>
> Your IP is in a block they identified as being a residential IP block,
> based on the PTR.
And they were dead wrong. Victim gets to suffer, eh?
> This block might contain both residential and
> business IPs. Have you asked your provider? If so, your beef is with
> your provider mixing residential and business IPs in a single block
> using the same PTR addressing scheme.
Actually you are transferring the blame again. Shame on you.
> >> >> (which should never send email "direct-to-MX")
> >> >
> >> >Says who? I've been doing so for probably at least 5 years
> >> >now, and before that over ISDN. Methinks someone is thinking
> >> >more than a bit too simplistically here.
> >>
> >> Anyone who doesn't have enough clue to get the PTR changed shouldn't
> >> be running a mail server, on a DSL address or elsewhere.
> >
> >Oftentimes users do not have control or influence over the
> >in-arpa zone for their IP, and that simple fact does not
> >make them a spammer with no business running an MTA.
>
> Your argument that this is inconvenient for some is like the old
> argument that closing open relay mail servers would be inconvenient.
> The net has changed, open relays are no longer feasible. Putting a
> mail server on an IP that identifies itself as being part of a generic
> DSL block is the same type of problem. The days when you can do that
> and not get blocked are ending. You have to adapt to the changing
> face of the net.
As I said before, when the RFC's have changed to reflect this "rule",
then I'll pay attention then, not before.
> >When such "laws" are codified in the RFC's, I'll give more
> >credence to them. Prior to that, I'll consider blocking
> >on such a basis rogue behaviour.
>
> You are spitting into the wind here. ISPs big and small are (and will
> continue) blocking using this method.
And as such, they are rogue.
> My research found that the first RFC to describe closing open relays
> was in ~2000, about 4 years after ISPs started closing open relays
> following the abuse by Spamford and company.
What your research apparently doesn't show is that a very large
amount of legitimate traffic were carried by those open relays
at the time. Solutions have to be arrived at which not only
help address problems, but which also avoid unnecessary damage
to innocent parties. If blocking traffic from relays which
primarily carry legitimate traffic fails that test, then it
is premature to block traffic from them until a more accurate
and less damaging tactic is found.
> >Better methodologies exist, but apparently Comcast is either
> >too lazy or too cheap to use them.
>
> Better DSL lines exist (that make it easier for you to have a
> non-dynamic-ID-PTR) ,
This has absolutely no bearing on the case in question. The
problem was easy to solve once we were able to make some "guesses"
about what the rogue site (Comcast) was doing, no thanks to them.
>but many DSL users are too lazy or too cheap to
> use them and persist in trying to run mail servers on cheap DSL lines
> that are IDd as being part of a block that consists of mainly Dynamic
> and Home DSL user.
You may as well say that it's OK to arrest people simply because
their car is more than 10 years old and has a couple dents in it.
Your reasoning does not hold water, because there is no accepted
"rule" or "standard" that codifies these things the way you seem
to think they are codified.
> >They are interfering with legitimate traffic originating from
> >legitimate senders all over the 'net, and as such it becomes
> >a public issue.
>
> No it doesn't. They serve their users with their rules. Their users
> are happy with the cost/benefit.
Just as the anti-spam crusaders love to say constantly, operators
on the net have a responsibility not only to their own users, but
to the rest of us. Why this situational logic dictates throwing
out that basic premise when the "error" occurs on the other side
(of being overly zealous with "antispam" tactics resulting in
damage to legitimate traffic) bears close examination.
> >Technically, spamming is not prohibited by RFC's either,
>
> You seem to have a basic misunderstanding of what RFCs are about.
Educate us, oh pompous and supercilious one!
> They are merely a way to describe a standard so that those who *want*
> to use the standard can, knowing that others will use it the same way.
> RFCs do not define the only "rules" that networks can use to decide
> when and how to exchange traffic with other networks.
As you of course know, there are precious few "laws" online, which
is actually one of the advantages of the 'net as it has existed.
The closest we have are the RFC's, or perhaps certain national
laws that nations try to impose on things as they pass through
their borders. (usually without a lot of success) There is however
an expectation of mutual trust and respect, which has worked more-
or-less OK over the years, while freeing us all from the stifling
influence of "can't do this, can't do that". The beauty of it all
is that when most people agree that something is bad, something is
usually done about it. But when there is a lot of disagreement
about what is "bad" (ie how to format a PTR record) then, understandably,
there is not going to be a consensus, and thus no RFC either.
> Many RFCs today are written after the fact, codifying practices that
> are already in place.
True enough, but I have seen little interest (or any RFC drafts) trying
to stipulate how to format a PTR record to make it easy for sites to
filter on a "residential" hostname. There is too much ambiguity in
the whole concept for there to be much agreement on such a thing. (or
else an RFC would likely have been written on the subject years ago)
> >How is it that you appear to consider that the various DNS BL's
> >constitute the entire constellation of spam mitigation measures
> >available to ISPs?
>
> I never said that.
Yet by your statements (ie "...the lists ARE NOT COMPREHENSIVE
ENOUGH and adding IPs using this formula is A) very effective...")
imply that these DNS BL lists are so fundamentally important
that we must all adapt to their requirements or else the 'net
as we know it is somehow in danger. Given that there are many
other ways of spam blocking (many of which are demonstrably
superior in every way to simply relying on public DNS BLs), I
fail to see why the Chicken Little urgency is justified.
> DNS BLs are but one of the many tools large ISPs use to help filter
> out spam.
In fact as I recall most of the truly large ISPs don't really
rely on DNS BL's, at least as traditionally used, because their
volume of traffic would overwhelm most public DNS BLs. IIRC,
MAPS used to sell the right to download the entire database
to large ISPs, because of this particular problem. I was under
the impression that most public DNS BL's (at least in the past)
were not willing to do the same thing, for various propietary
and privacy reasons.
> > Yeah, lots of the DNS BL's are crap, but
> >that doesn't prove a whole hell of a lot since DNS BL's are
> >pretty much what operators use when they don't want to make a
> >significant investment in a more sophisticated antispam system.
>
> Most ISPs use DNS BLs as a front line, and then have other filtering
> methods they use after they accept the email. The primary reason is
> that rejecting email before delivery is much less CPU, disk, and
> network intensive than accepting it and then filtering.
In other words, it's cheaper to do it that way. (exactly what
I have been saying)
> >Your obnoxious characterization of my position
>
> Your position is "I want a big ISP to change their rules because it's
> inconvenient for me. I want them to spend a lot more money which
> benefits me (a non customer) and pass that costs onto their customer."
No that is not my position. I expect any operator on the net, and
particularly a large operator to:
1) Be responsible to others on the 'net
2) Be transparent in their policies
3) Give adequate and public notice of a change in policy that
will have broad implications to others
Comcast in my view failed in those 3 areas in regards to this
particular policy.
I also find it the height of hypocrisy to on the one hand,
argue that "cost and profit be damned" when demanding that
an ISP adhere to certain spam-mitigation policies, yet when
they are over-zealous about those policies, you jump back
to their defense with the justification that asking them to
be fair to legitimate users caught in the crossfire is now
unreasonable because it "costs them too much money".
> Your position is selfish, and useless because the big ISPs don't care
> about your wants.
You may as well argue that it's OK for Comcast to sign pink
contracts with spammers because they have no obligation to
any of us to be responsible about anything. You contradict
yourself to no end.
> >(apparently, just
> >because I disagree with you on some points which often are disagreed
> >upon by reasonable people),
>
> I've been fighting this fight against spam for a long long time. Most
> people, when faced with the problem you were faced with, once they
> understood why the large ISPs filter in this fashion go "oh, OK, that
> makes sense. I'll change my PTR. Thanks!" You didn't do that. You
> kept whining.
#1, your patronizing and supercilious tone does not help your cause.
#2, if Comcast were remotely transparent about their policies and
helpful to those caught in the crossfire, it might be a little
different. The problem is, they aren't. I don't appreciate any
entity imposing unilateral laws or actions on me without notice,
explanation or consent - whether it's a new federal tax, a new
email blocking rule, or UBE.
Why you are unwilling to give certain entities (ie spammers) an
inch in this respect, while willing to give other entities (ie
ISPs that obey certain anti-spam orthodoxy) essentially a "get
out of jail free card" is classic situational ethics.
> Very few people involved in the fight to block/stop spam agree with
> your position.
No surprise there - if the denizens of NANAE for example are any
indicator, the crowd loosely associated with the "anti-spam movement"
are some of the most stubborn, self-satisfied and condescending people
I have met online.
> Most people readily understand why this type of
> blocking makes sense, doing the greatest good for the greatest number
> at the lowest cost possible and providing reasonable work arounds for
> the few who are inconvenienced.
Showing clear disdain for the "inconvenienced" does not gain such
entities points in my book.
> >> When a trojan compromised PC *anywhere* in your ISPs DSL system with
> >> an IP such as 111-222-333-444.dsl.[isp].net sent spam, examining that
> >> spam would trigger the addition of 111-222-333-444.dsl.[isp].net rules
> >> to the netblock filter.
> >
> >
> >#1, the host in question was not trojaned
>
> That Does Not Matter. It is in a bad neighborhood.
And you are increasingly proving to be blinded by your own crusade.
> >#2, the host in question had not, to our knowledge, been
> > the source of any spam. (nor was it was not on anyone
> > else's DNS BL that I can find, other than triggering
> > Comcast's bounce prior to when the PTR record was changed)
>
> That Does Not Matter. It is in a bad neighborhood.
See above.
> >> (Actually, the rule added would probably be
> >> 111-222-333-444.dsl.*, applying to ALL ISPs and not just to your ISP.)
> >
> >Brilliant idea, Not. TTBOWTBW again. (Throwing The Baby Out With
> >The Bathwater)
>
> These rules throw out a LOT more spam than they generate false
> positives.
So what? That you could eliminate all infected limbs after surgery
by amputating them does not suggest that amputating all limbs is a
good idea.
> ISP customer by-and-large are VERY happy to have these
> types of rules implemented to help stop spam and are willing to deal
> with the occasional problem such as when someone like you has
> difficulty emailing them.
Unfortunately for us, the vast majority of users simply do not see or
understand the big picture, and the fallout from such measures. Thus
they are poor indicators of what is a good policy or not. Typical
Comcast users don't how to administrate an IP router either, so
presuming their continued patronage somehow proves that we are doing
a good job administrating X or Y is just mental masturbation.
> There is no TTBOWTBW here.
Of course there is. Any time there are false positives, there is
TTBOWTBW.
> >> Said filter would then block all further spam emiting from this one
> >> trojan compromised PC as well as future spam emiting from other trojan
> >> compromised PCs in neighboring IPs and similar IPs at other ISPs.
> >
> >As well as a fair bit of legitimate traffic.
>
> No, as well as almost NO legitimate traffic, which is why such rules
> are used.
Strangely, I have already proven otherwise.
> I've said this before, and you seem to be ignoring it. Please pay
> attention. This is an important fact and if you disagree with it as a
> FACT then go find some data to back up your position.
>
> > Why not simply
> >block all credit cards with numbers starting with "4454" when
> >the credit-card processor discovers a single fraudulent
> >transaction from a card number beginning with that integer?
>
> Because such a rule would generate a large number of false positives.
> This filter that ISPs are using generates very few false positives.
Ah, so let's see if I've got this straight. It wouldn't be
OK to block all cards starting with 4454, but how about cards
starting with "4454 1101 5505...", if "only" 999 legitimate users
were affected? Is that now OK?
> >Too bad for the millions of legitimate card-holders.. they're
> >just "whiners"!
>
> There are no "millions of DSL users" inconvenienced by these filters.
> 99.999% of DSL users on dynamic-addressed and/or default PTRd IPs use
> their ISPs mail server and are thus not inconvenienced by these
> filters *at* *all*.
I'll reserve my judgement until I see accurate numbers.
Secondly, how difficult is it for an ISP to be transparent about
policies and helpful to those innocent users damaged by them? It
strikes me in the _very_ least as pompous and dismissive of the
needs of others to institute such things while making it very
difficult for users to figure out how to solve the problem.
(Probably laziness and laissez-faire more than anything)
> >> >A lot of people are pretty desperate these days to block
> >> >junkmail, and a lot of Comcast's customers aren't particularly
> >> >sophisticated internet users, so those factors contributing
> >> >to Comcast's customers being "happy" about their status-quo
> >> >doesn't exactly represent a particularly compelling argument
> >> >for what they're doing.
> >>
> >> They are making their customers happy. If this serves Comcast and
> >> Comcast's customers well, then who are you to whine?
> >
> >When their procedures interfere with legitimate communications.
>
> Their network, their rules. They feel that the rare interference is
> acceptable because these rules filter out a LOT of spam.
I wonder what you would say about someone who sold bandwidth to
spammers using the same argument: "my network, my rules!!"
Philip J. Koenig
199.245.68.61>, Gandalf Parker writes...
> Philip J. Koenig <See_email_@ddress_below.This_one_is.invalid>
> contributed wisdom to
> news:MPG.1ebb670d3...@News.Individual.Net:
>
> > On Fri, 28 Apr 2006 00:20:21 -0700, in article
> > <Pine.LNX.4.64.06...@enhance.cernio.com>, Graham Freeman
> > writes...
> >
> >> On Thu, 27 Apr 2006, Philip J. Koenig wrote:
> >>
> >> I think you're over-stating things. I never munge addresses, since I
> >> refuse to allow spammers and their ilk ruin the utility of email for
> >> me. I don't receive noticably more spam at the published addresses
> >> than I do at the unpublished ones. Harvesting from web sites is just
> >> one method used by spammers - dictionary attacks and other email
> >> identification methods are in widespread use as well.
> >
> > My experience is vastly different. I have many email
> > addresses, some of which have been used publicly in
> > certain different ways, some of which have never been
> > used publicly.
> >
> > The ones which have not been used publicly see ZERO spam
> > traffic. And I mean absolutely zero, as in not a single
> > spam message over multiple-year periods.
>
> At some level I would have to consider that to be luck. Or maybe you are
> tighter with the concept of "publicly" than I am.
As JN mentioned, I own and operate all the infrastructure for my
own domains and this has some bearing. Since I am not "[something]@
yahoo.net", there is some protection from insider trading of addresses,
likelihood of certain types of dictionary attacks, etc.
> I also have a wide
> range of addresses for varied levels of public use, and I have had good
> luck with it. But it only takes one elist you are on to be suddenly
> compromised by an exploit, or one friend with you in their address book
> who gets caught on some windows crack, or for that matter just one friend
> who includes you in a mass sending to all of their friends with the
> latest joke they heard.
Definitely true. But my point was not that keeping an address private
will guarantee it to be spam-free, but that:
> the simple fact is that in general, publicizing an email address is
> almost guaranteed to get it spammed.
So what we are really discussing here is the practical difference between
an address which will almost certainly get on spamlists (because it's
been publicized, ie posted in plain text on a popular webpage), and an
address which has not been publicized. I think it depends in large
measure on how your domain is hosted (ie just another address belonging
to a huge ISP, or an address on a small self-hosted domain) and whether
your spam-mitigation measures are effective (ie accurate) enough.
> But an address CAN be kept clean. My best results have been to create
> super-secret addresses which I read, funnel all of my junk addresses to
> that, and never hit "reply" but cut-n-paste replies in a totally seperate
> program (seperate OS in fact since I tend to read in linux and reply in
> windows).
>
> Of course, having my own server with any address for dozens of my domains
> does help also :)
Yep. For example, I have internal addresses that are only used
for receiving automated administrative messages, and are virtually
never used for sending email. Those addresses have been essentially
100% spam-free for years. This is not to say that there might be
ways to compromise them (ie a dictionary attack), but then again if
you have a habit of creating addresses like "bob@domain", then
that isn't too surprising either. :-)
> > Now if we all had highly-effective anti-spam systems, that
> > wouldn't be such a big problem perhaps, but unfortunately
> > lots of people don't.
>
> Have you banged your head on the latest efforts yet? I had an email of
> mine refused by AOL recently. I found that my DNS records were expected
> to have special txt lines added. And apparently there are 3 different
> methods of that being pursued. *sigh* my latest server os install changed
> all of the accepted default programs for things like email, ftp, dns.
> Time to relearn everything. Just having had my mid-century birthday has
> me feeling like Im past relearning all this crap.
Luckily the new DNS records aren't too complex. It's stuff like
the transition to IPv6 that I think will be a bit more problematic
because of the need to throw out things in phases and ensure that
the routing path is all compliant.
Speaking of "banging my head on the latest efforts", you might
want to read the original post in this thread. :-)
> > I am often quite saddened by what the spammers and scammers
> > have done to the internet - not necessarily always just from
> > their direct actions, but even worse because of how certain
> > entities manage to stifle in ever more expanding ways the
> > promise of the 'net by portraying it as a "dangerous
> > neighborhood" - essentially exploiting the image of rampant
> > danger to clamp down on the free dissemination of information
> > which has always been, to me, such an exciting aspect about
> > the 'net.
> >
> > Sigh, indeed.
>
> Internet is a long list of great ideas that were abused until it got shut
> down for everyone.
Makes you wonder.
Philip J. Koenig
news.ops.worldnet.att.net>, John Navas writes...
> In <MPG.1ebb35768...@News.Individual.Net> on Thu, 27 Apr 2006
> 21:10:08 -0700, Philip J. Koenig <See_email_@ddress_below.This_one_is.invalid>
> wrote:
>
> >Actually you are. Once upon a time, it was standard practice
> >to publish email addresses in clear text on web pages. Today
> >no webmaster in their right mind does such a thing because
> >the email address is immediately spidered/harvested/sold to
> >spammers and scammers.
>
> That's conventional wisdom of self-annointed cognoscenti, but I've not seen a
> significant actual problem from web-posted email addresses in tests I've run.
I have personal experience with this because I have created a number
of addresses that have been used only for very limited purposes, in
order to track this sort of thing. Most of the ones that have had
one or more messages posted on public webpages ended up on spamlists.
Others which have never been used in that way (or otherwise publicized)
remained clean. Certainly makes sense to me.
> Addresses tend to get compromised in other ways, either by naively entering
> them in software and/or website registrations, by the results of dictionary
> attacks, by inside selling of email address lists, by malware harvesting on
> infected computers, and the like.
Those are certainly factors, and today the last mentioned may be more
significant in particular because of all the "spam malware" that is
now circulating, but webpage harvesting, as far as I can tell, is a
definite reality.
Gandalf Parker
> Speaking of "banging my head on the latest efforts", you might
> want to read the original post in this thread. :-)
My apologies. Yes I was jumping in late. It just caught my eye about emails
on spam lists.
Im still trying to figure out why AOL wont clear my system. Apparently they
dont feel that they are talking to the systems admin. Im trying different
methods now to try and contact them "properly"
Gandalf Parker
John Navas
In <MPG.1ec8b1a2d...@News.Individual.Net> on Mon, 8 May 2006
02:39:24 -0700, Philip J. Koenig <See_email_@ddress_below.This_one_is.invalid>
wrote:
>Those are certainly factors, and today the last mentioned may be more
>significant in particular because of all the "spam malware" that is
>now circulating, but webpage harvesting, as far as I can tell, is a
>definite reality.
While I don't doubt your experience, my experience is quite different -- I've
got a number of addresses that have been posted in mailto: links on webpages
for years, and they only get a modest amount of spam, less than that on
addresses I've used in Usenet postings. The majority of the spam I get seems
to have come from email address harvesting of my correspondents that have had
infected computers.
John Navas
In <MPG.1ec898c66...@News.Individual.Net> on Mon, 8 May 2006
00:53:16 -0700, Philip J. Koenig <See_email_@ddress_below.This_one_is.invalid>
wrote:
>On Fri, 28 Apr 2006 22:24:03 -0700, in article
><grt552dco6nfrhf02...@4ax.com>, JC Dill writes...
>> IMHO you are being very unreasonable.
>
>This POV can seemingly only be harbored by those who feel that
>"the spam war" singularly justifies lowering the standard of
>responsibility to others on the net, as if to adopt the same
>frame-of-mind that the spammers themselves have poisoned the
>'net with. "The first casualty of war is the truth".
Worse than that: "The Spam War" (like the "Commie Menace" war of the '50's)
has quite clearly created an al too common mindset that pretty much anything
is OK against spammers, pretty much regardless of cost, and that anyone
objecting to those excesses is some sort of "spammer lover." Shades of Joseph
McCarthy.
John Navas
In <MPG.1ec8aa4ae...@News.Individual.Net> on Mon, 8 May 2006
02:08:01 -0700, Philip J. Koenig <See_email_@ddress_below.This_one_is.invalid>
wrote:
>> They are merely a way to describe a standard so that those who *want*
>> to use the standard can, knowing that others will use it the same way.
>> RFCs do not define the only "rules" that networks can use to decide
>> when and how to exchange traffic with other networks.
>
>As you of course know, there are precious few "laws" online, which
>is actually one of the advantages of the 'net as it has existed.
>The closest we have are the RFC's,
Actually the Internet Standards process, of which the RFCs are a part.
>or perhaps certain national
>laws that nations try to impose on things as they pass through
>their borders. (usually without a lot of success)
China and some other nations are actually quite successful. The open, free,
unregulated Internet has always been a myth.
>There is however
>an expectation of mutual trust and respect, which has worked more-
>or-less OK over the years, while freeing us all from the stifling
>influence of "can't do this, can't do that". The beauty of it all
>is that when most people agree that something is bad, something is
>usually done about it. But when there is a lot of disagreement
>about what is "bad" (ie how to format a PTR record) then, understandably,
>there is not going to be a consensus, and thus no RFC either.
Well said.
>> Many RFCs today are written after the fact, codifying practices that
>> are already in place.
>
>True enough, but I have seen little interest (or any RFC drafts) trying
>to stipulate how to format a PTR record to make it easy for sites to
>filter on a "residential" hostname. There is too much ambiguity in
>the whole concept for there to be much agreement on such a thing. (or
>else an RFC would likely have been written on the subject years ago)
The logical place would be RFC 2505 "Anti-Spam Recommendations for SMTP MTAs",
classified as "Best Current Practice". That PTR filtering isn't mentioned in
this or any other RFC makes it an experimental practice at best, but using it
undocumented in a large scale "live" system qualifies as rogue (IMnsHO).
>#1, your patronizing and supercilious tone does not help your cause.
Now that's funny! :)
JC Dill
<See_email_@ddress_below.This_one_is.invalid> wrote:
>On Fri, 28 Apr 2006 22:24:03 -0700, in article
><grt552dco6nfrhf02...@4ax.com>, JC Dill writes...
>
>> On Thu, 27 Apr 2006 22:04:22 -0700, Philip J. Koenig
>> <See_email_@ddress_below.This_one_is.invalid> wrote:
>>
>> >I just love these "burden the victim" tactics.
>>
>> The victim here is not you, it is Comcast which has been bombarded
>> with spam from your IP neighbors,
>
>
>On what basis do you make this wild presumption?
ISPs don't go out of their way to block legitimate email. They go out
of their way to block spammers. So, this filter WAS added because it
DID block spam.
>
>> and Comcast's users which have said
>> "filter that stuff so we don't get it in our inboxes".
>
>And this one?
Yep. Users today (as a group) gladly accept a certain percentage of
false positives when it means also blocking a lot of spam.
>> Comcast is taking care of their customers first and foremost. They
>> (and their customers) consider a few false positives to be OK. The
>> customers don't want to spend more for a "better" solution, they think
>> this works just fine.
>
>That may be, but any large entity on the 'net also has a responsibility
>to the rest of the world to act in accordance with accepted principles.
Bullshit.
They have a responsibility to their own customers. If their customers
like the service they are getting, then the network survives. If the
customers don't like the service they are getting, then the network
dies.
If the network is behaving irresposibily to other networks in what
they *send*, then the other networks will block them (sound familiar)?
Your argument isn't about what Comcast sends, it's about what they
elect to receive or not receive. They make their decision about what
to receive and what to put in their users inboxes based on what their
users (the people who PAY Comcast for their service) want.
>This is at the heart of what you love to crusade about, the spam problem.
>The entire foundation of an "anti-spam crusader's crusade" to persuade,
>cajole, and even threaten ISPs into compliance with certain "good
>practices" revolves specifically around the premise that an ISP is just
>as responsible to the "community as a whole" as they are to their own
>users.
What anti-spammers *want* and *how it actually works* are different.
If anti-spammers got what they wanted, spam would cease to exist. We
can dream, but that's not how the net works today.
> Why this obvious and constantly-touted orthodoxy of the 'net
>all the sudden goes out the window when it comes to over-zealous tactics
>on the other side of the fence doesn't exactly reflect very well on
>the credibility of those giving entities like Comcast a "get out of jail
>free card" when they take the "kill the spammer" mentality too far.
Anti-spammers aren't fond of filters with a high false-positive rate,
but they recognize that there's a limit to what an ISP will afford in
developing and maintaining their filters, and that there's always
going to be some false positives.
>> You think Comcast is being cheap because they won't pay for a more
>> expensive filtering solution. Comcast thinks YOU are being cheap
>
>Shaky presumption #1
Dead on presumption. If you sprang for the business class DSL service
designed for businesses that host their own servers, your situation
would not have happened.
>> because you are trying to send email from an IP block that is
>> overwhelmingly full of clueless people who have no business sending
>> direct-to-MX email from their dynamic IPs.
>
>Proven shaky presumption #2
Yes, it is proven that mail coming from IP blocks with a PTR such as
yours (when it was being blocked by Comcast) is overwhelmingly spam.
>> You want Comcast to spend
>> millions to implement better filtering, Comcast wants you to take a
>> few minutes to establish that you have clue by getting your IP to use
>> a non-dynamic-PTR.
>
>Comcast is being lazy, plain-and-simple.
No, they are being smart and prudent. Their method blocks a lot of
spam with very few false positives.
>> IMHO you are being very unreasonable.
>
>This POV can seemingly only be harbored by those who feel that
>"the spam war" singularly justifies lowering the standard of
>responsibility to others on the net, as if to adopt the same
>frame-of-mind that the spammers themselves have poisoned the
>'net with. "The first casualty of war is the truth".
You want everyone else to be more responsible than yourself. You want
them to incur additional expense in developing and maintaining spam
filters but are yourself unwilling to incure additional expense to
secure business class DSL to separate your legitimate mail server from
the trojan compromised spam spewing PCs of your DSL block neighbors.
Pot, Kettle, Black.
John Navas
In <69qu5251nvrbm2trc...@4ax.com> on Mon, 08 May 2006 09:01:55
-0700, JC Dill <jcd...@gmail.com> wrote:
>Yep. Users today (as a group) gladly accept a certain percentage of
>false positives when it means also blocking a lot of spam.
I strongly disagree -- I don't know of a single average user who would agree
with your statement. They expect their service providers to make best efforts
to avoid collateral damage, and to promptly remedy any damage that might
occur.
>>That may be, but any large entity on the 'net also has a responsibility
>>to the rest of the world to act in accordance with accepted principles.
>
>Bullshit.
That seems to pretty much sum up your point of view, making it unlikely that
there can be any sort of meaningful, reasonable dialog with you.
>Anti-spammers aren't fond of filters with a high false-positive rate,
>but they recognize that there's a limit to what an ISP will afford in
>developing and maintaining their filters, and that there's always
>going to be some false positives.
1. That's simply not true -- there are effective and practical filtering
methods with an essentially zero false positive rate.
2. That's also disingenuous -- you're arguing for an unnecessarily high false
positive rate, trying to justify it on grounds of economy and righteousness.
3. The way this is being done does a great disservice to those users Comcast
is professing to serve, because there is neither documentation nor
administration of the facility, thus making the harm worse than it needs to
be. That's simply inexcusable even for an experimental facility.
4. Comcast is actually acting contrary to the best interests and expectations
of its users, simply for its own convenience.
>Dead on presumption. If you sprang for the business class DSL service
>designed for businesses that host their own servers, your situation
>would not have happened.
Actually it can, but that's irrelevant, since there's not even a draft RFC in
support of this method -- you're trying to defend irresponsible, rogue
behavior.
>Yes, it is proven that mail coming from IP blocks with a PTR such as
>yours (when it was being blocked by Comcast) is overwhelmingly spam.
Bogus argument -- the great majority of all email is spam.
>>Comcast is being lazy, plain-and-simple.
>
>No, they are being smart and prudent. Their method blocks a lot of
>spam with very few false positives.
It is actually acting unreasonably and recklessly, not only because it is
using a poorly documented and administered system, but also because more
effective and less harmful methods are readily available.
>You want everyone else to be more responsible than yourself.
No, just responsible period. My own standard is much higher than that.
>You want
>them to incur additional expense in developing and maintaining spam
>filters
No, I would like them to use the best available methods, which are both
functionally and cost effective, but I at least expect them to properly
document what they are doing and to provide a reasonable way of working with
it.
>but are yourself unwilling to incure additional expense to
>secure business class DSL to separate your legitimate mail server from
>the trojan compromised spam spewing PCs of your DSL block neighbors.
Sorry, but there's no such accepted guideline, much less standard, on the
Internet. You're inventing something that simply doesn't exist.
>Pot, Kettle, Black.
Only by your personal standard. To the great majority of us this is simply
rogue behavior unless and until Comcast or you or someone else steps up to the
bar and subjects this to the RFC process.
JC Dill
<See_email_@ddress_below.This_one_is.invalid> wrote:
>On Fri, 28 Apr 2006 23:50:38 -0700, in article
><04u5525n0oc6suhvt...@4ax.com>, JC Dill writes...
>
>> Comcast isn't under any obligation to disclose this. But this system
>> is widely used by network and mail server admins, google and learn.
>
>We've been through this already, oh pompous one.
You can't handle the truth.
So instead of listening and learning, you lash out.
It must really suck to be so emotionally insecure that this is the
only way you can deal with information that goes against your ignorant
preconceptions and self-centeredness. My heart goes out to you and to
anyone who has to deal with you on a regular basis.
>The simple fact
>is, there is no "standard".
You obviously don't know a THING about how ISPs manage the spam load
that hits their servers. Anyone who does would never make the
statement you just made above.
You don't know what the most popular systems are, you don't know what
percentage of spam is blocked by different systems, you don't know
what the false positive rate is for different systems, you don't know
anything about what it is like to work in this role at an ISP.
>> >Furthermore, you are changing the terms here. Comcast claims
>> >it is blocking "residential IPs" (says right in the bounce
>> >message), and they were clearly wrong in this case. Why should
>> >innocent sites suffer for bad judgement on the part of the
>> >recipient site?
>>
>> Your IP is in a block they identified as being a residential IP block,
>> based on the PTR.
>
>And they were dead wrong. Victim gets to suffer, eh?
They were dead right. You were in a block that is identified as a
residential IP block. Your ISP didn't give you a business class DSL
IP, and they didn't tell you how to change your PTR to identify
yourself as a non-residential user, and YOU were too ignorant to
realize that this was essential if you wanted to reliably send email
from a server hosted on your residential-labeled IP.
They do NOT want to receive email sent "direct to mx" from residential
DSL IPs. If you aren't smart enough to understand this and fix the
problem, then they don't care that your email doesn't get thru.
>> This block might contain both residential and
>> business IPs. Have you asked your provider? If so, your beef is with
>> your provider mixing residential and business IPs in a single block
>> using the same PTR addressing scheme.
>
>Actually you are transferring the blame again. Shame on you.
No, the blame is yours for failing to secure business class IPs. You
were too cheap and too ignorant to properly secure the service level
that would have saved you from this problem.
>> Your argument that this is inconvenient for some is like the old
>> argument that closing open relay mail servers would be inconvenient.
>> The net has changed, open relays are no longer feasible. Putting a
>> mail server on an IP that identifies itself as being part of a generic
>> DSL block is the same type of problem. The days when you can do that
>> and not get blocked are ending. You have to adapt to the changing
>> face of the net.
>
>As I said before, when the RFC's have changed to reflect this "rule",
>then I'll pay attention then, not before.
The net is changing, and they (the big networks) don't care if there
are RFCs or not. They couldn't care less if you want to "pay
attention" to how they do things. It's your loss (your email that
gets blocked).
>> >When such "laws" are codified in the RFC's, I'll give more
>> >credence to them. Prior to that, I'll consider blocking
>> >on such a basis rogue behaviour.
>>
>> You are spitting into the wind here. ISPs big and small are (and will
>> continue) blocking using this method.
>
>And as such, they are rogue.
They are the net as it is today. Learn to deal with it.
>> My research found that the first RFC to describe closing open relays
>> was in ~2000, about 4 years after ISPs started closing open relays
>> following the abuse by Spamford and company.
>
>What your research apparently doesn't show is that a very large
>amount of legitimate traffic were carried by those open relays
>at the time.
What I know (because I was working at ISPs at the time) is that large
ISPs were closing open relays in starting in 1997 and 1998. Yet the
RFC didn't come out until 2000.
Netcom was relatively late to the game, here's an announcement from
January 1998 that they are going to close their open relays by the end
of February 1998 (more than 2 years before the RFC):
<http://groups.google.com/group/news.admin.net-abuse.email/msg/102c381b7a0a11e9?dmode=source&hl=en>
>Solutions have to be arrived at which not only
>help address problems, but which also avoid unnecessary damage
>to innocent parties. If blocking traffic from relays which
>primarily carry legitimate traffic fails that test, then it
>is premature to block traffic from them until a more accurate
>and less damaging tactic is found.
That's not how it works.
They considered the damage of closing open relays against the damage
of leaving them open (and spewing spam). When leaving them open
causes *more* damage, then open relays got closed. This happened
years before it was codified in an RFC.
Today, letting a consumer DSL line send "direct to MX" email to a user
will result in *much* more damage (spam received) than blocking all
email from that type of DSL line.
>> >Better methodologies exist, but apparently Comcast is either
>> >too lazy or too cheap to use them.
>>
>> Better DSL lines exist (that make it easier for you to have a
>> non-dynamic-ID-PTR) ,
>
>This has absolutely no bearing on the case in question.
It has EVERY bearing on the case in question.
> >but many DSL users are too lazy or too cheap to
>> use them and persist in trying to run mail servers on cheap DSL lines
>> that are IDd as being part of a block that consists of mainly Dynamic
>> and Home DSL user.
>
>You may as well say that it's OK to arrest people simply because
>their car is more than 10 years old and has a couple dents in it.
>Your reasoning does not hold water, because there is no accepted
>"rule" or "standard" that codifies these things the way you seem
>to think they are codified.
Your analogy doesn't compare.
Blocking email isn't the same as arresting people.
There IS a standard to block email this way. Ask anyone who manages a
large ISPs mail filters. Just because it isn't codified in an RFC
doesn't mean that this is a rogue action - all the large ISPs are
doing it which means *most* of the internet is doing it. They don't
need to wait for RFCs to decide what email they accept and deliver to
their own users today.
>> >They are interfering with legitimate traffic originating from
>> >legitimate senders all over the 'net, and as such it becomes
>> >a public issue.
>>
>> No it doesn't. They serve their users with their rules. Their users
>> are happy with the cost/benefit.
>
>Just as the anti-spam crusaders love to say constantly, operators
>on the net have a responsibility not only to their own users, but
>to the rest of us. Why this situational logic dictates throwing
>out that basic premise when the "error" occurs on the other side
>(of being overly zealous with "antispam" tactics resulting in
>damage to legitimate traffic) bears close examination.
Why do you want large ISPs to have a responsibility to do something
expensive "not only for their own users, but for the rest of us" yet
you are unwilling to be responsible in the same way for your own
economic choice to try to run a mail server on a consumer IDd DSL
line?
>> >Technically, spamming is not prohibited by RFC's either,
>>
>> You seem to have a basic misunderstanding of what RFCs are about.
>
>Educate us,
I did, right below.
>> They are merely a way to describe a standard so that those who *want*
>> to use the standard can, knowing that others will use it the same way.
>> RFCs do not define the only "rules" that networks can use to decide
>> when and how to exchange traffic with other networks.
>
>As you of course know, there are precious few "laws" online, which
>is actually one of the advantages of the 'net as it has existed.
>The closest we have are the RFC's, or perhaps certain national
>laws that nations try to impose on things as they pass through
>their borders. (usually without a lot of success) There is however
>an expectation of mutual trust and respect, which has worked more-
>or-less OK over the years, while freeing us all from the stifling
>influence of "can't do this, can't do that". The beauty of it all
>is that when most people agree that something is bad, something is
>usually done about it. But when there is a lot of disagreement
>about what is "bad" (ie how to format a PTR record) then, understandably,
>there is not going to be a consensus, and thus no RFC either.
Or, everyone is going to be too busy implementing the solution and no
one is going to waste their time writing up an RFC where one isn't
needed.
>> Many RFCs today are written after the fact, codifying practices that
>> are already in place.
>
>True enough, but I have seen little interest (or any RFC drafts) trying
>to stipulate how to format a PTR record to make it easy for sites to
>filter on a "residential" hostname. There is too much ambiguity in
>the whole concept for there to be much agreement on such a thing. (or
>else an RFC would likely have been written on the subject years ago)
There's little interest in writing such an RFC because the networks
who most need to follow it won't follow it.
Take a look at rfc-ignorant:
<http://www.rfc-ignorant.org/>
Networks today are by-and-large failing to care if their decisions
make things harder for others. That's why there's so much spam on the
net, and that's why stopping it is so hard.
>> >How is it that you appear to consider that the various DNS BL's
>> >constitute the entire constellation of spam mitigation measures
>> >available to ISPs?
>>
>> I never said that.
>
>Yet by your statements (ie "...the lists ARE NOT COMPREHENSIVE
>ENOUGH and adding IPs using this formula is A) very effective...")
>imply that these DNS BL lists are so fundamentally important
>that we must all adapt to their requirements or else the 'net
>as we know it is somehow in danger. Given that there are many
>other ways of spam blocking (many of which are demonstrably
>superior in every way to simply relying on public DNS BLs), I
>fail to see why the Chicken Little urgency is justified.
The other ways of blocking spam are far more costly.
Do you know what percentage of email deliveries attempted on a mail
server are spam?
Do you know the actual cost of rejecting email at the handshake?
Do you know the actual cost of accepting email and then filtering thru
some other means?
Do you know the cost of delivering spam to the end user's inbox, and
then fielding the support calls and having users leave (churn) because
they are getting too much spam?
Do you know how much spam costs an ISP?
If you knew these things, you would understand why it is critical to
reject spam at the earliest point possible.
>> DNS BLs are but one of the many tools large ISPs use to help filter
>> out spam.
>
>In fact as I recall most of the truly large ISPs don't really
>rely on DNS BL's, at least as traditionally used, because their
>volume of traffic would overwhelm most public DNS BLs.
They use local DNS BL filters (such as the one that blocked your
email) before submitting an IP to a DNS BL lookup. Then they cache
the lookup results so that they don't have to make a lookup for every
IP every time.
> IIRC,
>MAPS used to sell the right to download the entire database
>to large ISPs, because of this particular problem. I was under
>the impression that most public DNS BL's (at least in the past)
>were not willing to do the same thing, for various propietary
>and privacy reasons.
Which is why most ISPs are using this home-brewed solution.
>> > Yeah, lots of the DNS BL's are crap, but
>> >that doesn't prove a whole hell of a lot since DNS BL's are
>> >pretty much what operators use when they don't want to make a
>> >significant investment in a more sophisticated antispam system.
>>
>> Most ISPs use DNS BLs as a front line, and then have other filtering
>> methods they use after they accept the email. The primary reason is
>> that rejecting email before delivery is much less CPU, disk, and
>> network intensive than accepting it and then filtering.
>
>In other words, it's cheaper to do it that way. (exactly what
>I have been saying).
Yes, it is cheaper. Of course it's cheaper. That's prudent business.
>> >Your obnoxious characterization of my position
>>
>> Your position is "I want a big ISP to change their rules because it's
>> inconvenient for me. I want them to spend a lot more money which
>> benefits me (a non customer) and pass that costs onto their customer."
>
>No that is not my position. I expect any operator on the net, and
>particularly a large operator to:
>
>1) Be responsible to others on the 'net
Unfortunately, this hasn't been the case for many years.
>2) Be transparent in their policies
Transparent policies are becoming a thing of the past. Security by
obscurity isn't a very good form of security, but it's still widely
implemented in an attempt to slow down spammers from morphing their
techniques to evade the current security measures.
>3) Give adequate and public notice of a change in policy that
> will have broad implications to others
This change doesn't have "broad implications for others". It affects
very few, which is WHY a change like this was implemented - it's very
effective at blocking spam and has very few false positives.
>Comcast in my view failed in those 3 areas in regards to this
>particular policy.
It's the nature of the net today. Learn to live with it because
complaining about it isn't going to change a thing.
>I also find it the height of hypocrisy to on the one hand,
>argue that "cost and profit be damned" when demanding that
>an ISP adhere to certain spam-mitigation policies, yet when
>they are over-zealous about those policies, you jump back
>to their defense with the justification that asking them to
>be fair to legitimate users caught in the crossfire is now
>unreasonable because it "costs them too much money".
They *aren't* over zealous. Their spam-mitigation policies are very
prudent, with VERY few false positives from the type of filtering that
affected you. If this filtering caused widespread problems it
wouldn't be so prevalent.
The only (small) way they weren't "fair" to you was that you had to do
a bit of digging to find out that you needed to change your PTR. You
have certainly wasted far more time griping in this thread than it
took to discover and solve your problem, so clearly this wasn't a huge
problem for you.
>> Your position is selfish, and useless because the big ISPs don't care
>> about your wants.
>
>You may as well argue that it's OK for Comcast to sign pink
>contracts with spammers because they have no obligation to
>any of us to be responsible about anything. You contradict
>yourself to no end.
I'm not contradicting myself. You are creating a fictional argument,
ascribing it to me, and then blaming me for it. Clearly you are doing
this because sticking to the real arguments doesn't give you any other
way to attack me.
What one part of Comcast (their mail server admins) does is
acceptable. What another part of Comcast (their sales department that
might sign pink contracts) does might not be acceptable.
It *was* irresponsible of Comcast to let spam spew from their own
consumer customer IPs. In 2004 Comcast changed their filtering, they
now block port 25 so that a Comcast customer has to use Comcast's mail
server to relay the email, or they have to send email over a secure
protocol (port 587, port 465). They started by blocking high-volume
senders:
<http://news.com.com/2100-1038_3-5230615.html>
Today I believe they block all outbound connections to port 25. (I
discovered this because I have friends who have Comcast, I had to help
them reconfigure their email to use ports 587 or 465 so that they
could seamlessly send email from their laptops thru their work
servers from both work and home.)
If Comcast sales droids are signing pink contracts, then that's
irresponsible.
But just because one part of the business is irresponsible, I'm not
going to blame the responsible parts (the mail serve admins) for their
responsible actions to stem spam.
>> >(apparently, just
>> >because I disagree with you on some points which often are disagreed
>> >upon by reasonable people),
>>
>> I've been fighting this fight against spam for a long long time. Most
>> people, when faced with the problem you were faced with, once they
>> understood why the large ISPs filter in this fashion go "oh, OK, that
>> makes sense. I'll change my PTR. Thanks!" You didn't do that. You
>> kept whining.
>
>#1, your patronizing and supercilious tone does not help your cause.
That you don't like my tone doesn't concern me in the least. I don't
like your tone either. Your tone goes with your position, your
repeated whining that you don't want to be responsible for your
ignorance and your economic choices, but you want everyone else to pay
more instead so as to inconvenience you less.
>#2, if Comcast were remotely transparent about their policies and
>helpful to those caught in the crossfire, it might be a little
>different. The problem is, they aren't. I don't appreciate any
>entity imposing unilateral laws or actions on me without notice,
>explanation or consent - whether it's a new federal tax, a new
>email blocking rule, or UBE.
The net works in this way. Learn to live with it. New rules will be
implemented before RFCs exist. They don't have to notify you. You
will have to deal with it. Grow up and stop whining.
>Why you are unwilling to give certain entities (ie spammers) an
>inch in this respect, while willing to give other entities (ie
>ISPs that obey certain anti-spam orthodoxy) essentially a "get
>out of jail free card" is classic situational ethics.
I believe this policy (blocking email from IP blocks known to include
residential and consumer IPs that should not be sending email "direct
to mx") is a good policy and I applaud every ISP that implements it,
irrespective of their other policies that may or may not be policies I
agree with.
Just because I applaud them for this action doesn't mean I
automatically condone all other actions they take.
>> Very few people involved in the fight to block/stop spam agree with
>> your position.
>
>No surprise there - if the denizens of NANAE for example are any
>indicator, the crowd loosely associated with the "anti-spam movement"
>are some of the most stubborn, self-satisfied and condescending people
>I have met online.
>
>> Most people readily understand why this type of
>> blocking makes sense, doing the greatest good for the greatest number
>> at the lowest cost possible and providing reasonable work arounds for
>> the few who are inconvenienced.
>
>Showing clear disdain for the "inconvenienced" does not gain such
>entities points in my book.
How does this differ from your clear disdain for the inconvenience
(and considerable expense) that ISPs would experience if they changed
their filtering methods to no longer inconvenience you?
Pot, Kettle, Black
>> >> When a trojan compromised PC *anywhere* in your ISPs DSL system with
>> >> an IP such as 111-222-333-444.dsl.[isp].net sent spam, examining that
>> >> spam would trigger the addition of 111-222-333-444.dsl.[isp].net rules
>> >> to the netblock filter.
>> >
>> >#1, the host in question was not trojaned
>>
>> That Does Not Matter. It is in a bad neighborhood.
>
>And you are increasingly proving to be blinded by your own crusade.
I'm telling you how it is. Learn to live with it because "how it is"
isn't going to change just because you don't like it.
>> >#2, the host in question had not, to our knowledge, been
>> > the source of any spam. (nor was it was not on anyone
>> > else's DNS BL that I can find, other than triggering
>> > Comcast's bounce prior to when the PTR record was changed)
>>
>> That Does Not Matter. It is in a bad neighborhood.
>
>See above.
I'm telling you how it is. Learn to live with it because "how it is"
isn't going to change just because you don't like it.
>> >> (Actually, the rule added would probably be
>> >> 111-222-333-444.dsl.*, applying to ALL ISPs and not just to your ISP.)
>> >
>> >Brilliant idea, Not. TTBOWTBW again. (Throwing The Baby Out With
>> >The Bathwater)
>>
>> These rules throw out a LOT more spam than they generate false
>> positives.
>
>So what? That you could eliminate all infected limbs after surgery
>by amputating them does not suggest that amputating all limbs is a
>good idea.
Bad analogy again.
If a spam filtering rule throws out 100,000 spams for every non-spam
it catches as a "false positive", then the end users want that rule
implemented. If it's your email that gets caught, you get
inconvenienced. That's just how email delivery on the internet works
today.
>> ISP customer by-and-large are VERY happy to have these
>> types of rules implemented to help stop spam and are willing to deal
>> with the occasional problem such as when someone like you has
>> difficulty emailing them.
>
>Unfortunately for us, the vast majority of users simply do not see or
>understand the big picture, and the fallout from such measures.
They know that they don't want to pay a higher price each month for a
"better" solution.
> Thus
>they are poor indicators of what is a good policy or not. Typical
>Comcast users don't how to administrate an IP router either, so
>presuming their continued patronage somehow proves that we are doing
>a good job administrating X or Y is just mental masturbation.
Typical Comcast users are willing to put up with occasional mail
reception problems because they aren't willing to pay more for a
better service.
>> There is no TTBOWTBW here.
>
>Of course there is. Any time there are false positives, there is
>TTBOWTBW.
TTBOWTBW means that a large percentage of what you throw out is
desired (the baby).
There is no perfect way to filter out all spam and let all non-spam
thru. Users have decided that rather than filter 75% of the spam
(with no false positives) and deal with the flood of 25% of the spam
that evades those filters, they would rather have a filter system that
gets 99,99% of the spam and deal with the few false positives. Users
do NOT consider this TTBOWTBW. They think this is more like
occasionally losing the last sliver of soap when you dump out the bath
water, a small price to pay for the effectiveness of filtering out all
that spam.
>> >> Said filter would then block all further spam emiting from this one
>> >> trojan compromised PC as well as future spam emiting from other trojan
>> >> compromised PCs in neighboring IPs and similar IPs at other ISPs.
>> >
>> >As well as a fair bit of legitimate traffic.
>>
>> No, as well as almost NO legitimate traffic, which is why such rules
>> are used.
>
>Strangely, I have already proven otherwise.
No you haven't. It hasn't been proven otherwise by you or by anyone
else because it isn't true. These filters ARE very effective and DO
produce very FEW false positives.
>> I've said this before, and you seem to be ignoring it. Please pay
>> attention. This is an important fact and if you disagree with it as a
>> FACT then go find some data to back up your position.
Hmmm. You didn't find any data to back up your position. I stand by
my assertion. :-)
>> > Why not simply
>> >block all credit cards with numbers starting with "4454" when
>> >the credit-card processor discovers a single fraudulent
>> >transaction from a card number beginning with that integer?
>>
>> Because such a rule would generate a large number of false positives.
>> This filter that ISPs are using generates very few false positives.
>
>Ah, so let's see if I've got this straight. It wouldn't be
>OK to block all cards starting with 4454, but how about cards
>starting with "4454 1101 5505...", if "only" 999 legitimate users
>were affected? Is that now OK?
They wouldn't implement a filter like that unless A) it caught a lot
of problems and B) had very few false positives. If they did that, it
would be because the cost (to the false positive user) was lower than
the cost of letting all the other card transactions thru.
In many cases, banks DO temporarily block large numbers of CC
transactions due to a problem with only a few cards. They do this to
stop fraud.
>> >Too bad for the millions of legitimate card-holders.. they're
>> >just "whiners"!
>>
>> There are no "millions of DSL users" inconvenienced by these filters.
>> 99.999% of DSL users on dynamic-addressed and/or default PTRd IPs use
>> their ISPs mail server and are thus not inconvenienced by these
>> filters *at* *all*.
>
>I'll reserve my judgement until I see accurate numbers.
Do your own research and you will find out.
>Secondly, how difficult is it for an ISP to be transparent about
>policies and helpful to those innocent users damaged by them? It
>strikes me in the _very_ least as pompous and dismissive of the
>needs of others to institute such things while making it very
>difficult for users to figure out how to solve the problem.
>(Probably laziness and laissez-faire more than anything)
I addressed the problem with transparency above. It would be nice if
they could be transparent to non-spammers while keeping this
information hidden from spammers, but it doesn't work that way.
>> >> >A lot of people are pretty desperate these days to block
>> >> >junkmail, and a lot of Comcast's customers aren't particularly
>> >> >sophisticated internet users, so those factors contributing
>> >> >to Comcast's customers being "happy" about their status-quo
>> >> >doesn't exactly represent a particularly compelling argument
>> >> >for what they're doing.
>> >>
>> >> They are making their customers happy. If this serves Comcast and
>> >> Comcast's customers well, then who are you to whine?
>> >
>> >When their procedures interfere with legitimate communications.
>>
>> Their network, their rules. They feel that the rare interference is
>> acceptable because these rules filter out a LOT of spam.
>
>I wonder what you would say about someone who sold bandwidth to
>spammers using the same argument: "my network, my rules!!"
I'd say you have the right to block them.
Many networks do sell bandwidth to spammers, and many other networks
DO block them (using the same type of DSN BL that blocked your email).
The granularity of the blocks implemented by different ISPs run the
gamut from blocking individual IPs, to blocking /24s, to blocking
entire ISPs, to blocking entire countries. That's how it works today.
John Navas
In <0squ521s1lum6uae1...@4ax.com> on Mon, 08 May 2006 10:36:42
-0700, JC Dill <jcd...@gmail.com> wrote:
>Transparent policies are becoming a thing of the past. Security by
>obscurity isn't a very good form of security, but it's still widely
>implemented in an attempt to slow down spammers from morphing their
>techniques to evade the current security measures.
Nonsense -- security by obscurity is no security at all, often even
counterproductive, since it typically leads to a false sense of security.
I've already rebutted your other contentions.
JC Dill
<spamf...@navasgroup.com> wrote:
>[POSTED TO ba.internet - REPLY ON USENET PLEASE]
>
>In <0squ521s1lum6uae1...@4ax.com> on Mon, 08 May 2006 10:36:42
>-0700, JC Dill <jcd...@gmail.com> wrote:
>
>>Transparent policies are becoming a thing of the past. Security by
>>obscurity isn't a very good form of security, but it's still widely
>>implemented in an attempt to slow down spammers from morphing their
>>techniques to evade the current security measures.
>
>Nonsense -- security by obscurity is no security at all, often even
>counterproductive, since it typically leads to a false sense of security.
Security by obscurity is very effective - albeit not as effective as
many other (more secure) systems. Here's a great post that explains
why and how it works:
<http://lists.grok.org.uk/pipermail/full-disclosure/2004-September/026134.html>
<quote>
If security by obscurity _always_ sucks, then I hope that all the
readers of this post will send me detailed network diagrams, IPs and
passwords; also name, address and credit card number while you're at
it.
</quote>
John Navas
In <jf4v52p63stj6q5gd...@4ax.com> on Mon, 08 May 2006 11:48:08
-0700, JC Dill <jcd...@gmail.com> wrote:
>On Mon, 08 May 2006 18:01:39 GMT, John Navas
><spamf...@navasgroup.com> wrote:
>
>>In <0squ521s1lum6uae1...@4ax.com> on Mon, 08 May 2006 10:36:42
>>-0700, JC Dill <jcd...@gmail.com> wrote:
>>
>>>Transparent policies are becoming a thing of the past. Security by
>>>obscurity isn't a very good form of security, but it's still widely
>>>implemented in an attempt to slow down spammers from morphing their
>>>techniques to evade the current security measures.
>>
>>Nonsense -- security by obscurity is no security at all, often even
>>counterproductive, since it typically leads to a false sense of security.
>
>Security by obscurity is very effective - albeit not as effective as
>many other (more secure) systems. Here's a great post that explains
>why and how it works:
>
><http://lists.grok.org.uk/pipermail/full-disclosure/2004-September/026134.html>
>
><quote>
>If security by obscurity _always_ sucks, then I hope that all the
>readers of this post will send me detailed network diagrams, IPs and
>passwords; also name, address and credit card number while you're at
>it.
></quote>
Meaningless, because that's not the measure of security.
Here's an authoritative discussion by a real expert:
"Secrecy, Security, and Obscurity" by Bruce Schneier
<http://www.schneier.com/crypto-gram-0205.html#1>
Which concludes:
Kerckhoffs' Principle generalizes to the following design guideline:
minimize the number of secrets in your security system. To the extent
that you can accomplish that, you increase the robustness of your
security. To the extent you can't, you increase its fragility.
Obscuring system details is a separate decision from making your
system secure regardless of publication; it depends on the
availability of a community that can evaluate those details and the
relative communities of "good guys" and "bad guys" that can make use
of those details to secure other systems.
The very essence of the RFC process is the existence of such a community of
"good guys".
JC Dill
<spamf...@navasgroup.com> wrote:
>Meaningless, because that's not the measure of security.
>
>Here's an authoritative discussion by a real expert:
>"Secrecy, Security, and Obscurity" by Bruce Schneier
><http://www.schneier.com/crypto-gram-0205.html#1>
You are confusing security with cryptography.
From that very page, read:
<quote>
in a well-designed cryptographic system, only the key needs to be
secret; there should be no secrecy in the algorithm. Modern
cryptographers have embraced this principle, calling anything else
"security by obscurity."
</quote>
>Which concludes:
>
> Kerckhoffs' Principle generalizes to the following design guideline:
> minimize the number of secrets in your security system.
Bruce is talking here about systems that *can* use crypto. Notice his
discussion about airport security and his admission that there is no
way to encrypt all the secrets into a single "key". He says
<quote>
And that fragility is an inherent property of airline security.
</quote>
He doesn't say "is no security at all".
> To the extent
> that you can accomplish that, you increase the robustness of your
> security. To the extent you can't, you increase its fragility.
Yep, security by obscurity is fragile. But it IS still a form of
security, just not a very secure form.
> Obscuring system details is a separate decision from making your
> system secure regardless of publication; it depends on the
> availability of a community that can evaluate those details and the
> relative communities of "good guys" and "bad guys" that can make use
> of those details to secure other systems.
Those decisions are made by ISPs on a daily basis as they strive to
filter and block spam.
>The very essence of the RFC process is the existence of such a community of
>"good guys".
The bad guys can read RFCs too. Publishing an RFC has no effect at
all on if a given procedure is secure or not.
Back into the killfile with you.
John Navas
In <uh8v52l48or7p8tpi...@4ax.com> on Mon, 08 May 2006 13:01:54
-0700, JC Dill <jcd...@gmail.com> wrote:
>On Mon, 08 May 2006 19:02:08 GMT, John Navas
><spamf...@navasgroup.com> wrote:
>
>>Meaningless, because that's not the measure of security.
>>
>>Here's an authoritative discussion by a real expert:
>>"Secrecy, Security, and Obscurity" by Bruce Schneier
>><http://www.schneier.com/crypto-gram-0205.html#1>
>
>You are confusing security with cryptography.
No, I'm simply referencing a noted cryptographer that's also a noted security
expert. Read more carefully.
>From that very page, read:
>
><quote>
>
>in a well-designed cryptographic system, only the key needs to be
>secret; there should be no secrecy in the algorithm. Modern
>cryptographers have embraced this principle, calling anything else
>"security by obscurity."
>
></quote>
The note is about "security systems" in general. Cryptography is just one
application of security principles. Read more carefully.
>>Which concludes:
>>
>> Kerckhoffs' Principle generalizes to the following design guideline:
>> minimize the number of secrets in your security system.
Note: "security system"
>Bruce is talking here about systems that *can* use crypto.
No, he's talking about "security systems" in general, even pertaining to such
things as "missile guidance algorithms". Read more carefully.
>Notice his
>discussion about airport security and his admission that there is no
>way to encrypt all the secrets into a single "key". He says
>
><quote>
>And that fragility is an inherent property of airline security.
></quote>
>
>He doesn't say "is no security at all".
What he says is, "The fewer the secrets there are, the more secure the system
is." In other words, when you add secrets to a system, you make it less
secure. That's what makes "security by obscurity" an oxymoron.
>> To the extent
>> that you can accomplish that, you increase the robustness of your
>> security. To the extent you can't, you increase its fragility.
>
>Yep, security by obscurity is fragile. But it IS still a form of
>security, just not a very secure form.
Again, "The fewer the secrets there are, the more secure the system is."
In other words, when you add secrets to a system, you make it less secure.
That's what makes "security by obscurity" an oxymoron.
>> Obscuring system details is a separate decision from making your
>> system secure regardless of publication; it depends on the
>> availability of a community that can evaluate those details and the
>> relative communities of "good guys" and "bad guys" that can make use
>> of those details to secure other systems.
>
>Those decisions are made by ISPs on a daily basis as they strive to
>filter and block spam.
In most cases it's simply sloppiness, ignorance, and expedience, not to
mention naivete.
>>The very essence of the RFC process is the existence of such a community of
>>"good guys".
>
>The bad guys can read RFCs too. Publishing an RFC has no effect at
>all on if a given procedure is secure or not.
You've completely missed what Bruce Schneier is saying. Is it because you
simply don't read carefully enough, or is it a matter of denial?
>Back into the killfile with you.
Translation: My position's so unpersuasive that I'm going to again bury my
head in the sand. ;)
Glenn S. Tenney KCTJ CISSP CISM
John Navas <spamf...@navasgroup.com> wrote:
> What he says is, "The fewer the secrets there are, the more secure the system
> is." In other words, when you add secrets to a system, you make it less
> secure. That's what makes "security by obscurity" an oxymoron.
>
> In other words, when you add secrets to a system, you make it less secure.
> That's what makes "security by obscurity" an oxymoron.
"obscurity" is one of several tools that we security professionals
use... it is *not* in and of itself "security". The term "security BY
obscurity" relates to those situations (many as noted by Bruce) where
people mistakenly RELY on obscurity for their security.
For example: Keeping a company's internal network architecture (e.g.
machine names, etc.) "secret" is a reasonable best practice not because
it IS secure, but because it helps to keep some things secret to "raise
the cost" of insituting an attack.
Or, if one wants to help reduce the likelihood of being attacked, then
keeping the relationship to one's IP address might be of some help. It
can't be relied upon to stop an attack nor to reduce the effect of such
an attack -- i.e. it can't be used as a form of protection from any such
attack. But, in some situations it might help.
I believe it was you who doesn't want the IP addresses of their clients
made public. Since anyone on the Internet by definition has their IP
address "public", the reason for not associating their IP address with
you and or their company name is not solely for "privacy", but rather as
one of many security tools used to help make it less likely that those
clients will be attacked.
--
Glenn Tenney KCTJ CISSP CISM
The email address has been altered for display since spam
is not allowed here, but you can figure it out...
John Navas
In <tenney-576A5E....@nnrp-virt.nntp.sonic.net> on Mon, 08 May 2006
15:07:02 -0700, "Glenn S. Tenney KCTJ CISSP CISM" <ten...@org.think> wrote:
>In article <JVN7g.39757$Fs1....@bgtnsc05-news.ops.worldnet.att.net>,
> John Navas <spamf...@navasgroup.com> wrote:
>> What he says is, "The fewer the secrets there are, the more secure the system
>> is." In other words, when you add secrets to a system, you make it less
>> secure. That's what makes "security by obscurity" an oxymoron.
>>
>> Again, "The fewer the secrets there are, the more secure the system is."
>> In other words, when you add secrets to a system, you make it less secure.
>> That's what makes "security by obscurity" an oxymoron.
>
>"obscurity" is one of several tools that we security professionals
>use... it is *not* in and of itself "security". The term "security BY
>obscurity" relates to those situations (many as noted by Bruce) where
>people mistakenly RELY on obscurity for their security.
What Bruce Schneier explains in some detail
<http://www.schneier.com/crypto-gram-0205.html#1> is that, in addition to
improving security by minimizing the number of secrets in a system, disclosure
is a value proposition, balancing whatever security is lost by disclosure
against whatever value is gained by disclosure.
What's been proven over and over is that the benefits of disclosure (of
systems, not passwords) are almost always greater than the drawbacks.
>For example: Keeping a company's internal network architecture (e.g.
>machine names, etc.) "secret" is a reasonable best practice not because
>it IS secure, but because it helps to keep some things secret to "raise
>the cost" of insituting an attack.
Not necessarily. That cost differential is relatively small, and thus not
much to count on. On the other hand, by publishing (say) machine names we
remind ourselves that our security doesn't rely on machine naming, thus
reducing the chances of human error, and we make it possible for others to
alert us to possible weaknesses in our practices, which can be of real value.
I personally see no real value is disguising machine names. My own machine
name (at the moment) is "JTP". Are you really going to contend that I've now
somehow reduced my security? ;)
>Or, if one wants to help reduce the likelihood of being attacked, then
>keeping the relationship to one's IP address might be of some help. It
>can't be relied upon to stop an attack nor to reduce the effect of such
>an attack -- i.e. it can't be used as a form of protection from any such
>attack. But, in some situations it might help.
Perhaps, but again the difference is relatively small, and thus not much to
count on, as weighed against the risk of complacency.
Many of my clients start off saying, "there's no way to get through our
security", only to later blush when I show them how easy it actually is,
usually because of their complacency.
>I believe it was you who doesn't want the IP addresses of their clients
>made public.
No, what I said was that I wasn't willing to expose my clients to any risk for
no good reason. It's again a matter of a value proposition. I've already
disclosed the system, Internet email. Your suggestion is something akin to
publishing passwords.
>Since anyone on the Internet by definition has their IP
>address "public", the reason for not associating their IP address with
>you and or their company name is not solely for "privacy",
Really? Then you can of course identify them -- right? ;)
>but rather as
>one of many security tools used to help make it less likely that those
>clients will be attacked.
It's not an issue of attack -- it's an issue of privacy.
ka...@sonic.net
And you're able to reliably make this distinction? Yeah.
ka...@sonic.net
>On Mon, 08 May 2006 18:01:39 GMT, John Navas
><spamf...@navasgroup.com> wrote:
>
>>[POSTED TO ba.internet - REPLY ON USENET PLEASE]
>>
>>In <0squ521s1lum6uae1...@4ax.com> on Mon, 08 May 2006 10:36:42
>>-0700, JC Dill <jcd...@gmail.com> wrote:
>>
>>>Transparent policies are becoming a thing of the past. Security by
>>>obscurity isn't a very good form of security, but it's still widely
>>>implemented in an attempt to slow down spammers from morphing their
>>>techniques to evade the current security measures.
>>
>>Nonsense -- security by obscurity is no security at all, often even
>>counterproductive, since it typically leads to a false sense of security.
>
>Security by obscurity is very effective - albeit not as effective as
>many other (more secure) systems. Here's a great post that explains
>why and how it works:
>
><http://lists.grok.org.uk/pipermail/full-disclosure/2004-September/026134.html>
>
><quote>
>If security by obscurity _always_ sucks, then I hope that all the
>readers of this post will send me detailed network diagrams, IPs and
>passwords; also name, address and credit card number while you're at
>it.
></quote>
>
To the extent that John believes "security by obscurity is no
security at all", we can assume that the Password to all of his
accounts is JhnNavas" and he never uses anything other than "1234" for
a PIN.
Seems a bit contradictory for someone who recently contended
that quoting a single IP address would be a major breach of privacy. I
have to guess that it's a principle that applies only to his own
clients.
>jc
ka...@sonic.net
<spamf...@navasgroup.com> wrote:
That's a fr cry from your blatant assertion that "security by
obscurity is no security at all".
ka...@sonic.net
<spamf...@navasgroup.com> wrote:
<standard childisness about posting deleted>
>
>What he says is, "The fewer the secrets there are, the more secure the system
>is." In other words, when you add secrets to a system, you make it less
>secure. That's what makes "security by obscurity" an oxymoron.
Oxymoron entails inherent contradiction.
The hierarchy, for your benefit:
Strong security --
Security by obscurity -- lesser, though of some value.
"no security at all" (JN's words) -- not identical to
the previous item.
ka...@sonic.net
<spamf...@navasgroup.com> wrote:
<infantile, obsessive net-nannying deleted for the enjoyment of other
readers>
>
>You've completely missed what Bruce Schneier is saying. Is it because you
>simply don't read carefully enough, or is it a matter of denial?
Translation: only JN is capable of reading with comprehension
-- a tenuous position at best. And not nearly as subtle an ad hominem
as he believes it to be.
>
>>Back into the killfile with you.
>
>Translation: My position's so unpersuasive that I'm going to again bury my
>head in the sand. ;)
Translation: be a man -- go on a two week "business trip" when
your arguments run out of steam, as JN routinely does.