Usefulness of sorbs
linux...@yahoo.com
derived from the timleness and accuracy of the data contained, and that
it seems that sorbs has slipped into dysfunction with respect to the
accuracy and maintinence of their data.
My specfic complaint today is that sorbs is denying service to my users
because sorbs decided to list my mx, and is compounding the problem by
refusing to cooperate in correcting the error. The mx is 12.149.130.38,
'postoffice.willitsonline.com', and sorbs seems to think that this must
be dynamic space and therefore must be whacked. The evidence used by
sorbs, was based soley on reverse dns information, and for which this
IP did have a generic record due to a recent server move.
These dynamic lists were beleivable when we ISP's voluenteered the
information, because we could state with absolute authority what was
and what was not 'dynamic space'. But just comming along and deciding,
based simply on the one fact of a generic looking rdns record that the
space is dynamic, is technically flawed and is like saying the internet
is down just because you can't access some page and get an error
message.
There is a whole lot more network based tests that can be done to help
increase the confidence level of that determination, stating with
simple protocol and _asking_ the domain adminstrator (me). And if you
don't wish to be bothered because you think that a /27 out of the whole
internet represents a signifigant threat that must be crushed first and
no questions later ever, then at least you could bother to build into
your robot the tools for consulting whois as well as dig for mx records
and see what other support exists to suggest that perhaps the server in
question really is legitimate afterall. In particular, I know of few
real dynamic spaces that would contain valid mx records for the whole
of the domain such as willitsonline.com, and espically if you consulted
whois and would learn that that domain has a /23 in that range and not
just the /27 sorbs 'discovered'. And having that much space would
immediately thru up a flag and tell me this isn't a punk kid with a
modem or dsl line who is a threat of zombie spam infection. There are
additional tests that could also raise or lower that confidence level,
but these all require thinking the problem thru and weighing the risks
against the benifits. In this light, I beleive that automatic sorbs
listing of generic looking records is simply bad engineering, and leads
me to question the legitimacy of the entire database.
I would further single out sorbs for poor overall management - no
attack matt, but you're creating a problem and then lack the tools to
quickly and effectively correct it. The sorbs site makes it painfully
clear that any and all 'removal' requests will take a lot of time, no
matter how much damage is being caused, and that they will penalize you
by deprioritzing your case if you dare create another ticket no matter
how much time has gone by. It also claims innocence because they don't
garuentee any 'service level', that it's a voluenteer effort, that
they're overworked etc etc. But better management would converge on a
point that is fair and equitable for all parties involved, that does
include 'service levels' (if you insist on that term) and mechanisams
to garner automatic removal just as fast as the listing went up in the
first place.
At the very least, if you insist on using the flimsey rdns excuse and
refuse to incorporate some of that other confidence inspiring
engieering I mentioned, and if the standard will be rdns records with
higher ttls and such, then sorbs could at the very least, include a
working tool to cause an immediate recheck. While not solving the
problem of sorbs being too overwhelmed in the first place (not creating
the problem in the first place is the only solution to that), it would
go some ways twords reducing the hostillity and anger that sorbs
creates with these false listings, and demonstrate that perhaps the
project isn't so half baked after all.
The general policy of not accepting mail from dynamic spaces is a good
one that I support totally and have noted a substantial benefit from.
But if the data collected is less than reliable, then the value to us
drops considerably and we would prefer to simply not consult that
source at all. Therefore, as a result of our listing, as well as the
seeming persistence of this and similar complaints against sorbs, we
will immediately be discontinuing the use of sorbs data for our spam
filtering efforts. I am open to solving the problem with sorbs via
engineering means (time, server, and network resources if needed), and
if it comes together and attains that level of impeccable data that I
demand, then I'll begin using it again. But this flimsy rdns listing
nonsense needs to go.
Mike-
--
Comments posted to news.admin.net-abuse.blocklisting
are solely the responsibility of their author. Please
read the news.admin.net-abuse.blocklisting FAQ at
http://www.blocklisting.com/faq.html before posting.
Dave Platt
linux...@yahoo.com <linux...@yahoo.com> wrote:
>I think the usefulness of sorbs - like all of these lists - is directly
>derived from the timleness and accuracy of the data contained, and that
>it seems that sorbs has slipped into dysfunction with respect to the
>accuracy and maintinence of their data.
>
>My specfic complaint today is that sorbs is denying service to my users
>because sorbs decided to list my mx, and is compounding the problem by
>refusing to cooperate in correcting the error. The mx is 12.149.130.38,
>'postoffice.willitsonline.com', and sorbs seems to think that this must
>be dynamic space and therefore must be whacked. The evidence used by
>sorbs, was based soley on reverse dns information, and for which this
>IP did have a generic record due to a recent server move.
"dig" shows that this IP has another aspect of its reverse DNS which
is likely to cause some people/sites/DNSBLs to suspect that it's still
a dynamically-assigned address.
The PTR record for this IP has only a 300-second (five-minute) timeout.
This doesn't give those who query/examine the IP address any real
confidence that it's assigned to a single, stable customer over the
long term.
>These dynamic lists were beleivable when we ISP's voluenteered the
>information, because we could state with absolute authority what was
>and what was not 'dynamic space'. But just comming along and deciding,
>based simply on the one fact of a generic looking rdns record that the
>space is dynamic, is technically flawed and is like saying the internet
>is down just because you can't access some page and get an error
>message.
I'd agree that it's flawed, *if* you want a hard decision as to whether
it's dynamic.
I'd say that it's not flawed, *if* the criterion you're looking for is
more along the lines of "Is this IP address credibly assigned, for a
reasonably long and predictable interval, to an identifiable customer
who is thus responsible for it and can be contacted directly in the
case of abuse?"
My impression is that what a lot of DNSBL users are concerned with is
the latter, *not* necessarily the former. Such users are going to be
more willing to accept email from an IP address whose assignment (and
thus the identity of the responsible customer) appears stable.
When your ISP was assigning only generic reverse-DNS to your IP
address, this was no longer true. There was no way for an "outsider"
to determine via DNS that willitsonline.com was the proper contact
point for this address (and although this can be determined from
"whois", that system is not set up to handle large numbers of queries
and thus very few email systems query it).
The way your IP address is PTR'ed right now, it's still not as solidly
accountable as some people might consider necessary in order to gain
trust. The DNS literally says "Well, it's assigned to willitsonline.com
right now, but that's subject to change on 5 minutes' notice."
>There is a whole lot more network based tests that can be done to help
>increase the confidence level of that determination, stating with
>simple protocol and _asking_ the domain adminstrator (me).
Since your domain wasn't in the reverse DNS, it would require human
intervention to go "whois", look up the ownership, dig out the
NET-12-149-130-0-1 delegation, and look up the contact address.
Multiply that by about a gabillion IP address ranges, add in the fact
that SORBS and similar DNSBLs are often run on volunteer labor, and I
think you'll see the problem.
> And if you
>don't wish to be bothered because you think that a /27 out of the whole
>internet represents a signifigant threat that must be crushed first and
>no questions later ever, then at least you could bother to build into
>your robot the tools for consulting whois as well as dig for mx records
>and see what other support exists to suggest that perhaps the server in
>question really is legitimate afterall.
Unfortunately, I don't think that the "whois" system is up to handling
that on a large scale... the "whois" servers are prone to overload
(and stop responding), or to decide that someone's trying to "harvest"
whois data (and deliberately lock out such queries), and the serious
lack of standardization in the data coming back from the whois server
makes life even more difficult.
>I would further single out sorbs for poor overall management - no
>attack matt, but you're creating a problem and then lack the tools to
>quickly and effectively correct it.
Well, I'd ask just how much $$ (and labor, which adds up to the same
thing) you're willing to pony up to Matt and others in his position to
help improve matters?
> The sorbs site makes it painfully
>clear that any and all 'removal' requests will take a lot of time, no
>matter how much damage is being caused, and that they will penalize you
>by deprioritzing your case if you dare create another ticket no matter
>how much time has gone by. It also claims innocence because they don't
>garuentee any 'service level', that it's a voluenteer effort, that
>they're overworked etc etc. But better management would converge on a
>point that is fair and equitable for all parties involved, that does
>include 'service levels' (if you insist on that term) and mechanisams
>to garner automatic removal just as fast as the listing went up in the
>first place.
So, make a specific proposal, write some code, and offer it to Matt.
If it works well, I rather suspect he'll say "Thanks very much!" and
start using it.
> At the very least, if you insist on using the flimsey rdns excuse and
>refuse to incorporate some of that other confidence inspiring
>engieering I mentioned, and if the standard will be rdns records with
>higher ttls and such, then sorbs could at the very least, include a
>working tool to cause an immediate recheck.
Such a tool would probably still classify your IP address as
questionable, due to its 300-second PTR TTL.
>The general policy of not accepting mail from dynamic spaces is a good
>one that I support totally and have noted a substantial benefit from.
>But if the data collected is less than reliable, then the value to us
>drops considerably and we would prefer to simply not consult that
>source at all. Therefore, as a result of our listing, as well as the
>seeming persistence of this and similar complaints against sorbs, we
>will immediately be discontinuing the use of sorbs data for our spam
>filtering efforts. I am open to solving the problem with sorbs via
>engineering means (time, server, and network resources if needed), and
>if it comes together and attains that level of impeccable data that I
>demand, then I'll begin using it again. But this flimsy rdns listing
>nonsense needs to go.
That's entirely your privilege, and it's an appropriate response. If
any DSNBL's listing criteria do not meet your needs (for whatever
reason - wrong criteria, or not implemented to the degree of
reliability that you consider worthwhile), don't use the DNSBL.
That's the same decision every other admin has the right to make.
I strongly suspect that a lot of people will continue using the SORBS
data despite its perceived and actual limitations.
Since SORBS states quite clearly that "Generic reverse DNS naming is
the most important criterion for determining if an address range
should be considered dynamically assigned", admins who use the SORBS
data ought to be aware of this... and, for this reason, any admin who
uses the SORBS DUHL can be assumed to be [1] in agreement that this is
a reasonable policy, or [2] careless, because s/he used a DNSBL
without understanding its listing criteria.
--
Dave Platt <dpl...@radagast.org> AE6EO
Hosting the Jade Warrior home page: http://www.radagast.org/jade-warrior
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!
Morely Dotes
news:126pdqd...@corp.supernews.com:
> In article <1147970146....@g10g2000cwb.googlegroups.com>,
> linux...@yahoo.com <linux...@yahoo.com> wrote:
>
>>My specfic complaint today is that sorbs is denying service to my users
>>because sorbs decided to list my mx
THAT is a blatant lie. SORBS is most certainly not denying service to OP's
users. OTOH, I am relying on SORBS data to prevent irresponsible admins,
such as OP, from letting their users send spam or other unwanted traffic to
*my* users.
Responsible, competent admins don't allow their networks to stay in SORBS
very long (if they somehow manage to get in at all).
--
Tired of spam in your mailbox? Come to http://www.spamblocked.com
Who is Brad Jesness? http://www.wilhelp.com/bj_faq/
Look for the big white box that says "Maximum Evil" in pink letters.
"Sufficiently advanced incompetence is indistinguishable from malice."
linux...@yahoo.com
> "dig" shows that this IP has another aspect of its reverse DNS which
> is likely to cause some people/sites/DNSBLs to suspect that it's still
> a dynamically-assigned address.
>
The first point is how well is this mechanisam engineered and we're
talking about denying service based on that mechanisam, therefore we
need to agree that it should actually work. And in the Internet I think
we all can think of what we call 'corner cases' that appear to work in
one situation but don't in a number of others, and this rdns listing
mechanisam is exactly that.
What you're citing is a corner case that, by itself and in a vaccum,
appears to make the statement that this is dynamic space subject to
change. But since we're talking about denying service again, is it
right to simply stop with this one thing and consider our job done? The
demonstrated result of that one test is that it results in many false
positives, which lead to the overload that sorbs staff complain about
(and the anger and rage I feel as I pull spammer tricks now to
circumvent and overrule their listing in order to keep our mail
flowing).
> The PTR record for this IP has only a 300-second (five-minute) timeout.
> This doesn't give those who query/examine the IP address any real
> confidence that it's assigned to a single, stable customer over the
> long term.
Why is this one single test more important and trumps all others? You
seem to be saying that this is the only sure fire way to know and that
no amount of information or thinking is needed or required, that this
is the only thing that makes the cut. But there's a number of other
peices of information available straight out of the network that taken
together, would indicate a different result.
Also, I would ask since when is a 5 minute ttl value a poor choice for
a mail server? That violates no internet best practices that I know of,
and in fact, is exactly like what some dns round robin load balancing
schemes do.
>
> I'd say that it's not flawed, *if* the criterion you're looking for is
> more along the lines of "Is this IP address credibly assigned, for a
> reasonably long and predictable interval, to an identifiable customer
> who is thus responsible for it and can be contacted directly in the
> case of abuse?"
>
Yes it is flawed in that criterion, because it demonstrably failed in
my case and many other here. Just look back over the group and you'll
see waaaaayyy too many posts here complaining about exactly this issue
with sorbs. Other listing services have used techniques like sending
complaints to ab...@willitsonline.com and receivng a prompt, courteous
reply that addresses the problem or concern. The abuse alias works, but
your flimsy network test doesn't give you that information, you
actually have to try it for yourself.
> My impression is that what a lot of DNSBL users are concerned with is
> the latter, *not* necessarily the former. Such users are going to be
> more willing to accept email from an IP address whose assignment (and
> thus the identity of the responsible customer) appears stable.
>
My impression is that a lot of DNSBL users actually care about the
accuracy and timliness of the information contained in the lists they
consult, and this flimsy rdns test (and espically in the absense of
other possible checks and common sense), seems highly likely to
generate false positives. Many mailserver configs that use dnsbl, will
make mail accpetance decisions based exclusively on the reply received
from that bl. It is generally not a matter of degrees, it's an all or
nothing proposition.
> When your ISP was assigning only generic reverse-DNS to your IP
> address, this was no longer true. There was no way for an "outsider"
> to determine via DNS that willitsonline.com was the proper contact
> point for this address (and although this can be determined from
> "whois", that system is not set up to handle large numbers of queries
> and thus very few email systems query it).
>
> The way your IP address is PTR'ed right now, it's still not as solidly
> accountable as some people might consider necessary in order to gain
> trust. The DNS literally says "Well, it's assigned to willitsonline.com
> right now, but that's subject to change on 5 minutes' notice."
>
The engineering problem is, how do we create automated checks that give
us confidence in the answer to the question. And your intrepretation of
the dns results are flawed - it says that it's assigned to
'postoffice.willitsonline.com', with a 5 minute ttl... and also that
'postoffice.willitsonline.com' is assigned to it with a much longer
ttl. And thru other checks one can learn that this host is also the
primary mx for the domain. So the suspecion that it's some throwaway
spam host or modem, is reduced... once you bother to look for facts.
> Since your domain wasn't in the reverse DNS, it would require human
> intervention to go "whois", look up the ownership, dig out the
> NET-12-149-130-0-1 delegation, and look up the contact address.
>
Ah, but, the information *is* there. You have to choose to go use it,
and once you do, the suspecion grows some more that perhaps the single
flimsy test isn't good enough.
> Multiply that by about a gabillion IP address ranges, add in the fact
> that SORBS and similar DNSBLs are often run on volunteer labor, and I
> think you'll see the problem.
>
Exactly my point - SORBS is creating a problem it can't control or
handle by virtue of the fact that it's using flimsy tests to make
authorative designations of fact which may not yet be reasonably
ascertainable on today's internet, and certainly, not with the petty
trivial testing that is currently taking place.
>
> >I would further single out sorbs for poor overall management - no
> >attack matt, but you're creating a problem and then lack the tools to
> >quickly and effectively correct it.
>
> Well, I'd ask just how much $$ (and labor, which adds up to the same
> thing) you're willing to pony up to Matt and others in his position to
> help improve matters?
>
I would commit substantial time and code resources to the proposition
if I saw there was a commitment on the part of sorbs (and others
considering similar techniques) to solve the general problem. But being
a good project manager however, would require me to make the
observation that the current system is broken and that we should be
working smarter (by reducing false positives), instead of harder
(throwing more resources at the problem to handle the complaints being
generated). The need of sorbs is not invalid, it's simply the false
positives (and the lack of responsiveness on the part of sorbs support)
that make it so.
> So, make a specific proposal, write some code, and offer it to Matt.
> If it works well, I rather suspect he'll say "Thanks very much!" and
> start using it.
The specfic proposal right now, is to stop this automated listing based
on the rdns test, on the basis of the number of wrong listings it's
created and the fact that sorbs is lacking the resources to respond in
a timely fashion when mistakes are noted and reported. The severity of
a mistake in sorbs data is fairly signifigant and does tremendous
damage to innocent parties, and it's not fair or equitable to expect
these parties to just tolerate it. To deny mail service, the bar should
be pretty high. Unless you're blars and you don't care...
>
> > At the very least, if you insist on using the flimsey rdns excuse and
> >refuse to incorporate some of that other confidence inspiring
> >engieering I mentioned, and if the standard will be rdns records with
> >higher ttls and such, then sorbs could at the very least, include a
> >working tool to cause an immediate recheck.
>
> Such a tool would probably still classify your IP address as
> questionable, due to its 300-second PTR TTL.
>
No, such a tool would come back and report to you exactly what it
queried and what problem exactly it has with the returned data. Right
now I screwed up and only set the forward zone ttl to 43201 seconds and
didn't do the reverse. It's seperate files that have to be manually
maintained, a common source of rdns whackiness and one more reason it
shouldn't be trusted. A correctly function tool would say the ttls
aren't high enough. But the current sorbs shema is simply, mail stops
working without advance warning, and nobody is at the wheel and there
won't be any apologies or corrections and we can't even tell you what
set it all off. A more conservative approach would have not resulted in
the denial of my service.
> Since SORBS states quite clearly that "Generic reverse DNS naming is
> the most important criterion for determining if an address range
> should be considered dynamically assigned", admins who use the SORBS
> data ought to be aware of this... and, for this reason, any admin who
> uses the SORBS DUHL can be assumed to be [1] in agreement that this is
> a reasonable policy, or [2] careless, because s/he used a DNSBL
> without understanding its listing criteria.
I would think it's probbly the latter, but sorbs advertises itself in a
way that leaves a much different opinion. The web site states 'fighting
spam by finding and listing exploitable servers', so right off the top,
many sites who use sorbs beleive that this is the complete content of
the database. It also does not discuss anywhere that I can see, the
flimsy rdns test nor discuss any of the possible scenarios in which
this will be wrong. Further, no published internet best practices
discusses this subject much, so sorbs gains a following and the power
to deny service to large groups of users, without there ever being any
engineering review of the techniques used. I seriously doubt that the
vast majority of servers configured to use sorbs, consented to deny
service because of a 5 minute ttl. Most people using it probbly think
the dynamic spaces were derived thru some authoratative scheme, like
simply asking isps for the information in the first place.
Mike-
David Cary Hart
<linux...@yahoo.com> opined:
> I think the usefulness of sorbs - like all of these lists - is
> directly derived from the timleness and accuracy of the data
> contained, and that it seems that sorbs has slipped into
> dysfunction with respect to the accuracy and maintinence of their
> data.
>
range due to generic rDNS. You corrected this and cannot get them to
de-list the range. You are then suggesting that SORBS should apply
numerous, more accurate tests such as contacting the administrator?
To the best of my knowledge, SORBS has a very pragmatic criteria
consisting of rDNS and TTL. While it would be great if there were
other tests that could be more accurate, no professionally managed
space should have difficulty meeting that simple standard. While you
might be profoundly honest, contacting administrators is extremely
unscientific. Furthermore, exactly WHO is going to subsidize SORBS to
achieve the staffing to exhaustively examine every assignment?
--
Displayed Email Address is a SPAM TRAP
Our DNSRBL - Eliminate Spam: http://www.TQMcube.com
Multi-RBL Check: http://www.TQMcube.com/rblcheck.php
SPEWS Delisting: http://tqmcube.com/spews.php
Atro Tossavainen
>
> Dave Platt wrote:
>
> > "dig" shows that this IP has another aspect of its reverse DNS which
> > is likely to cause some people/sites/DNSBLs to suspect that it's still
> > a dynamically-assigned address.
> >
> I would think it's probbly the latter, but sorbs advertises itself in a
> way that leaves a much different opinion. The web site states 'fighting
> spam by finding and listing exploitable servers', so right off the top,
> many sites who use sorbs beleive that this is the complete content of
> the database.
http://www.sorbs.net/using.shtml
> Further, no published internet best practices
> discusses this subject much,
Apparently, there is a recent Internet draft on the topic, written by
Matthew and Luis Muñoz from the Venezuelan ISP CanTV.
http://www.ietf.org/internet-drafts/draft-msullivan-dnsop-generic-naming-schemes-00.txt
--
Atro Tossavainen (Mr.) / The Institute of Biotechnology at
Systems Analyst, Techno-Amish & / the University of Helsinki, Finland,
+358-9-19158939 UNIX Dinosaur / employs me, but my opinions are my own.
< URL : http : / / www . helsinki . fi / %7E atossava / > NO FILE ATTACHMENTS
RadicalModerate
https://www.dnsbl.au.sorbs.net/scgi-bin/dulexclusions ?
Before doing so be sure your DNS configuration meets the following
requirements (you may need to coordinate this with your upstream):
* The MX record of a domain needs to contain a host name that maps to
the IP address involved. The Time to Live of the MX record needs to be at
least 43200 seconds.
* The A record for the host name needs to have a TTL
of at least 43200 seconds.
(this is what might have gotten you listed; when you did your server move
you likely had to set a short DNS TTL for its IP and/or MX record address
that now needs to be reset to 43200 or higher)
* The reverse DNS PTR record for the IP address involved needs to map
back to the name given in the MX record, and to have a TTL of at least
43200 seconds.
* If there are multiple MX entries, these rules apply to them all.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Herb Oxley
From: address IS Valid.
Philip Homburg
linux...@yahoo.com <linux...@yahoo.com> wrote:
>derived from the timleness and accuracy of the data contained, and that
>it seems that sorbs has slipped into dysfunction with respect to the
>accuracy and maintinence of their data.
Unfortunately, you don't seem to say a lot about the usefulness of sorbs.
I don't agree with sorbs' listing policy myself. But if you want to say
anything about the usefulness, you have to say something about the
false positive and false negative rates, and compare that to other spam
filters.
Just about all lists will have false positives some of the time. That is
annoying for the people affected, but random incidents don't say much about
the performance of the list as a whole.
>The mx is 12.149.130.38,
>'postoffice.willitsonline.com',
A (not so) funny detail is that I have the entire 12.0.0.0/8 blocked.
There is simply too much spam coming from that block. ARIN lists AT&T as
the owner of the entire /8, so the entire /8 gets blocked.
--
That was it. Done. The faulty Monk was turned out into the desert where it
could believe what it liked, including the idea that it had been hard done
by. It was allowed to keep its horse, since horses were so cheap to make.
-- Douglas Adams in Dirk Gently's Holistic Detective Agency
Stephen Satchell
> Dave Platt wrote:
>> [prior attributions not provided by poster]
>>The PTR record for this IP has only a 300-second (five-minute) timeout.
>>This doesn't give those who query/examine the IP address any real
>>confidence that it's assigned to a single, stable customer over the
>>long term.
>
>
> Why is this one single test more important and trumps all others? You
> seem to be saying that this is the only sure fire way to know and that
> no amount of information or thinking is needed or required, that this
> is the only thing that makes the cut. But there's a number of other
> peices of information available straight out of the network that taken
> together, would indicate a different result.
>
> Also, I would ask since when is a 5 minute ttl value a poor choice for
> a mail server? That violates no internet best practices that I know of,
> and in fact, is exactly like what some dns round robin load balancing
> schemes do.
Really? All of my DNS round robin load balancing schemes have TTLs of
43200. It isn't the TTL that determines how round-robin selection works.
It's important because spammers can them move around a /24 without
assistance from the ISP and spam, spam, spam, spam, spam.
>>I'd say that it's not flawed, *if* the criterion you're looking for is
>>more along the lines of "Is this IP address credibly assigned, for a
>>reasonably long and predictable interval, to an identifiable customer
>>who is thus responsible for it and can be contacted directly in the
>>case of abuse?"
>
> Yes it is flawed in that criterion, because it demonstrably failed in
> my case and many other here. Just look back over the group and you'll
> see waaaaayyy too many posts here complaining about exactly this issue
> with sorbs. Other listing services have used techniques like sending
> complaints to ab...@willitsonline.com and receivng a prompt, courteous
> reply that addresses the problem or concern. The abuse alias works, but
> your flimsy network test doesn't give you that information, you
> actually have to try it for yourself.
SORBS isn't your own problem when we talk about generic rDNS. I have
code in place in my perimeter gateway routers that check specifically
for generic host names, and will reject mail on this criterion alone.
See http://email.amhosting.com/dyn.html for information on my practice.
By the way, I got the idea to do this from discussion here about
common spammer practice.
While I'm on the subject, I've noticed something VERY disturbing: there
are administrators who are falsifying rDNS to the point that I had to
turn off host name lookup in my Web servers at $DAYJOB. Why? When
there is abuse, the logs no longer are dependable with host name lookups
turned on. That is to say, I can't get the original IP address back
reliably.
Hal Murray
>While I'm on the subject, I've noticed something VERY disturbing: there
>are administrators who are falsifying rDNS to the point that I had to
>turn off host name lookup in my Web servers at $DAYJOB. Why? When
>there is abuse, the logs no longer are dependable with host name lookups
>turned on. That is to say, I can't get the original IP address back
>reliably.
That sounds like a bug in the code.
It should log both the IP address and the reverse DNS
host name, and probably some flag to indicate if the
forward DNS matches.
Have you submitted a bug report?
--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.
Seth Breidbart
linux...@yahoo.com <linux...@yahoo.com> wrote:
>Dave Platt wrote:
>
>> "dig" shows that this IP has another aspect of its reverse DNS which
>> is likely to cause some people/sites/DNSBLs to suspect that it's still
>> a dynamically-assigned address.
>>
>The first point is how well is this mechanisam engineered and we're
>talking about denying service based on that mechanisam, therefore we
>need to agree that it should actually work.
Nobody needs to agree. If _I_ think it works well enough for me, then
I can use it on my server. If _you_ think it doesn't work well enough
for you, then you shouldn't use it on your server. See how that
works?
> And in the Internet I think
>we all can think of what we call 'corner cases' that appear to work in
>one situation but don't in a number of others, and this rdns listing
>mechanisam is exactly that.
Nothing is perfect. What matters is the odds. If something blocks a
lot of spam, and no actual messages that I care about, it's good for
me to use it.
>What you're citing is a corner case that, by itself and in a vaccum,
>appears to make the statement that this is dynamic space subject to
>change. But since we're talking about denying service again, is it
>right to simply stop with this one thing and consider our job done?
That's up to the server owner. Is it right to spend a whole lot more
time and effort for very little gain in accuracy? Is it right to
spend a lot of time and effort on this case at the cost of not
spending them on something else and thereby reducing overall accuracy?
> The demonstrated result of that one test is that it results in many
>false positives,
"Many" as seen by whom?
>> The PTR record for this IP has only a 300-second (five-minute) timeout.
>> This doesn't give those who query/examine the IP address any real
>> confidence that it's assigned to a single, stable customer over the
>> long term.
>
>Why is this one single test more important and trumps all others?
Because the server owner (his server, his rules) wants it to.
If you think you could do a better job than SORBS, feel free to set up
your own list service. If others agree yours is better, they'll
switch, and SORBS will become irrelevant. If they don't agree, you'll
at least be able to learn something, I hope.
Or, more simply, set up a SORBS-ERROR list, which people can use to
whitelist stuff you think SORBS has listed in error. Again, people
who agree with you will use your list, others won't.
>Also, I would ask since when is a 5 minute ttl value a poor choice for
>a mail server? That violates no internet best practices that I know of,
Best practice for something intended to look static is a minimum of
12-24 hours.
>and in fact, is exactly like what some dns round robin load balancing
>schemes do.
That's a pretty stupid load-balancing scheme.
>The engineering problem is, how do we create automated checks that give
>us confidence in the answer to the question.
If you have what you think is a better solution, use it and see how
many others agree.
>> Since your domain wasn't in the reverse DNS, it would require human
>> intervention to go "whois", look up the ownership, dig out the
>> NET-12-149-130-0-1 delegation, and look up the contact address.
>>
>Ah, but, the information *is* there. You have to choose to go use it,
>and once you do, the suspecion grows some more that perhaps the single
>flimsy test isn't good enough.
So why should limited resources be used the way you want rather than
the way their owner wants?
>> Multiply that by about a gabillion IP address ranges, add in the fact
>> that SORBS and similar DNSBLs are often run on volunteer labor, and I
>> think you'll see the problem.
>
>Exactly my point - SORBS is creating a problem it can't control or
>handle by virtue of the fact that it's using flimsy tests to make
>authorative designations of fact which may not yet be reasonably
>ascertainable on today's internet, and certainly, not with the petty
>trivial testing that is currently taking place.
If you don't like SORBS, feel free not to use it.
>> Well, I'd ask just how much $$ (and labor, which adds up to the same
>> thing) you're willing to pony up to Matt and others in his position to
>> help improve matters?
>
>I would commit substantial time and code resources to the proposition
>if I saw there was a commitment on the part of sorbs (and others
>considering similar techniques) to solve the general problem.
In other words, you aren't willing to contribute anything until you're
guaranteed to get your way. It doesn't work like that.
>> So, make a specific proposal, write some code, and offer it to Matt.
>> If it works well, I rather suspect he'll say "Thanks very much!" and
>> start using it.
>
>The specfic proposal right now, is to stop this automated listing based
>on the rdns test, on the basis of the number of wrong listings it's
>created and the fact that sorbs is lacking the resources to respond in
>a timely fashion when mistakes are noted and reported.
The issue is whether or not in SORBS' opinion that would provide a net
benefit. Reducing false positives at the cost of reducing true
positives might not be, overall, beneficial.
> The severity of
>a mistake in sorbs data is fairly signifigant and does tremendous
>damage to innocent parties, and it's not fair or equitable to expect
>these parties to just tolerate it.
So provide a better service and let SORBS whither.
> To deny mail service, the bar should
>be pretty high. Unless you're blars and you don't care...
It's the admin of the receiving machine who controls the height of his
bar.
>I would think it's probbly the latter, but sorbs advertises itself in
>a way that leaves a much different opinion. The web site states
>'fighting spam by finding and listing exploitable servers', so right
>off the top, many sites who use sorbs beleive that this is the
>complete content of the database.
People who don't read very well or carefully often make all sorts of
mistakes, resulting in all sorts of consequences. That's their
problem.
> I seriously doubt that the
>vast majority of servers configured to use sorbs, consented to deny
>service because of a 5 minute ttl.
By definition, they did.
> Most people using it probbly think the dynamic spaces were derived
>thru some authoratative scheme, like simply asking isps for the
>information in the first place.
There is no obligation on the part of anybody to change their actions
because of incorrect beliefs of others.
Seth
huey.c...@gmail.com
> linux...@yahoo.com <linux...@yahoo.com> wrote:
> > My specfic complaint today is that sorbs is denying service to my
> > users because sorbs decided to list my mx, and is compounding the
> > problem by refusing to cooperate in correcting the error. The mx is
> > 12.149.130.38, 'postoffice.willitsonline.com', and sorbs seems to
> > think that this must be dynamic space and therefore must be
> > whacked. The evidence used by sorbs, was based soley on reverse dns
> > information, and for which this IP did have a generic record due to
> > a recent server move.
> This doesn't give those who query/examine the IP address any real
> confidence that it's assigned to a single, stable customer over the
> long term.
That statement is, not to put too fine a point on it, stupid.
To wit:
mailin-01.mx.aol.com. A IN 300 205.188.156.185
mailin-01.mx.aol.com. A IN 300 205.188.158.121
mailin-01.mx.aol.com. A IN 300 64.12.137.249
mailin-02.mx.aol.com. A IN 300 205.188.155.89
mailin-02.mx.aol.com. A IN 300 205.188.157.25
mailin-02.mx.aol.com. A IN 300 64.12.138.185
mailin-03.mx.aol.com. A IN 300 205.188.159.57
mailin-03.mx.aol.com. A IN 300 64.12.138.57
mailin-03.mx.aol.com. A IN 300 64.12.138.120
mailin-03.mx.aol.com. A IN 300 205.188.157.217
mailin-04.mx.aol.com. A IN 300 205.188.156.249
mailin-04.mx.aol.com. A IN 300 205.188.159.217
mailin-04.mx.aol.com. A IN 300 64.12.138.89
mailin-04.mx.aol.com. A IN 300 64.12.138.152
reverse DNS on all of those IPs is 3600s
mx4.hotmail.com. A IN 3600 65.54.245.104
mx4.hotmail.com. A IN 3600 65.54.190.179
mx4.hotmail.com. A IN 3600 65.54.244.104
mx4.hotmail.com. A IN 3600 65.54.244.232
mx1.hotmail.com. A IN 3600 64.4.50.50
mx1.hotmail.com. A IN 3600 65.54.245.8
mx1.hotmail.com. A IN 3600 65.54.244.136
mx1.hotmail.com. A IN 3600 65.54.244.8
mx2.hotmail.com. A IN 3600 65.54.244.40
mx2.hotmail.com. A IN 3600 65.54.190.50
mx2.hotmail.com. A IN 3600 65.54.245.40
mx2.hotmail.com. A IN 3600 65.54.244.168
mx3.hotmail.com. A IN 3600 64.4.50.179
mx3.hotmail.com. A IN 3600 65.54.244.72
mx3.hotmail.com. A IN 3600 65.54.245.72
mx3.hotmail.com. A IN 3600 65.54.244.200
reverse DNS on all of those IPs is 3600s
mx2.mail.yahoo.com. A IN 1800 4.79.181.135
mx2.mail.yahoo.com. A IN 1800 67.28.113.70
mx2.mail.yahoo.com. A IN 1800 67.28.113.19
mx2.mail.yahoo.com. A IN 1800 67.28.113.72
mx3.mail.yahoo.com. A IN 1800 4.79.181.12
mx3.mail.yahoo.com. A IN 1800 67.28.113.11
mx3.mail.yahoo.com. A IN 1800 4.79.181.13
mx3.mail.yahoo.com. A IN 1800 67.28.113.10
mx3.mail.yahoo.com. A IN 1800 64.156.215.8
mx3.mail.yahoo.com. A IN 1800 64.156.215.18
mx3.mail.yahoo.com. A IN 1800 4.79.181.134
mx4.mail.yahoo.com. A IN 1800 66.218.86.156
mx4.mail.yahoo.com. A IN 1800 66.218.86.254
mx4.mail.yahoo.com. A IN 1800 4.79.181.136
mx1.mail.yahoo.com. A IN 1800 67.28.113.71
mx1.mail.yahoo.com. A IN 1800 67.28.113.73
mx1.mail.yahoo.com. A IN 1800 4.79.181.14
mx1.mail.yahoo.com. A IN 1800 4.79.181.15
reverse DNS on all of those IPs is 1200s
Now, given that most of the largest producers and consumers of email
in the United States all have DNS and rDNS with timeouts set at an
hour or under, the requirement by SORBS that "The A record for the host
name needs to have a TTL of at least 43200 seconds", and the statement
"This doesn't give those who query/examine the IP address any real
confidence that it's assigned to a single, stable customer over the
long term" are both clearly at odds with reality, unless you really
don't think that people like AOL, hotmail, and yahoo are 'stable
customers', in which case there is likely another obvious source of
error.
--
Huey
E-Mail Sent to this address will be added to the BlackLists
> mailin-01.mx.aol.com A IN 300 205.188.156.185 ...
> reverse DNS on all of those IPs is 3600s
> reverse DNS on all of those IPs is 3600s
> reverse DNS on all of those IPs is 1200s
> Now, given that most of the largest producers and
> consumers of email in the United States all have DNS
> and rDNS with timeouts set at an hour or under, the
> requirement by SORBS that "The A record for the host
> name needs to have a TTL of at least 43200 seconds",
...
AFAIK for SORBS a 43200 TTL is not a absolute requirement,
http://www.dnsbl.sorbs.net/faq/dul.shtml
"The Regional Internet Registry (RIR) Point of Contact
(PoC) can request a listing or delisting of any address
in their space. The only time this will be refused is
when the netblock information in the RIR or in the
reverse DNS naming clearly indicates the addresses are
dynamically assigned (e.g. 0.1.pool.example.com)."
If they are not a IP whois listed contact, then I guess
they have to meet other delisting requirements.
--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.
linux...@yahoo.com
personell - to address the problem it is creating, and the queue wait
times for service is at least over a week at this point in time.
Something has to give. One solution is to stop using bogus criteria
such as the flimsy rdns test, a test which does not pass the technical
validity muster. You are the second person to suggest that the
potential damage of incorrect listings does not outweigh the
inconveience and time demands required to do 'a better job', and by
extension, why bother with doing a better job with validating the
listings first. I have a strong objection because the damage is
substantial to otherwise innocent domains, and sorbs moving first is
the equivelent of taking the first swing.
With respect to this standard you think professionally managed space
should adhere to, I don't beleive it passes technical muster and I can
quote procedures straight out of the cricket book which will result in
exactly this problem. For example, just exactly how does sorbs know
that I'm not about to move servers around in my domain? Reducing the
ttl is a necessary step in order to accomplish this, just read the
cricket book for some examples reccomended. There are others, but the
point is this - sorbs current stated procedure does not pass the
technical muster.
E-Mail Sent to this address will be added to the BlackLists
> linux...@yahoo.com <linux...@yahoo.com> wrote:
>> Dave Platt wrote:
>>> The PTR record for this IP has only a 300-second
>>> (five-minute) timeout. This doesn't give those
>>> who query/examine the IP address any real confidence
>>> that it's assigned to a single, stable customer over
>>> the long term.
>> Why is this one single test more important and trumps all others?
AFAIK for SORBS, it appears for the most part that the word
of the IP whois direct allocation contact trumps all others.
Other dynamic / generic DNSbls have other criteria;
{Maybe one of them more closely meets your needs.}
dynamic.dnsbl.rangers.eu.org http://dnsbl.rangers.eu.org/
generic IP range, A subnet whose reverse DNS entries are
sequentially numbered and do not indicate static assignment
I am listed in dynamic/generic zone, but my address is static!
How do I get off the list?
A: Make sure your revDNS clearly indicates that there is a
mail server behind it (mail.yourdomain.com is a good example).
However, delisting requests will be honored only if the
majority of the IPs in the nearest /24 subnet have
non-generic revDNS.
Dynablock.njabl.org removal http://njabl.org/dynablock.html
Your IP space must be reassigned via whois to show that
it's "your address space".
There must be unique (non-script-generated) rDNS for your IPs.
rDNS for 1.2.3.4 of 1-2-3-4-blah.some.provider
or blah-10-24-3-4.blah.some.provider do not qualify.
If neither of the above are true, and the request comes
from anyone other than the ISP that owns the IP space,
the request will be totally ignored.
For large blocks of static IPs that might be mistaken
as dynamic, we very strongly recommend ISPs either
clearly note in their RIR registration info (whois)
that the space is static or do so in the in-addr.arpa
(reverse) DNS.
Requests for removal of space that resolves to names
like adsl-10-20-30-40.some.provider are somewhat likely
to be ignored, while requests for removal of space that
resolves to names like adsl-10-20-30-40.static.some.provider
or mail.some.domain are far more likely to be granted.
dnsbl.njabl.org dynamic IP ranges http://njabl.org/listing.html
(njabl created, not the easynet mirror)
In general, there's no need for a dial-up user to talk directly
to any SMTP server other than that of their own ISP.
So we're compiling a list of dial-up port IP ranges, mostly at
larger providers where the abuse seems to be the worst,
and we add those to the list.
We also include any other IP pools that appear to be dynamically
assigned as well as NAT pools, since they are effectively dynamic.
If an IP is listed because we think it's in a dial-up range,
show us that it not. If it really is a dial-up, it'll most
likely remain in the list, but we may add non-dial-up range
IP's to the list thinking they are dial-up range IP's.
In these cases, we'll be happy to correct the error.
If your IP is listed as dynamic, please contact us from the
RIR contact email address to inform us that it is not.
JAMMDNSBL (.6 for dynamic IP ranges)
http://www.jammconsulting.com/policies/dnsbl.shtml
legitimate emails sent from a dynamically assigned IP
should be relayed thru their ISP's mail server
(which should have a static IP).
Because of this, we aim to block all dynamic IP addresses.
Unfortunately, we have no way to tell if any given IP address
is dynamic or static without information from the ISP that owns it.
Therefore, we take the following steps when we receive spam:
If the spam comes from an IP that is static, we will list the IP.
If we do not know if the IP is dynamic or static:
query the registry records to find the IP range and ISP where the spam originated
list the entire IP range to prevent additional spam coming into our network.
send an email notification to the ISP that owns the IP range that:
and request these pieces of information: IP address is dynamic or static
A listing of the dynamic addresses within their IP range
Once the ISP responds, we adjust our list based on the information
they give us.
If the originating machine has a static IP address,
we will only list it.
If not, we will list the range of dynamic IP addresses
that includes the originating machine.
If the ISP gives us a list of additional dynamic IP addresses,
we will list all of those IP addresses.
NOTE: The entire range will remain in our list until the
ISP responds to our inquiry.
Many ISPs use a reverse DNS naming scheme to identify
their dynamic IPs. The following ISPs have given us
these naming schemes: ... ~45 examples
PDL http://www.pan-am.ca/pdl/
http://www.pan-am.ca/pdl/adding.html
... Another important clue is the reverse DNS name of the
source address, in this case dedn-206-45-235-27.mts.net
Anything that looks generic, or looks like part of a
sequence of address names, is a good candidate for listing.
PDL lists networks that provide temporary connectivity to
the Internet, where SMTP services are not expected to be found.
Home dial-up Internet providers use their network ranges for
temporary connectivity, as do home ADSL and home Cable providers.
If there is any doubt, the submission is rejected.
The most important criteria that approves or rejects a submission
is the Internet provider's Terms of Service.
If they disallow mail servers in their terms of service,
chances are their networks will be listed.
If they allow static IP addresses but still disallow mail
servers, their IPs could be listed.
If they are not clear on permitting servers, PDL will make
an attempt to guess or contact the ISP to ask them.
Another important criteria is the way the ISP identifies
their network. If they clearly identify it as temporary
or non-server IP, either through a WHOIS registry or in
reverse DNS, chances are it will be listed.
And third, the presence of SMTP and other services in the
network will influence the submission.
An ISP may not explicitly disallow servers, nor may it
clearly identify a network's usage through a database
or reverse DNS. But if spam came from a network where
no SMTP services are operating, it could be listed.
http://www.pan-am.ca/pdl/removing.html
PDL's removal criteria are as simple as the addition criteria.
First, PDL will remove entries if requested by the ISP.
For instance, if the ISP changes their Terms of Service
to permit SMTP services, they have special arrangements
with certain customers or they simply don't like the idea
of being listed, they merely have to ask.
We'll try to explain why the listings are a good thing to
help them stop junk e-mailers on their network, but
we'll still remove listings if they insist.
Second, if the network you wish to see removed is no longer
identified as home IP, such as former dial-up space
reassigned to servers, we'll remove it.
Finally, if many SMTP services or other services normally
identified with non-home IP are present in a range listed,
we'll remove it.
Why PDL May Not Remove a Listing
While all removal requests provoke a reevaluation,
they don't all result in removals.
Requests from end users will generally be answered
with a request to ask their Internet provider for
a clairification of their Terms of Service.
Because of abuse or negligence by server operators,
or by whatever corporate whims of the network's owners,
Internet providers may refuse to allow servers even
on broadband services.
Depending on the Internet provider, it can be extremely
difficult to tell the difference between network ranges
that are allowed to run servers and those that are not.
If you believe you're permitted to run a mail server where
you are, ask for clairification from your Internet provider
before writing the PDL Project.
Include that with your removal request.
We're not trying to accuse you of lying, but listings can
happen when faced with an e-mail abuse sample, a set of
terms like these and no way to tell the difference between
home and server connections.
DNSBLNETAURDTS rdts.dnsbl.net.au http://www.dnsbl.net.au/rdts/
dnsbl.net.au Dynamic Type Services List
Please also see my r-dns.rfc page. Reverse DNS RFC
http://www.dnsbl.net.au/rdts/r-dns.rfc.php
Consists of collection of IP addressed networks, which are
normally assigned dynamically (never the same ip number
again, when you log back on again.)
http://www.dnsbl.net.au/remove/
Step 1. To remove a block entry, you must first define it's
IP address, like "12.23.12.23" .. Blocklist entry :
We have a 'Minimal questions asked' removal policy.
Once you have defined a current Blocklist Entry
at Step 1. above, anyone, anywhere, anytime,
can remove that entry, by 3 additional steps.
2. Enter your email address, and press the SUBMIT button
3. The UNLOCK CODE will be sent to you by email
4. Enter the UNLOCK CODE, and press the SUBMIT button
> If you have what you think is a better solution, use it
> and see how many others agree.
...
>> I would commit substantial time and code resources to the
>> proposition if I saw there was a commitment on the part
>> of sorbs (and others considering similar techniques)
>> to solve the general problem.
>
> In other words, you aren't willing to contribute anything
> until you're guaranteed to get your way. It doesn't work
> like that.
>
>>> So, make a specific proposal, write some code, and offer
>>> it to Matt. If it works well, I rather suspect he'll say
>>> "Thanks very much!" and start using it.
>>
>> The specfic proposal right now, is to stop this automated
>> listing based on the rdns test, on the basis of the number
>> of wrong listings it's created and the fact that sorbs is
>> lacking the resources to respond in a timely fashion when
>> mistakes are noted and reported.
This is always one of my top thoughts when someone complains
about what this, that or the other DNSbl lists (or does not list);
"I got Spam from x IP, how come y DNSbl does not list it?"
"Not all users of the mail server on x IP send spam,
why does y DNSbl list it?" ...
If you know of a better way to skin a cat, write a RFC,
if others agree, they might implement it;
Invent a better widget, if it is better others may use it, ...
>> To deny mail service, the bar should be pretty high.
>> Unless you're blars and you don't care...
>
> It's the admin of the receiving machine who controls
> the height of his bar.
At $DayJob we use SA for post reception filtering / sorting,
the messages either go in the users inbox or their spam box.
One or two DNSbls listing all IP addresses for example
(which has happened) is not going to cause all messages
to be lost, even if all DNSbls used were to list all addresses
and that added up to a high enough score that all messages
were treated as spam, the messages would still be recoverable,
(if the enduser went looking for them in the spam folder).
{This kind of filtering does consume more resources than
null routing IPs listed in a DNSbl, or rejecting at SMTP
time IPs listed in a DNSbl.}
>> I would think it's probbly the latter, but sorbs advertises
>> itself in a way that leaves a much different opinion.
>> The web site states 'fighting spam by finding and listing
>> exploitable servers', so right off the top, many sites
>> who use sorbs beleive that this is the complete content
>> of the database.
>
> People who don't read very well or carefully often make all
> sorts of mistakes, resulting in all sorts of consequences.
> That's their problem.
>
>> I seriously doubt that the vast majority of servers
>> configured to use sorbs, consented to deny service
>> because of a 5 minute ttl.
>
> By definition, they did.
>
>> Most people using it probbly think the dynamic spaces
>> were derived thru some authoratative scheme, like
>> simply asking isps for the information in the first place.
>
> There is no obligation on the part of anybody to change
> their actions because of incorrect beliefs of others.
There are many people that use many DNSbls and other
spam control methods / services that they don't understand.
(Like those who have intentionally used a DNSbl that lists
all IPv4, without understanding what the DNSbl listed,
or even perhaps what a DNSbl really is.)
If a mail server admin is going to use any 3rd party
spam control resource, they should understand as much
as possible the pros, cons, failure modes, ...
and do testing (tag for some time with the DNSbl
evaluate the results, and see if it really meets your
needs).
--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.
--
E-Mail Sent to this address will be added to the BlackLists
> My specfic complaint today is that sorbs is denying service to my users
Only (potentially) to SORBS servers;
Other mail server admins might be referencing dul.dnsbl.sorbs.net
or dnsbl.sorbs.net or some other mirror or composite that includes
dul.dnsbl.sorbs.net in their Spam Control, if they are rejecting
based on entries in those DNSbls or any other DNSbls, that is up
to those mail server admins, SORBS certainly can't compel them
to NullRoute, Reject, Bounce or filter based on a SORBS DNSbl,
nor can any other DNSbl (Admins pretty much have to intentionally
use any DNSbl and what to do with what results they get from a
DNSbl).
> At the very least, ... if the standard will be rdns
> records with higher ttls and such, then sorbs could
> at the very least, include a working tool to cause
> an immediate recheck.
They do, https://www.dnsbl.sorbs.net/scgi-bin/dulexclusions
found near the bottom of this page
http://www.dnsbl.sorbs.net/faq/dul.shtml
However your IP would not be delisted,
as it does not appear to currently meet the criteria.
(short rDNS PTR TTL, no MX record for postoffice.willitsonline.com,
MXes that are there have short TTLs too.)
http://www.dnsstuff.com/tools/ptr.ch?ip=12.149.130.38
12.149.130.38 PTR record: postoffice.willitsonline.com. [TTL 300s] (5 Minutes)
http://www.dnsstuff.com/tools/lookup.ch?name=postoffice.willitsonline.com&type=A
postoffice.willitsonline.com A IN 43201 (12 Hours 1 Second) 12.149.130.38
http://www.dnsstuff.com/tools/lookup.ch?name=willitsonline.com&type=MX
willitsonline.com MX IN [TTL 300s] (5 Minutes) mx0.willitsonline.com [Preference = 10]
willitsonline.com MX IN [TTL 300s] (5 Minutes) mx-relay.willitsonline.com [Preference = 20]
willitsonline.com MX IN [TTL 300s] (5 Minutes) mx-relay-offsite.willitsonline.com [Preference = 100]
> ... and espically if you consulted whois ...
IP whois for 12.149.130.38 does not indicate that the
CIDR: 12.149.130.0/23 , NetRange: 12.149.130.0 - 12.149.131.255
is for static use only.
BTW,
http://www.dnsstuff.com/tools/traversal.ch?domain=38.130.149.12.in-addr.arpa&type=PTR
Records DO NOT all match: At least one DNS server (ns4.tiedyenetworks.com) did not respond.
http://www.dnsstuff.com/tools/traversal.ch?domain=willitsonline.com&type=A
Records DO NOT all match: At least one DNS server (ns4.tiedyenetworks.com) did not respond.
http://www.dnsstuff.com/tools/traversal.ch?domain=willitsonline.com&type=MX
Records DO NOT all match: At least one DNS server (ns4.tiedyenetworks.com) did not respond.
If you can create & maintain a Dynamic IP DNSbl that
changes faster and is more accurate than existing
Dynamic / Generic DNSbls, I'm sure many would appreciate
your continuous effort. (When will it be available?)
--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.
--
ru.ig...@usask.ca
> As I stated, since SORBS doesn't have the resources - technical and
> personell - to address the problem it is creating, and the queue wait
> times for service is at least over a week at this point in time.
OK, so don't use SORBS. You aren't obliged to. Other users who are
not concerned with a two week lag in blocklisting updates will continue
to use it. There's even a good chance that's the way they want it
(some may even wish listings lag by months, but Matthew isn't unkind).
There's a wide range of anti-spam solutions out there, catering
to an equally wide range of anti-spam reactions. You choose the
one that suits you.
Or cut holes in your local implementation. Just about every spam
filtering/blocking machinery has some sort of whitelist in place.
Either way, it is YOUR JOB as an admin to set up, modify, or decide
to use blocklists as appropriate to your company. Every tool has
its uses, and SORBS seems useful enought that it maintains a pretty
high profile. If you got burned for using SORBS (i.e. for using
a tool that wasn't suited for your project), then do what most tech
managers do, accept it (i.e. live with the problems), adapt it
(i.e. make modificatons yourself in-house), or toss it (i.e. find
a more appropriate tool).
> One solution is to stop using bogus criteria
> such as the flimsy rdns test,
It suits me just fine. If it turns out I'm on a set of IPs that
look generic and I find them listed, it would be MY JOB to ask
SORBS to delist (after providing relevant info/discussion).
> a test which does not pass the technical
> validity muster.
It doesn't have to. It just has to pass a probability threshold.
Some blocklists are used either for pre-emptive or preventative
protection. The SORBS list in question is one of these. As with
many pre-emptive mechanisms, you cover a wide range and poke holes
or reinforce as necessary. OK, so it DOES pass technical validity
muster. I think you're just making the wrong assumption about the
operational model for that list.
> You are the second person to suggest that the
> potential damage of incorrect listings does not outweigh the
> inconveience and time demands required to do 'a better job', and by
> extension, why bother with doing a better job with validating the
> listings first.
Well, if you are arguing against that, then you should do the
"better job" because that will cost you less than the damage
of using the wrong blocklist. Keep in mind that even though
the cost of problems in using SORBS is yours, you did not pay
SORBS. You got a spam prevention service that operates in a
defined way for free. If you want added value, you can ask
for it, but don't expect it for free. That's one reason folks
have been telling you to build your own if you are so
dissatisfied.
> I have a strong objection because the damage is
> substantial to otherwise innocent domains,
Damage to which "innocent domains"? The domains that use SORBS
knowing that there will be collateral (in which case, they've
already determined the damage is worth the use of SORBS)? The
domains that use SORBS without realizing how much collateral
(in which case, they can stop using it and find something that
suits them better, and if they don't notice it, then they either
aren't taking enough damage to matter or they ought to learn to
choose what is appropriate for them)? The domains that are
blocked because their intended recipient uses SORBS (in which
case, that's really not the SORBS user's problem and neither is it
SORBS' - the onus is on the "blocked" to get unblocked)?
> For example, just exactly how does sorbs know
> that I'm not about to move servers around in my domain?
The answer is obvious if you are a user of SORBS, you inform SORBS
ahead of time. That kind of action is virtually mandatory for
folks in technical operations. When it is overlooked, the
responsibility is purely on the tech staff that didn't account
for the effect (in this case, it would be your fault for not
performing due diligence and making sure that the blocklists
that you use won't get messed up).
ru
--
I am not SPEWS. Any suggestions regarding SPEWS are merely from
observation of SPEWS records and its FAQs.
Laurence F. Sheldon, Jr.
> With respect to this standard you think professionally managed space
> should adhere to, I don't beleive it passes technical muster and I can
> quote procedures straight out of the cricket book which will result in
> exactly this problem. For example, just exactly how does sorbs know
> that I'm not about to move servers around in my domain? Reducing the
> ttl is a necessary step in order to accomplish this, just read the
> cricket book for some examples reccomended. There are others, but the
> point is this - sorbs current stated procedure does not pass the
> technical muster.
There seems to be a natural progression, akin to the one propounded by
Godwin, that describes the life-cycle of blocking lists, starting with
somebody with a charismatic combination of spare time, spare computing
resources, and a good idea.
As time and other influences I have not sorted out yet progress, the
good idea is perverted into some variation of control-freakism with (in
some notorious cases) spite listings, bizarre micromanagment of other
peoples resources as a price for delisting, and so on.
With each iteration the credibility of good people is damaged irreparably.
It is sad.
--
Requiescas in pace o email
Ex turpi causa non oritur actio
http://members.cox.net/larrysheldon/
linux...@yahoo.com
> > Further, no published internet best practices
> > discusses this subject much,
>
> Apparently, there is a recent Internet draft on the topic, written by
> Matthew and Luis Muñoz from the Venezuelan ISP CanTV.
>
> http://www.ietf.org/internet-drafts/draft-msullivan-dnsop-generic-naming-schemes-00.txt
>
This draft discusses some generic naming schemes, but doesn't address
issues such as ttl values and such, which is the flimsy guesswork that
sorbs has built part of it's database upon and for which causes denial
of service to innocents when wrong.
On another note, has anyone ever talked before about drafting a bcp or
such with respect to blocklists and host interactions before?
Dave Platt
<huey.c...@gmail.com> wrote:
>Dave Platt <dpl...@radagast.org> wrote:
>> The PTR record for this IP has only a 300-second (five-minute) timeout.
>> This doesn't give those who query/examine the IP address any real
>> confidence that it's assigned to a single, stable customer over the
>> long term.
>That statement is, not to put too fine a point on it, stupid.
>To wit:
#snip#
> mx1.mail.yahoo.com. A IN 1800 4.79.181.15
>reverse DNS on all of those IPs is 1200s
>
>Now, given that most of the largest producers and consumers of email
>in the United States all have DNS and rDNS with timeouts set at an
>hour or under, the requirement by SORBS that "The A record for the host
>name needs to have a TTL of at least 43200 seconds", and the statement
>"This doesn't give those who query/examine the IP address any real
>confidence that it's assigned to a single, stable customer over the
>long term" are both clearly at odds with reality, unless you really
>don't think that people like AOL, hotmail, and yahoo are 'stable
>customers', in which case there is likely another obvious source of
>error.
I stand by my statement as written. I think you're reading something
into it which I did not write.
What I said was that a short TTL on a PTR record does not give any
real confidence that the address is assigned to a single, stable
customer over the long term. I believe that's true.
I didn't say that a short TTL on a PTR was *evidence* of
untrustworthiness or a dynamic assignment. I did say that a short TTL
is a *lack*of*evidence* of long-term stability. As they say, "absence
of evidence is not evidence of absence."
In all of the cases you cited, the records belong to a domain which is
*known* to be a large, stable company. In these cases, if I look at
the PTR record, I wouldn't consider the short TTL to be relevant
(except insofar as it may force more DNS lookups than are really
necessary), and I wouldn't be inclined to put any of these records on
a "possibly dynamic" list as a result.
Neither would/has SORBS, to the best of my knowledge. They haven't
(to the best of my knowledge) added any of those AOL/Hotmail/Yahoo
relays to the DUHL, as far as I know.
SORBS apparently wishes to see something that they consider *evidence*
of long-term stability - specifically, a longer TTL on the PTR. This
is one piece of evidence which isn't technically hard to provide, and
which can easily be verified by their automated de-listing system.
I suspect that they may well allow other forms of evidence, but these
would probably have to be verified manually by their volunteer
staff... and so they probably discourage this approach.
--
Dave Platt <dpl...@radagast.org> AE6EO
Hosting the Jade Warrior home page: http://www.radagast.org/jade-warrior
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!
--
Real Name
communicate:
> AFAIK for SORBS, it appears for the most part that the word
> of the IP whois direct allocation contact trumps all others.
Unless rDNS clearly indicates that the IP in question is dynamic (with
the words "dyn", "dial", "pool" etc showing in the PTR RR's).
Joe Bednorz
>As I stated, since SORBS doesn't have the resources - technical and
>personell - to address the problem it is creating, and the queue wait
>times for service is at least over a week at this point in time.
>Something has to give.
Demand your money back.
--
Alice in Wonderland Interactive Adventure: <http://www.ruthannzaroff.com/wonderland/>
Baen Free Online SciFi Library: <http://www.baen.com/library/>
All the best,
Joe Bednorz
Stephen Satchell
> As I stated, since SORBS doesn't have the resources - technical and
> personell - to address the problem it is creating, and the queue wait
> times for service is at least over a week at this point in time.
> Something has to give. One solution is to stop using bogus criteria
> such as the flimsy rdns test, a test which does not pass the technical
> validity muster.
It doesn't? From http://email.amhosting.com/dyn.html:
"There is no RFC that mandates every IP address have a valid host name
record. There is RFC 1912, "Common DNS Operational and Configuration
Errors", which says this on the topic:
"1: Every Internet-reachable host should have a name. The
consequences of this are becoming more and more obvious. Many services
available on the Internet will not talk to you if you aren't correctly
registered in the DNS.
"2: Make sure your PTR and A records match. For every IP address,
there should be a matching PTR record in the in-addr.arpa domain. If a
host is multi-homed, (more than one IP address) make sure that all IP
addresses have a corresponding PTR record (not just the first one).
Failure to have matching PTR and A records can cause loss of Internet
services similar to not being registered in the DNS at all. Also, PTR
records must point back to a valid A record, not a alias defined by a
CNAME. It is highly recommended that you use some software which
automates this checking, or generate your DNS data from a database which
automatically creates consistent data.
"More and more mail administrators are requiring that their peers
observe these best practices, and will reject mail where the
administrator has not taken the time and trouble to do the job right."
-==-
Your opinion is yours, and you can use that opinion to set policy on
your mail servers. I think the rDNS test is a very robust way of
dealing with the bot-net problem, as very few bot-net operators check to
see if their victims have a host name in the rDNS for the box they take
over.
I get five million e-mail connection attempts a day. Of those five
million connection attempts, I pass through four hundred thousand
e-mails. If you have a better solution, one that will not require me to
at least double the number of mail servers I have to run, trot it out.
Oh, and I'm not using SORBS to make this determiniation. I have a
little PERL script that does the examination for generic host names, and
PostFix has a hook for a Perl-written policy modules. It's far cheaper
for me to do the calculations myself (my mail servers have plenty of
extra cycles avaiable; it's disk and network that are tight) than to try
to look up anything.
> You are the second person to suggest that the
> potential damage of incorrect listings does not outweigh the
> inconveience and time demands required to do 'a better job', and by
> extension, why bother with doing a better job with validating the
> listings first. I have a strong objection because the damage is
> substantial to otherwise innocent domains, and sorbs moving first is
> the equivelent of taking the first swing.
We are all required to do the best job we can, to follow community
standards when setting up our equipment, our networks, our services.
Why should you be an exception? In the time it took you to write your
screed, you could have FIXED your problem yourself, by going back and
fixing your rDNS and DNS for your mail servers.
Are you claiming negligence on Matthew's part? Just because some people
are too lazy to do the right thing, such as follow Internet Best
Practice, doesn't mean that Matthew has to bend over backward to
accomodate people who don't care.
>
> With respect to this standard you think professionally managed space
> should adhere to, I don't beleive it passes technical muster and I can
> quote procedures straight out of the cricket book
Cricket Book != Standards
Cricket Book != Community Expectations
>which will result in
> exactly this problem. For example, just exactly how does sorbs know
> that I'm not about to move servers around in my domain?
Why should SORBS care? You reduce the TTL for one week, change your
zone files, and with the change you set the TTL back. What's so hard
about that?
> Reducing the
> ttl is a necessary step in order to accomplish this, just read the
> cricket book for some examples reccomended. There are others, but the
> point is this - sorbs current stated procedure does not pass the
> technical muster.
Neither does spamming, but spam happens anyway. (Ever read RFC-1855?)
The trust model of the Internet has changed dramatically since the first
widespread publication of the DDN Protocol Handbook in 1985. Community
expectations have changed with the rampant abuse that has grown since
the NFS gave up being in the backbone business.
Members of the community have had to react to the less-than-one-percent
of the bad apples out there. Sorry you got caught up in it for your lax
attitude toward administrator, but some of us have customers that expect
our servers not to crash just because some people think their message is
so important they have to send it thousands of times.
It's a form of riot control. Riot control is never fair to everyone. I
could tell you stories...
Laurence F. Sheldon, Jr.
>>http://www.ietf.org/internet-drafts/draft-msullivan-dnsop-generic-naming-schemes-00.txt
>
> This draft discusses some generic naming schemes, but doesn't address
> issues such as ttl values and such, which is the flimsy guesswork that
> sorbs has built part of it's database upon and for which causes denial
> of service to innocents when wrong.
>
> On another note, has anyone ever talked before about drafting a bcp or
> such with respect to blocklists and host interactions before?
I am a newcomer in the wonderful world of the Internet and its
development and the documentation thereof, but I was always of the
impression that a Best Current Practices document documented the Current
(as contrasted with proposed) Best Practices, and that a newcomer could
use the collection of BCP's to quickly come up to speed on what other
people are doing, have been doing for some time, and have determined
from some years of experience what works (or worked) well.
Documents for new procedures not currently in place I would expect to
have been labeled "Experimental" or "Proposed Standards Track" or
something similar.
--
Requiescas in pace o email
Ex turpi causa non oritur actio
http://members.cox.net/larrysheldon/
--
Stephen Satchell
> E-Mail Sent to this address will be added to the BlackLists attempted to
> communicate:
>
>
>>AFAIK for SORBS, it appears for the most part that the word
>> of the IP whois direct allocation contact trumps all others.
>
>
> Unless rDNS clearly indicates that the IP in question is dynamic (with
> the words "dyn", "dial", "pool" etc showing in the PTR RR's).
>
Or unless rDNS clearly indicates that the IP in question is dynamic with
most or all of the IP address encoded in it, whether it be dot-quad,
decimal, or hexidecimal. SORBS may not consider such addresses as
dynamic, but I do, and I block mail that does not have an Honest-to-Pete
FQDN that means something.
Your milage may vary.
By the way, I don't use the SORBS blocklist publication at all. It's
cheaper, in resources, given five million connection attempts per server
per day, to do the search of the host name each time within my Postfix
policy module. I've profiled my PostFix policy module, and the
generic-DNS test takes less resources to perform than the white-list
search to turn off the generic-DNS test.
(The difference is so striking that I'm thinking about turning things
around: perform the test, THEN check the white-list. I think it would
be a gain all around.)
I get the idea that I'm not the only one doing this. In fact, it was a
series of theads in NANAE that gave me the idea to do this on-the-fly,
instead of relying on external analysis and reaction. While I don't
have exact numbers to hand (my log analyzer needs work, so that it can
finish the job analyzing one log before log rotation happens -- I'm
moving the analysis to C) casual examiniation of my logs show thousands
and thousands of rejects for "dynamic/residential".
So fix the DNS for your mail server, if you want *any* chance of getting
mail to me or my customers.
E-Mail Sent to this address will be added to the BlackLists
> Real Name wrote:
>> BlackList attempted to communicate:
>>> AFAIK for SORBS, it appears for the most part that the word
>>> of the IP whois direct allocation contact trumps all others.
>>
>> Unless rDNS clearly indicates that the IP in question is
>> dynamic (with the words "dyn", "dial", "pool" etc showing
>> in the PTR RR's).
>
> Or unless rDNS clearly indicates that the IP in question is
> dynamic with most or all of the IP address encoded in it,
> whether it be dot-quad, decimal, or hexidecimal.
> SORBS may not consider such addresses as dynamic, but I do,
> and I block mail that does not have an Honest-to-Pete FQDN
> that means something.
>
> Your milage may vary.
>
> By the way, I don't use the SORBS blocklist publication at
> all. It's cheaper, in resources, given five million
> connection attempts per server per day, to do the search
> of the host name each time within my Postfix policy module.
... and you don't have to worry about the DNSbl getting DDOSed,
connectivity, availability, uptime, stability, ...
(local copies of a DNSbl offload some of that).
If you maintain your own rejecting criteria (pattern matching,
Black / White Lists, Bayes, ...) you might lose some value
of 3rd party detection of abuse before it reaches you,
however you can insure it is doing exactly what you want;
If it ever doesn't you have no one else to complain about
(as keeping the service working, updated, maintained, tuned
is all your own responsibility).
--
E-Mail Sent to this address <Blac...@Griffin-Technologies.net>
will be added to the BlackLists.
E-Mail Sent to this address will be added to the BlackLists
> I am a newcomer in the wonderful world of the Internet and
> its development and the documentation thereof, but I was
> always of the impression that a Best Current Practices
> document documented the Current (as contrasted with proposed)
> Best Practices, and that a newcomer could use the collection
> of BCP's to quickly come up to speed on what other people are
> doing, have been doing for some time, and have determined
> from some years of experience what works (or worked) well.
>
> Documents for new procedures not currently in place I would
> expect to have been labeled "Experimental" or "Proposed
> Standards Track" or something similar.
The Internet Standards Process
http://www.rfc-editor.org/rfc/rfc2026.txt
(BCP: Page 15 / Section 5. )
--
E-Mail Sent to this address <Blac...@Griffin-Technologies.net>
will be added to the BlackLists.
--
Laurence F. Sheldon, Jr.
> "There is no RFC that mandates every IP address have a valid host name
> record. There is RFC 1912, "Common DNS Operational and Configuration
> Errors", which says this on the topic:
RFC 1912 is an Informational RFC. Quoting from it:
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^
Unquote.
--
Requiescas in pace o email
Ex turpi causa non oritur actio
http://members.cox.net/larrysheldon/
--
Hal Murray
> most or all of the IP address encoded in it, whether it be dot-quad,
>decimal, or hexidecimal. SORBS may not consider such addresses as
>dynamic, but I do, and I block mail that does not have an Honest-to-Pete
>FQDN that means something.
I think "dynamic" is misleading. How about "generic"?
In the old days (before cable modems and xDSL), most generic
host names were dialups and hency most likely dynamic. That
was also before trojans. The reason for blocking them was
inaction on the ISPs part. ISPs often claimed they didn't
know which user was using a dialup, even if you gave them
the exact time. I assume that was a combination of not
being willing to look hard enough and not having tools
to help with the search.
Today, many DSL and cable IP addresses are pseudo dynamic.
They are assigned via DHCP, but the lifetime is long (week?).
Some actually are static.
In any case, the source is probably a trojaned windows box.
The main problem is not that the ISP can't figure out who
is responsible, but rather than they don't act fast enough.
So blocking generic addresses makes sense. It's just that
calling them dynamic confuses things reasonably often,
especially when used by DNSBLs that say one thing and implement
another.
--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.
--
Stephen Satchell
>>Or unless rDNS clearly indicates that the IP in question is dynamic with
>> most or all of the IP address encoded in it, whether it be dot-quad,
>>decimal, or hexidecimal. SORBS may not consider such addresses as
>>dynamic, but I do, and I block mail that does not have an Honest-to-Pete
>>FQDN that means something.
>
>
> I think "dynamic" is misleading. How about "generic"?
Because Joe Six Pack doesn't understand what "generic" means in the
context of host names. Over the months I've tried a number of
combinations of error messages and finally settled on this. (From the
logs of one of my mail servers:)
May 21 17:45:39 mx11 postfix/smtpd[30063]: NOQUEUE: reject: RCPT from
unknown[200.44.209.1]: 554 <a4...@a3businesssolutions.com>: Recipient
address rejected: Host name 200-44-209-1.genericrev.cantv.net
[200.44.209.1] appears to be for dynamic/residential servicei; see
http://email.amhosting.com/dyn.html; from=<brand...@earthlink.net>
to=<a4...@a3businesssolutions.com> proto=SMTP helo=<earthlink.net>
Your argument makes sense from one standpoint; the reality is that we
have to deal with real-world, non-computer people. If you follow the
link embedded in the reject message, you will find I define what a
generic host name is.
Hmmm...I literally picked this particular log line at random. Look at
the host name: it contains the string "genericrev"! Learn something
new every day...
Atro Tossavainen
> Hmmm...I literally picked this particular log line at random. Look at
> the host name: it contains the string "genericrev"! Learn something
> new every day...
And you also managed to catch a spam delivery attempt from the network
of Cantv, abuse@ for which is manned by Luis (of the generic rDNS BCP
document fame, along with Mat :)
--
Atro Tossavainen (Mr.) / The Institute of Biotechnology at
Systems Analyst, Techno-Amish & / the University of Helsinki, Finland,
+358-9-19158939 UNIX Dinosaur / employs me, but my opinions are my own.
< URL : http : / / www . helsinki . fi / %7E atossava / > NO FILE ATTACHMENTS
--
fermin....@gmail.com
complaint to their support address - a response between 48 hours and up
to 28 days (!!) is just not acceptable.
The way it is now, those jerks are interfering with my business, since
my servers, which do all have fixed, non-dynamic IP adresses, have been
tagged as being "dynamic". Trying to correct that problem via that joke
they call a website doesn't work - I get server errors (HTTP 500) or
timeouts trying to access it.
Mike Andrews
> imo, the yahoos at sorbs are doing more harm than good. Try sending a
> complaint to their support address - a response between 48 hours and up
> to 28 days (!!) is just not acceptable.
Ah, but in the opinions of the people using SORBS, it does more good
than harm. My experience with SORBS (yes, I've been listed -- and got
out again) has been that responses tenbd strongly to come in less
than 48 hours.
> The way it is now, those jerks are interfering with my business, since
> my servers, which do all have fixed, non-dynamic IP adresses, have been
> tagged as being "dynamic". Trying to correct that problem via that joke
> they call a website doesn't work - I get server errors (HTTP 500) or
> timeouts trying to access it.
Erm ... you're coming here to try to get something fixed, or just to
blow off steam? Which is it? Because if you want something fixed,
then abusing the people who can fix it may not help your case, and
if you're just blowing off steam, then I expect the rest of us have
other, more pressing, things to do.
--
Mike Andrews, W5EGO
mi...@mikea.ath.cx
Tired old sysadmin
phil-new...@ipal.net
| imo, the yahoos at sorbs are doing more harm than good. Try sending a
| complaint to their support address - a response between 48 hours and up
| to 28 days (!!) is just not acceptable.
|
| The way it is now, those jerks are interfering with my business, since
| my servers, which do all have fixed, non-dynamic IP adresses, have been
| tagged as being "dynamic". Trying to correct that problem via that joke
| they call a website doesn't work - I get server errors (HTTP 500) or
| timeouts trying to access it.
If you have had mail rejected due to a listing in blacklist "FOO", and you
feel that blacklist "FOO" is not worthy of being used to refuse email, then
make the suggestion to the people you are trying to send mail to (assuming
they want your mail) that they open another email box on another provider
that does not use blacklist "FOO". Or as an alternative, ask them to ask
their provider to stop using blacklist "FOO" for blocking, and maybe just
use it for quarantining, or for selecting mail for expanded analysis. You
might even offer to host a new mailbox on your mail server for them (then
your mail would surely never bounce).
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
Angel
> imo, the yahoos at sorbs are doing more harm than good. Try sending a
> complaint to their support address - a response between 48 hours and up
> to 28 days (!!) is just not acceptable.
Who decides what is and what is not acceptable? Are the SORBS
maintainers employed by you? Do you have a contract with them? Are you
paying them for service in any way?
If the answer to all those was 'no', then on what ground are you
claiming that it is unacceptable? SORBS is provided free of charge, at
the operator's own expense. They have no legal obligations to you
whatsoever.
> The way it is now, those jerks are interfering with my business, since
> my servers, which do all have fixed, non-dynamic IP adresses, have been
> tagged as being "dynamic". Trying to correct that problem via that joke
> they call a website doesn't work - I get server errors (HTTP 500) or
> timeouts trying to access it.
SORBS cannot 'interfere with your business'. They have no access to your
servers and cannot prevent you from sending out any email at all. Some
admins may use their services to help them block unwanted email. SORBS is
a useful service to me that catches a lot of spam before it is even
delivered. YMMV.
--
The three reasons why there is a spam problem:
Greed, Gullibility & Micro$oft.
Stephen Satchell
> On Tue, 23 May 2006 18:53:37 GMT, Angel wrote:
>>SORBS cannot 'interfere with your business'. They have no access to your
>>servers and cannot prevent you from sending out any email at all. Some
>>admins may use their services to help them block unwanted email. SORBS is
>>a useful service to me that catches a lot of spam before it is even
>>delivered. YMMV.
>
> fact preventing my mail servers to reach other servers.
What is your IP address again? What does your host name for that IP
address look like? What are the TTLs on the A and PTR record?
phil-new...@ipal.net
| The problem is that *my* server is blacklisted. Just opening new accounts
| on one of my servers won't do a thing.
The problem is, I tried to whitelist your server, and it rejected
*my* server
as being an invalid hostname.
Angel
> On Tue, 23 May 2006 18:53:37 GMT, Angel wrote:
>
>>> imo, the yahoos at sorbs are doing more harm than good. Try sending a
>>> complaint to their support address - a response between 48 hours and up
>>> to 28 days (!!) is just not acceptable.
>> Who decides what is and what is not acceptable? Are the SORBS
>> maintainers employed by you? Do you have a contract with them? Are you
>> paying them for service in any way?
>
Oh yes, there will be a problem. All the kooks will crawl out of the
woodwork and accuse SORBS of blackmailing. Well, some do so already.
> The problem is, that they are offering
> this kind of service and many companies have started using their DNS
> blacklist to filter spam. No problem so far - if the process of removing a
> wrongfully added ip range or address weren't so tedious. And don't get me
> started on "response times"...
A free service is worth exactly what you pay for it. Since nobody is
paying SORBS anything... You are trying to make demands ("They must give
better service!" "They must delist promptly!") from a party you have no
authority over.
>>> The way it is now, those jerks are interfering with my business, since
>>> my servers, which do all have fixed, non-dynamic IP adresses, have been
>>> tagged as being "dynamic". Trying to correct that problem via that joke
>>> they call a website doesn't work - I get server errors (HTTP 500) or
>>> timeouts trying to access it.
>> SORBS cannot 'interfere with your business'. They have no access to your
>> servers and cannot prevent you from sending out any email at all. Some
>> admins may use their services to help them block unwanted email. SORBS is
>> a useful service to me that catches a lot of spam before it is even
>> delivered. YMMV.
>
> Yes, they do. By supplying false information about my system, they are in
> fact preventing my mail servers to reach other servers.
The fact that you get 5xx messages from said other servers proves that
your server was able to reach them okay. The refusal is done on the
receiving end, your servers themselves are completely untampered with.
You are not being denied your right to send email. Within the borders of
your own network, you can do whatever you want. But as soon as your
email leaves your network, all your rights end and your email is at the
whim of the admins on the receiving ends. Some of those chose
voluntarily to consult SORBS to determine what to accept and what not.
Since you never had any rights to have your email delivered to begin
with, you are not being denied anything you are entitled to.
--
Proud member of the CABAL and officially recognized SPEWS Kook.
Who are Moris and Brad Jesness?
http://www.pearlgates.net/nanae/kooks/
Winston
# If you have had mail rejected due to a listing in blacklist "FOO", and you
# feel that blacklist "FOO" is not worthy of being used to refuse email, then
# make the suggestion to the people you are trying to send mail to (assuming
# they want your mail) that they open another email box on another provider
# that does not use blacklist "FOO". Or as an alternative, ask them to ask
# their provider to stop using blacklist "FOO" for blocking, and maybe just
# use it for quarantining, or for selecting mail for expanded analysis. You
# might even offer to host a new mailbox on your mail server for them (then
# your mail would surely never bounce).
Fermin Sanchez <fermin....@gmail.com> replied:
> The problem is that *my* server is blacklisted. Just opening new accounts
> on one of my servers won't do a thing.
Really?! Either you didn't understand Phil's last sentence, or you're
using SORBS to block mail from your own servers to your own local users.
One of those two should be fixable. Creating local accounts for remote
users may not be appealling, though.
-WBE
Stephen Satchell
> On Tue, 23 May 2006 16:56:35 GMT, phil-new...@ipal.net wrote:
>[snip]
>>If you have had mail rejected due to a listing in blacklist "FOO", and you
>>feel that blacklist "FOO" is not worthy of being used to refuse email, then
>>make the suggestion to the people you are trying to send mail to (assuming
>>they want your mail) that they open another email box on another provider
>>that does not use blacklist "FOO". Or as an alternative, ask them to ask
>>their provider to stop using blacklist "FOO" for blocking, and maybe just
>>use it for quarantining, or for selecting mail for expanded analysis. You
>>might even offer to host a new mailbox on your mail server for them (then
>>your mail would surely never bounce).
>
>
> on one of my servers won't do a thing.
Why wouldn't it do a thing? If you create a mailbox on your server for
your recipients, YOU control where and how the mail is delivered. Your
recipients would then use POP3 to log into the mailbox you provide.
Simple. Easy. Fast. And, above all, virtually foolproof.
phil-new...@ipal.net
| On Mon, 29 May 2006 19:18:48 GMT, Winston wrote:
|
|>> The problem is that *my* server is blacklisted. Just opening new accounts
|>> on one of my servers won't do a thing.
|> Really?! Either you didn't understand Phil's last sentence, or you're
|> using SORBS to block mail from your own servers to your own local users.
|> One of those two should be fixable. Creating local accounts for remote
|> users may not be appealling, though.
|
| I'm not a native English speaker/writer.
|
| As an example, I tried to send a mail to a business associate at
| microsoft.com. It got bounced back to me - their (Microsoft's) mail server
| told me that my server was/is listed on SORBS.
|
| Clear now? Sorry about the language barrier, if that was the problem.
It seems Microsoft does not want spam. Ironically, Microsoft is a huge
enabler of the high volume of spam.
Anyway, without your address, I cannot speculate on possible reason why
your address might still be listed in SORBS, or why it might be taking
longer than others to be delisted from SORBS. I'm not very knowledgeable
about SORBS, but others here probably are. Armed with information like
your address, their comments could be more accurately reflecting the real
reasons for your difficulties.
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-200...@ipal.net |
|------------------------------------/-------------------------------------|
Laurence F. Sheldon, Jr.
Except that his server is blacklisted.
--
Requiescas in pace o email
Ex turpi causa non oritur actio
http://members.cox.net/larrysheldon/
--
Seth Breidbart
Laurence F. Sheldon, Jr. <LarryS...@cox.net> wrote:
>Stephen Satchell wrote:
>> Why wouldn't it do a thing? If you create a mailbox on your server for
>> your recipients, YOU control where and how the mail is delivered. Your
>> recipients would then use POP3 to log into the mailbox you provide.
>>
>> Simple. Easy. Fast. And, above all, virtually foolproof.
>
>Except that his server is blacklisted.
I don't know of any POP client that cares.
Seth
Laurence F. Sheldon, Jr.
I don't know what happened to that attempt, I hope it doesn't turn up
as a "premature postulation". (Love that!)
Fermin Sanchez wrote:
> On Mon, 29 May 2006 19:18:48 GMT, Winston wrote:
>
>>>The problem is that *my* server is blacklisted. Just opening new accounts
>>>on one of my servers won't do a thing.
>>
>>Really?! Either you didn't understand Phil's last sentence, or you're
>>using SORBS to block mail from your own servers to your own local users.
>>One of those two should be fixable. Creating local accounts for remote
>>users may not be appealling, though.
>
> It's also possible that I somehow didn't get my meaning through. After all,
> I'm not a native English speaker/writer.
>
> As an example, I tried to send a mail to a business associate at
> microsoft.com. It got bounced back to me - their (Microsoft's) mail server
> told me that my server was/is listed on SORBS.
>
> Clear now? Sorry about the language barrier, if that was the problem.
It seemed clear to me the first time, and I don't see anything wrong
with your English.
The problem appears to be that you appear to be served over an ADSL
line, and your provider has rudely and obviously in open contempt for
SORBS named your IP adsl.....
I doubt that there is an useful solution available to you.
--
Requiescas in pace o email
Ex turpi causa non oritur actio
http://members.cox.net/larrysheldon/
--
Winston
additional information in Fermin's latest reply, Phil's suggestion was
equivalent to: "One way to get around the problem of the [Microsoft] user
not being able to get your mail [at Microsoft] would be to give the
[Microsoft] user an email account on Fermin's server."]
Fermin Sanchez <fermin....@gmail.com> wrote:
>>> The problem is that *my* server is blacklisted. Just opening new accounts
>>> on one of my servers won't do a thing.
I replied:
>> Really?! Either you didn't understand Phil's last sentence, or you're
>> using SORBS to block mail from your own servers to your own local users.
>> One of those two should be fixable. Creating local accounts for remote
>> users may not be appealling, though.
I probably should have included a ":-)".
Fermin Sanchez <fermin....@gmail.com> writes:
> It's also possible that I somehow didn't get my meaning through. After
> all, I'm not a native English speaker/writer.
>
> As an example, I tried to send a mail to a business associate at
> microsoft.com. It got bounced back to me - their (Microsoft's) mail
> server told me that my server was/is listed on SORBS.
>
> Clear now? Sorry about the language barrier, if that was the problem.
You did fine the first time, and I believe Phil and I understood you.
What Phil suggested was that there's a completely different solution that
has the advantage of not needing any change at SORBS or Microsoft -- give
the Microsoft user an email account on your system. It might not be
practical, but if it is, it should work.
Andy Hood
> My mail domain is fermin.ch, Mailaddress is in that domain,
> give...@givenname.com if you catch my meaning. "nslookup -querytype=mx
> fermin.ch" should tell you from what IP address mail originates.
fermin.ch mail exchanger = 20 mail2.fermin.ch.
fermin.ch mail exchanger = 10 mail1.fermin.ch.
mail1.fermin.ch internet address = 213.200.252.84
mail2.fermin.ch internet address = 213.200.252.85
84.252.200.213.in-addr.arpa domain name pointer mail.fermin.ch.
85.252.200.213.in-addr.arpa domain name pointer adsl-213-200-252-85.cybernet.ch.
mail.fermin.ch has address 213.200.252.84
So:
the reverse lookups do not match your MX records,
84.252.200.213.in-addr.arpa is the only proper reverse in that /26 and,
mail2.fermin.ch has a name classed as dynamic.
You'd do better if cybernet.ch dropped the reverses for the rest of the
addresses, or changed them to one of the patterns accepted as meaning (my
definition) "this address is statically assigned to someone who either
does not have forward DNS and hence doesn't need reverse, or does not want
to pay to for having the reverse hosted or delegated".
--
Never tell people how to do things. Tell them WHAT to
do and they will surprise you with their ingenuity.
-- Gen. George S. Patton, Jr.
Seth Breidbart
Fermin Sanchez <fermin....@gmail.com> wrote:
>On Tue, 30 May 2006 02:16:13 GMT, Stephen Satchell wrote:
>
>>> The problem is that *my* server is blacklisted. Just opening new accounts
>>> on one of my servers won't do a thing.
>> Why wouldn't it do a thing? If you create a mailbox on your server for
>> your recipients, YOU control where and how the mail is delivered. Your
>> recipients would then use POP3 to log into the mailbox you provide.
>>
>> Simple. Easy. Fast. And, above all, virtually foolproof.
>
>have yet another mail account on yet another server?
Do they make money by doing business with you?
Seth
Stephen Satchell
From his own mail? And who blocks Pop3 access?
phil-new...@ipal.net
| On Tue, 30 May 2006 02:16:13 GMT, Stephen Satchell wrote:
|
|>> on one of my servers won't do a thing.
|> Why wouldn't it do a thing? If you create a mailbox on your server for
|> your recipients, YOU control where and how the mail is delivered. Your
|> recipients would then use POP3 to log into the mailbox you provide.
|>
|> Simple. Easy. Fast. And, above all, virtually foolproof.
|
| have yet another mail account on yet another server?
Why would your business associates choose to use SORBS to block mail without
whitelisting you to override SORBS on their servers?
Actually, the idea of hosting the mailboxes for your own mailing list(s)
is a very practical idea. You can restrict deliver to them to only what
you send, and thus keep them 100% clear of all spam. Readers can add the
new mailbox account to their user agent (programs like Outlook and the
mail agents in web browsers handle this well). And it beats having lots
of mail all mingled together like one gets with everything coming to one
box. I think you'd find a lot of people would prefer this. And you'd
never have to worry about being in any blacklist.
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-200...@ipal.net |
|------------------------------------/-------------------------------------|
--
phil-new...@ipal.net
| On Tue, 30 May 2006 11:39:38 GMT, phil-new...@ipal.net wrote:
|
|>| As an example, I tried to send a mail to a business associate at
|>| microsoft.com. It got bounced back to me - their (Microsoft's) mail server
|>| told me that my server was/is listed on SORBS.
|>|
|>| Clear now? Sorry about the language barrier, if that was the problem.
|> It seems Microsoft does not want spam. Ironically, Microsoft is a huge
|> enabler of the high volume of spam.
|
| what mail system they have...
|
|> Anyway, without your address, I cannot speculate on possible reason why
|> your address might still be listed in SORBS, or why it might be taking
|> longer than others to be delisted from SORBS. I'm not very knowledgeable
|> about SORBS, but others here probably are. Armed with information like
|> your address, their comments could be more accurately reflecting the real
|> reasons for your difficulties.
|
| give...@givenname.com if you catch my meaning. "nslookup -querytype=mx
| fermin.ch" should tell you from what IP address mail originates.
=============================================================================
phil@hadar:/home/phil 393> dnsmx fermin.ch.
fermin.ch. 86400 IN MX 10 mail1.fermin.ch.
fermin.ch. 86400 IN MX 20 mail2.fermin.ch.
phil@hadar:/home/phil 394> dnsa mail1.fermin.ch. mail2.fermin.ch.
mail1.fermin.ch. 86400 IN A 213.200.252.84
mail2.fermin.ch. 86400 IN A 213.200.252.85
phil@hadar:/home/phil 395> dnsptr 213.200.252.84 213.200.252.85
84.252.200.213.in-addr.arpa. 86400 IN PTR mail.fermin.ch.
85.252.200.213.in-addr.arpa. 86400 IN PTR cust.static.213-200-252-85.cybernet.ch.
phil@hadar:/home/phil 396> dnsa mail.fermin.ch. cust.static.213-200-252-85.cybernet.ch.
mail.fermin.ch. 86400 IN A 213.200.252.84
cust.static.213-200-252-85.cybernet.ch. 86400 IN A 213.200.252.85
phil@hadar:/home/phil 397>
=============================================================================
So I assume one of those 2 mail servers is your outbound server.
If not, then you need to say what its address or hostname is.
Your address is in a pool of generic addresses. What I mean by that
is that of the 256 addresses in 213.200.252.0/24, most have the name
of the ISP, not of the customer. Maybe they are unassigned? That is
not clear. The /24 could be blocked for this reason by some networks.
I find no SPEWS entries for these addresses.
Laurence F. Sheldon, Jr.
> On Tue, 30 May 2006 16:15:04 +0000, Fermin Sanchez wrote:
>
>>My mail domain is fermin.ch, Mailaddress is in that domain,
>>give...@givenname.com if you catch my meaning. "nslookup -querytype=mx
>>fermin.ch" should tell you from what IP address mail originates.
It will tell me nothing of the sort!
It will tell my computer where to send email. There is no RR in the DNS
with fields defined to identify the source of a particular email.
--
Requiescas in pace o email
Ex turpi causa non oritur actio
http://members.cox.net/larrysheldon/
--
Real Name
>>>My mail domain is fermin.ch, Mailaddress is in that domain,
>>>give...@givenname.com if you catch my meaning. "nslookup -querytype=mx
>>>fermin.ch" should tell you from what IP address mail originates.
>
> It will tell me nothing of the sort!
>
> It will tell my computer where to send email. There is no RR in the DNS
> with fields defined to identify the source of a particular email.
There is, however, an SPF record on fermin.ch that'll give a clue as to
where mail should be coming from. But I agree that the MX has nothing to
do with mail coming from a domain.
phil-new...@ipal.net
| On Thu, 1 Jun 2006 00:07:35 GMT, Laurence F. Sheldon, Jr. wrote:
|
|>> Clear now? Sorry about the language barrier, if that was the problem.
|>
|> It seemed clear to me the first time, and I don't see anything wrong
|> with your English.
|>
|> The problem appears to be that you appear to be served over an ADSL
|> line, and your provider has rudely and obviously in open contempt for
|> SORBS named your IP adsl.....
|
| for a public IP subnet of static addresses.
|> I doubt that there is an useful solution available to you.
|
All upper case "SPAM" is a registered trademark of Hormel corporation used
for its canned processed meat product. Please don't use that term for the
references to bulk unsolicited email. The correct term is "spam" in all
lower case (or capitalized under language rules such as at the beginning
of a sentence).
Of course the technology of the connection doesn't automatically mean the
host at the other end will leak spam. Statistically speaking, though, it
does increase the chances if all that is known is the technology and it
happens to be that which is also used for pooled connectivity to homes and
offices. BTW, office computers are just as likely to be leakers of spam
as home computers.
Often, it is whole pools of addresses that get listed when listings are
based on IP address, which is what most DNSBLs are. It is not practical
to list each and every IP address individually in a database. Thus, many
listings of pools go by /24 block. Then the judgement isn't so much about
the individual IPs in each block, but the general nature of the block as
a whole. If it looks like a pool, smells like a pool ...
Whether your address is listed in SORBS for this reason I do not know.
As an email sender, you need to distinguish what you send above and beyond
all spam, in a way that can be authenticated during the SMTP session that
sends it. And you have to do this even though spammers are trying their
own very best to distinguish their junk. You have the advantage of being
in control of your domain name, and where you host it, etc. Spammers have
no control over _your_ domain (unless you've made a security mistake and
allowed that control). It is _not_ the responsibility of the recipient's
server to figure out if your server is distinguished any more than certain
basic checks that are good enough to let you do your part. If you wish to
rise above the spam noise, you must do that yourself; most others will not
dig for the jems in the muck.
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-200...@ipal.net |
|------------------------------------/-------------------------------------|
--
Seth Breidbart
Fermin Sanchez <fermin....@gmail.com> wrote:
>Why not? ADSL doesn't automatically mean SPAM and/or dynamic addresses.
No, it doesn't. But some people believe that there is a high enough
correlation between rDNS with "ADLS" in the name and spam emission to
be useful. Their servers, their rules.
Seth
Laurence F. Sheldon, Jr.
> On Thu, 1 Jun 2006 00:07:35 GMT, Laurence F. Sheldon, Jr. wrote:
>>I doubt that there is an useful solution available to you.
>
> Why not? ADSL doesn't automatically mean SPAM and/or dynamic addresses.
Because the blocklist operators are a power unto themselves and I don't
know a way around it.
I have said it before, and I'll say it one last^Wmore time: If you
depend on email, develope a method to exchange mail over a secure tunnel
between you and your correspondents. The public email facitlity is
fatally flawed, ruined by the spammers and scammers, and by the
well-intentioned attempts to save it. (Recall the "We had to burn the
village to the ground to liberate it." thing?)
Stephen Satchell
> Why not? ADSL doesn't automatically mean SPAM and/or dynamic addresses.
Can you say "bot-net"? I knew you could.
As the spammers move from overseas servers to bot-nets, it's even more
critical now to recognize generic addresses from mail sources, and to
block mail from generic addresses.
"adsl" in the domain name is an instant block here.
If you want to talk to my servers, you need to recognize my rules.
Stephen Satchell
> On Tue, 30 May 2006 14:19:32 GMT Fermin Sanchez <fermin....@gmail.com> wrote:
> | On Tue, 30 May 2006 02:16:13 GMT, Stephen Satchell wrote:
> |
> |>> The problem is that *my* server is blacklisted. Just opening new accounts
> |>> on one of my servers won't do a thing.
> |> Why wouldn't it do a thing? If you create a mailbox on your server for
> |> your recipients, YOU control where and how the mail is delivered. Your
> |> recipients would then use POP3 to log into the mailbox you provide.
> |>
> |> Simple. Easy. Fast. And, above all, virtually foolproof.
> |
> | It's not a practical solution. Why should my business associates choose to
> | have yet another mail account on yet another server?
>
> Why would your business associates choose to use SORBS to block mail without
> whitelisting you to override SORBS on their servers?
>
> Actually, the idea of hosting the mailboxes for your own mailing list(s)
> is a very practical idea. You can restrict deliver to them to only what
> you send, and thus keep them 100% clear of all spam. Readers can add the
> new mailbox account to their user agent (programs like Outlook and the
> mail agents in web browsers handle this well). And it beats having lots
> of mail all mingled together like one gets with everything coming to one
> box. I think you'd find a lot of people would prefer this. And you'd
> never have to worry about being in any blacklist.
>
It strikes me that people forget there are programs like fetchmail that
are available on a wide variety of platforms, including M$ Winblows.
You don't like having to check hundreds of mailboxes for critical
correspondence? Fetchmail to the rescue!
I'm beginning to think that for absolute-must-get-through, a separate
mailbox on the SENDING side makes more and more sense...
Laurence F. Sheldon, Jr.
> "adsl" in the domain name is an instant block here.
>
> If you want to talk to my servers, you need to recognize my rules.
And if you were a pill peddler want to peddle pills at clinics I was
administrator for, you would follow mine. Which involved mail machines
at some of our autonomous clinics. Which were connected via some form
of DSL whose DNS was not under our control.
But I'm not an admin anymore, and I don't think anybody who cares about
reliability uses public email anymore.
Before I started filtering them all there were a number of threads on
NANAE that touted "the Scientific Method" (mostly with little
understanding of the term). Here is a place where some scholarly
research might be useful.
What is the shape of the growth-curve of total spam traffic as a
function of the number of IP addresses listed on the several blocking lists?
Is it possible that like the war on open relays the battle has moved on
and we have not?
--
Requiescas in pace o email
Ex turpi causa non oritur actio
http://members.cox.net/larrysheldon/
--
Stephen Satchell
> What is the shape of the growth-curve of total spam traffic as a
> function of the number of IP addresses listed on the several blocking
> lists?
I don't know. The only DNSBL I use now is Spamhaus.
> Is it possible that like the war on open relays the battle has moved on
> and we have not?
It has moved on. It's now a bot-net war.
E-Mail Sent to this address will be added to the BlackLists
> has moved on and we have not?
It appears that trojaned end user PCs are the source of much
of the Spam.
Open Proxies still seem to still be used
(although these are often on trojaned end user PCs).
Classic Open Relays seem few and far between now days.
--
E-Mail Sent to this address <Blac...@Griffin-Technologies.net>
will be added to the BlackLists.
phil-new...@ipal.net
| I'm beginning to think that for absolute-must-get-through, a separate
| mailbox on the SENDING side makes more and more sense...
Now if we could only convince the spammers that this is the way to go :-)
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-200...@ipal.net |
|------------------------------------/-------------------------------------|
--
phil-new...@ipal.net
| Laurence F. Sheldon, Jr. wrote:
|> Is it possible that like the war on open relays the battle
|> has moved on and we have not?
|
| It appears that trojaned end user PCs are the source of much
| of the Spam.
|
| Open Proxies still seem to still be used
| (although these are often on trojaned end user PCs).
|
| Classic Open Relays seem few and far between now days.
I've seeing more open relays, again. Maybe that's because the combination
of DNSBLs and my PBL of generic zombie addresses is more effective, now?
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-200...@ipal.net |
|------------------------------------/-------------------------------------|
--