You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2008/05/08 16:38:57 UTC
[Bug 5905] New: Remove uridnsbl_skip_domain constantcontact.com
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5905
Summary: Remove uridnsbl_skip_domain constantcontact.com
Product: Spamassassin
Version: unspecified
Platform: Other
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P5
Component: Rules
AssignedTo: dev@spamassassin.apache.org
ReportedBy: alex.uribl@gmail.com
uridnsbl_skip_domain constantcontact.com
This ESP is a notorius non COI Sender, darker shade of GREY and can hardly be
considered of value.
The fact that it gets skipped means that local URI blacklists wil not work.
Haven't found a SA skip_uridnsbl_skip_domain so many would appreciate if this
entry could be removed.
Thanks
Alex
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 5905] Remove uridnsbl_skip_domain constantcontact.com
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5905
Justin Mason <jm...@jmason.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|Undefined |3.3.0
--- Comment #14 from Justin Mason <jm...@jmason.org> 2009-07-03 03:19:43 PST ---
more reports of spammy stuff on the users list; let's remove it from the
URIDNSBL whitelist
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 5905] Remove uridnsbl_skip_domain constantcontact.com
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5905
Justin Mason <jm...@jmason.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #15 from Justin Mason <jm...@jmason.org> 2009-07-16 14:29:24 PST ---
: 541...; svn commit -m "bug 5905: remove constantcontact.com from the default
uridnsbl_skip_domain list" rules/25_uribl.cf
Sending rules/25_uribl.cf
Transmitting file data .
Committed revision 794868 ( https://svn.apache.org/viewcvs.cgi?view=rev&rev=794868 ).
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 5905] Remove uridnsbl_skip_domain constantcontact.com
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5905
--- Comment #5 from Alex Broens <al...@gmail.com> 2008-05-08 09:51:29 PST ---
Many user reports I have on file clearly show its their MTAs. and not abused
images, URIS, joejobs, etc.
Also have some which do not come from their MTAs but point to their link
tracking or unsubs.
Hard to say if these are bogus unless you click on them, which one would hardly
want to do.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 5905] Remove uridnsbl_skip_domain constantcontact.com
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5905
--- Comment #10 from Justin Mason <jm...@jmason.org> 2008-05-10 13:03:14 PST ---
whatever Jeff's reasons for whitelisting it -- if URIBL want to be able to
_blacklist_ them or greylist or whatever, it can't be in the skip list...
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 5905] Remove uridnsbl_skip_domain constantcontact.com
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5905
--- Comment #1 from Alex Broens <al...@gmail.com> 2008-05-08 07:48:04 PST ---
I'd like to add rs6.net also present 25_uribl.cf
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 5905] Remove uridnsbl_skip_domain constantcontact.com
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5905
--- Comment #9 from Theo Van Dinter <fe...@apache.org> 2008-05-09 12:10:10 PST ---
fwiw, the skip list came from the top domains that surbl was getting queries
for which they had whitelisted.
it'd be nice to hear from jeff about this.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 5905] Remove uridnsbl_skip_domain constantcontact.com
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5905
--- Comment #2 from Doc Schneider <ma...@maddoc.net> 2008-05-08 09:26:33 PST ---
I see a lot of spam with that url in it so I'm +1 on this!
-Doc
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 5905] Remove uridnsbl_skip_domain constantcontact.com
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5905
--- Comment #12 from Alex Broens <al...@gmail.com> 2008-05-12 00:28:34 PST ---
(In reply to comment #11)
> Quite frankly, I question the value here.
>
>
> Being in the skip list does, and should not, not reflect whether the domain is
> "really white and never sends spam". It should contain domains which are both
> high volume and will not likely appear in any of the blacklists from any of the
> uribl's. This serves the purpose of reducing load on the uribl servers by
> eliminating oft-cited domains that aren't going to produce a positive match.
they would produce a positive match on many private lists IF they weren't
skipped, which was the reason for the initial request.
> Usually this "will not likely appear" is based on the whitelists that surbl.org
> and uribl.com keep. Those whitelists are also selected not on a "never spam"
> basis. They are really for internal use to keep track of domains that they
> already know will cause severe FPs if blacklisted. They serve as a reminder
> when processing spam reports that the domain has already been reviewed and
> switching to black is probably unwise.
see initial request.
> Removing a domain from the skip list only has value if the domain is actually
> listed in one of the surbl.org lists, or uribl.com's black list. (Dallas
> Engelken has explicitly clarified that presence in URIBL_GREY should not be a
> good reason to remove a domain from the skip). At present, constantcontact
> isn't listed in any of these lists.
again, this is not about what URIBL.com/SURBL may or not do, its allowing ppl
to do it if the major BLs don't.
> It appears that at present both major URIBL systems have constantcontact
> whitelisted. A quick check on uribl.com's lookup will show it's been in their
> whitelist since 2005. That same lookup will also verify it's not listed in any
> surbl.org lists, and I assume it's in surbl's whitelist.
irrelevant to the initial request: "The fact that it gets skipped means that
local URI blacklists wil not work."
>
> As for the status of the domain, there are *numerous* legitimate businesses,
> particularly small ones, using it. A quick scan of my own inbox shows 1 chain
> resturant (zpizza), one local fine dining restaurant, and a local independent
> nursery/garden center use it. I also have several business I buy from at my
> office who use them.
which is why global BLs often refrain of making the move to listing bulkers
like these.
This doesn't apply to anybody's private list and should not be SA deciding for
these list operators.
you'd still have the feature to skip the lookups for your sites on your boxes.
> Regardless of how grey constantcontact may be, with such a large base of
> nonspam email using this domain I highly doubt either surbl.org or uribl.com
> will move it to one of their blacklists, because it would throw their false
> positive rate through the ceiling. Too much of that and SA would be forced to
> drop the rule score substantially, and that would make the lists more-or-less
> useless.
irrelevant to the initial request: "The fact that it gets skipped means that
local URI blacklists wil not work."
> That said, if you can convince either uribl.com or surbl.org to list it in one
> of their blacklists (not grey), I'd be happy to go along with removing it from
> the skip list.
irrelevant to the initial request: "The fact that it gets skipped means that
local URI blacklists wil not work."
> In the interim, removing it appears to lack any tangible value other than
> increasing load on both users of spamassassin and the surbl.org/uribl.com DNS
> servers.
the extra load caused by these (cached) lookups is minimal compared to the
amount of unwanted bulk it can stop if listed in private lists.
If the domain can't be removed, then a feature should be added to unskip the
skip.
Alex
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 5905] Remove uridnsbl_skip_domain constantcontact.com
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5905
--- Comment #8 from Loren Wilton <lw...@earthlink.net> 2008-05-09 11:33:31 PST ---
ConstantContact seems to be an opt-OUT (maybe!) marketing information sender.
Some person at some company that uses constantcontact to deliver their spam
signs you up, you have no say in the matter. You now get marketing fluf from
someone you have never heard of, thanks to constantcontact.
The mails usually contain an opt-out link, but I've never dared try one to see
what it would do. I simply assign any constantcontact stuff a score of 99.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 5905] Remove uridnsbl_skip_domain constantcontact.com
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5905
--- Comment #3 from Justin Mason <jm...@jmason.org> 2008-05-08 09:31:49 PST ---
if it's showing up in spam, I'm happy to remove it. patches would help...
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 5905] Remove uridnsbl_skip_domain constantcontact.com
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5905
--- Comment #6 from Michael Peddemors <mi...@linuxmagic.com> 2008-05-08 11:16:58 PST ---
They also have many IP's listed on MIPSPACE for sending out email marketing to
non-opt in addresses. I spoke at length with one of the members of Constant
Contact ISP relations officer (sic) and got the understanding that for most of
the IP's they use, the controls on what email addresses their customers send to
are not very strict. They have 2 IP's which we agreed to exempt from MIPSPACE
(and would love to hear any reports that these two IP's also have problems)
based on those two servers are double optin (well one sends out confirmations,
and the other is the double opt-in server) but it is obvious that there is
problems with giving them an advantage score. I can understand why it may have
been added, as the people who use constant contact want to get their marketing
materials out and tend to complain loudly when their emails get marked as
'Spam' but as long as the emails coming out are being confirmed not to be
always COI, it really should come out, so that the materials can be graded on
the content and nature properly.
The IP's he claimed that their customers are forced to comply with double optin
policies are:
# Constant Contact Double Opt In Invitation Server
!64.95.77.162
# Constant Contact Double Opt In Delivery Server
!64.95.77.164
But for the rest, we have seen many problems as well.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 5905] Remove uridnsbl_skip_domain constantcontact.com
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5905
--- Comment #11 from Matt Kettler <mk...@verizon.net> 2008-05-11 18:30:49 PST ---
Quite frankly, I question the value here.
Being in the skip list does, and should not, not reflect whether the domain is
"really white and never sends spam". It should contain domains which are both
high volume and will not likely appear in any of the blacklists from any of the
uribl's. This serves the purpose of reducing load on the uribl servers by
eliminating oft-cited domains that aren't going to produce a positive match.
Usually this "will not likely appear" is based on the whitelists that surbl.org
and uribl.com keep. Those whitelists are also selected not on a "never spam"
basis. They are really for internal use to keep track of domains that they
already know will cause severe FPs if blacklisted. They serve as a reminder
when processing spam reports that the domain has already been reviewed and
switching to black is probably unwise.
Removing a domain from the skip list only has value if the domain is actually
listed in one of the surbl.org lists, or uribl.com's black list. (Dallas
Engelken has explicitly clarified that presence in URIBL_GREY should not be a
good reason to remove a domain from the skip). At present, constantcontact
isn't listed in any of these lists.
It appears that at present both major URIBL systems have constantcontact
whitelisted. A quick check on uribl.com's lookup will show it's been in their
whitelist since 2005. That same lookup will also verify it's not listed in any
surbl.org lists, and I assume it's in surbl's whitelist.
As for the status of the domain, there are *numerous* legitimate businesses,
particularly small ones, using it. A quick scan of my own inbox shows 1 chain
resturant (zpizza), one local fine dining restaurant, and a local independent
nursery/garden center use it. I also have several business I buy from at my
office who use them.
Regardless of how grey constantcontact may be, with such a large base of
nonspam email using this domain I highly doubt either surbl.org or uribl.com
will move it to one of their blacklists, because it would throw their false
positive rate through the ceiling. Too much of that and SA would be forced to
drop the rule score substantially, and that would make the lists more-or-less
useless.
That said, if you can convince either uribl.com or surbl.org to list it in one
of their blacklists (not grey), I'd be happy to go along with removing it from
the skip list.
In the interim, removing it appears to lack any tangible value other than
increasing load on both users of spamassassin and the surbl.org/uribl.com DNS
servers.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 5905] Remove uridnsbl_skip_domain constantcontact.com
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5905
--- Comment #7 from Alex Broens <al...@gmail.com> 2008-05-08 14:01:03 PST ---
Pls Note:
This about the URL only - no the IPs
If they rate negative SA scores, they can go for HABEAS, SenderSocre and
whatever is used in SA.
If they use the same URLs on SOI and COI, they can easily change it, but SA's
skip works *like* a hardcoded bypass so whatever you want to do, "DNS lookup
wise", doesn't work (URIbl or URIDNSbl)
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 5905] Remove uridnsbl_skip_domain constantcontact.com
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5905
--- Comment #13 from Matt Kettler <mk...@verizon.net> 2008-05-12 05:09:44 PST ---
If it's purely about local blacklists, then a local adjustment would be the
prefered way, IMHO.
However, this runs into the question of do we add a unskip, or just have you
add a uri rule (which isn't subject to the skip) and be done with it?
The main reason to use a DNS system over uri rules is volume of entries. If
you've got lots of entries, URI rules become inefficient due to memory
footprint.
However, there's very few domains in the skip list. So few that if you wanted
to blacklist all of them you could do it efficiently with uri rules.
In light of all that, unless there's hoards of domains, or some other reason
this won't work for you, I'd suggest doing this:
uri L_URI_CCONTACT /constantcontact\.com\//i
describe L_URI_CCONTAACT has a constant contact URI
score L_URI_CCONTACT 1.0
This has the following advantages:
1) it's easy
2) no mods to SA are required.
3) a local feature doesn't require a global change
4) you can score this one independently, should you so desire.
5) it's efficient, provided you don't have to add more than 50 or so of these.
In general, this is starting to look a lot like bug 5864.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 5905] Remove uridnsbl_skip_domain constantcontact.com
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5905
--- Comment #4 from Justin Mason <jm...@jmason.org> 2008-05-08 09:32:57 PST ---
I should be clearer -- if it's showing up in spam *sent via their hosts*.
obviously if it's being faked in spam, that's just the usual situation.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.