You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Dave Pooser <da...@pooserville.com> on 2014/04/13 21:22:22 UTC
RCVD_IN_IADB_VOUCHED pushed spam into false negatives
And looking at the IADB web page, what I see is them bragging about how
little checking they do. What I don't see on their Web site is any way to
report spam to them.
I've gone ahead and set all IADB scores to 0 locally, but I'm curious if
this strikes anybody else as a questionable default for stock SA?
--
Dave Pooser
Cat-Herder-in-Chief, Pooserville.com
"...Life is not a journey to the grave with the intention of arriving
safely in one pretty and well-preserved piece, but to slide across the
finish line broadside, thoroughly used up, worn out, leaking oil, and
shouting GERONIMO!!!" -- Bill McKenna
Re: RCVD_IN_IADB_VOUCHED pushed spam into false negatives
Posted by RW <rw...@googlemail.com>.
On Sun, 13 Apr 2014 14:22:22 -0500
Dave Pooser wrote:
> And looking at the IADB web page, what I see is them bragging about
> how little checking they do. What I don't see on their Web site is
> any way to report spam to them.
Under "Contact" it says:
"To report abuse or spam from one of our SuretyMail Accredited
senders: abuse@suretymail.com"
> I've gone ahead and set all IADB scores to 0 locally, but I'm curious
> if this strikes anybody else as a questionable default for stock SA?
Personally I find that it works well. RCVD_IN_IADB_VOUCHED hits about 1%
of my ham and no spam at all in the last 30,000 or so.
Re: RCVD_IN_IADB_VOUCHED pushed spam into false negatives
Posted by Axb <ax...@gmail.com>.
On 04/13/2014 09:22 PM, Dave Pooser wrote:
> And looking at the IADB web page, what I see is them bragging about how
> little checking they do. What I don't see on their Web site is any way to
> report spam to them.
>
>
> I've gone ahead and set all IADB scores to 0 locally, but I'm curious if
> this strikes anybody else as a questionable default for stock SA?
imo, all the "certification" service are questionable but we have a choice..
you set score to 0 which stops the scoring but queries still happen in
the background
# IADB support ...
header __RCVD_IN_IADB eval:check_rbl('iadb-firsttrusted',
'iadb.isipp.com.')
tflags __RCVD_IN_IADB net nice
header RCVD_IN_IADB_VOUCHED eval:check_rbl_sub('iadb-firsttrusted',
'127.0.1.255')
describe RCVD_IN_IADB_VOUCHED ISIPP IADB lists as vouched-for sender
tflags RCVD_IN_IADB_VOUCHED net nice
In SA 3.4 I use:
dns_query_restriction deny isipp.com
then no query is sent and the score makes no difference .-)
Re: RCVD_IN_IADB_VOUCHED pushed spam into false negatives
Posted by Greg Troxel <gd...@ir.bbn.com>.
Dave Warren <da...@hireahit.com> writes:
> I just thought I'd mention the rules since it seemed to be outside
> them, but if it's grandfathered in, that's not unfair.
I disagreed about grandfathering. The purpose of the policy is to
decide what's ok. Just because something was added earlier doesn't mean
it should stay, if it doesn't meet the current norms.
Re: RCVD_IN_IADB_VOUCHED pushed spam into false negatives
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 4/14/2014 7:34 PM, Dave Warren wrote:
> On 2014-04-13 12:22, Dave Pooser wrote:
>> And looking at the IADB web page, what I see is them bragging about how
>> little checking they do. What I don't see on their Web site is any
>> way to
>> report spam to them.
>>
>> I've gone ahead and set all IADB scores to 0 locally, but I'm curious if
>> this strikes anybody else as a questionable default for stock SA?
>
> Are we talking about http://www.isipp.com/iadb.php or something else?
>
> Based on
> https://wiki.apache.org/spamassassin/DnsBlocklistsInclusionPolicy I'm
> not sure that they qualify anyway, specifically:
>
> "Must not have intent to profit, including optional or required
> payments, in order to remove, add, expedite or otherwise
> non-objectively handle entries to their lists."
>
> http://www.isipp.com/suretymail-faq.php#pricing indicates that pricing
> starts at $10.00 per month, and I cannot find any way to add or remove
> an IP without paying a fee. Am I misreading the rules, or are they out
> of compliance to be included at all?
No, I think you are reading it correctly. It was added prior to the
policy. If it has a lot of problems, we would have to consider
disabling it by default.
Regards,
KAM
Re: RCVD_IN_IADB_VOUCHED pushed spam into false negatives
Posted by Dave Warren <da...@hireahit.com>.
On 2014-04-13 12:22, Dave Pooser wrote:
> And looking at the IADB web page, what I see is them bragging about how
> little checking they do. What I don't see on their Web site is any way to
> report spam to them.
>
> I've gone ahead and set all IADB scores to 0 locally, but I'm curious if
> this strikes anybody else as a questionable default for stock SA?
Are we talking about http://www.isipp.com/iadb.php or something else?
Based on
https://wiki.apache.org/spamassassin/DnsBlocklistsInclusionPolicy I'm
not sure that they qualify anyway, specifically:
"Must not have intent to profit, including optional or required
payments, in order to remove, add, expedite or otherwise non-objectively
handle entries to their lists."
http://www.isipp.com/suretymail-faq.php#pricing indicates that pricing
starts at $10.00 per month, and I cannot find any way to add or remove
an IP without paying a fee. Am I misreading the rules, or are they out
of compliance to be included at all?
--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren
Re: RCVD_IN_IADB_VOUCHED pushed spam into false negatives
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 4/16/2014 12:50 PM, Axb wrote:
> On 04/16/2014 06:43 PM, Greg Troxel wrote:
>> If the whitelist company doesn't want to make a wiki page and be
>> transparent and responsive, SA users shouldn't have that whitelist
>> imposed on them.
>
> nothing is imposed on SA users. They have a choice to disable whatever
> they don't like (or have it done for them)
Additionally, rules are a separate installation. You can choose not to
use them.
Re: RCVD_IN_IADB_VOUCHED pushed spam into false negatives
Posted by Axb <ax...@gmail.com>.
On 04/16/2014 06:43 PM, Greg Troxel wrote:
> If the whitelist company doesn't want to make a wiki page and be
> transparent and responsive, SA users shouldn't have that whitelist
> imposed on them.
nothing is imposed on SA users. They have a choice to disable whatever
they don't like (or have it done for them)
Re: RCVD_IN_IADB_VOUCHED pushed spam into false negatives
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 4/16/2014 12:43 PM, Greg Troxel wrote:
> So I'm not sure what you mean about volunteers; I view this as a basic
> policy problem rather than a needs-implementation problem. Once policy
> is declared, almost all the work is on the part of paid whitelist
> operators to do things they should have been doing anyway. Greg
I welcome your input to edit the policy and find ways to implement it
fairly, etc. But I think you discount the amount of work this requires
and volunteers are needed for policy as well. If you want to help do
this, that would be good but I think you are asking for a review of all
DNSBLs and a modification of a policy that was previously voted on by
the PMC so changes would need to be vetted.
I also don't know that I would vote for this policy change. I would
likely enforce the existing policy that pay-for-play whitelists do not
qualify for default enabling.
Please open a bugzilla for the issue and in the meantime, disable the
rules through scoring to 0 on your installation.
regards,
KAM
Abuse contacts (was Re: RCVD_IN_IADB_VOUCHED pushed spam into false
negatives)
Posted by Kris Deugau <kd...@vianet.ca>.
John Hardin wrote:
> On Wed, 16 Apr 2014, Matthias Leisi wrote:
>> abuse@<easily identifiable, stable and unique domain> should be
>> available.
>> Wiki and docs are fine, but should not be needed if possible.
>
> Oh my god, yes! Sites who force you to go through a web page rather than
> having a working abuse@ address are saying "we really don't want you to
> report abuse to us."
And by "working", this includes "don't reject .eml attachments out of
hand" and "don't reject mail as spam".
Because a lot of mail reported to an abuse contact will be....
variously spammy and/or malicious.
As for processing a message forwarded as an attachment, if *I* can
scrape together enough pieces in the right order to automatically detach
RFC822-attached email messages from a parent, and extract relay IP and
other bits and pieces from the attached message(s), surely a major ESP
or hosting provider can hire someone who can do better than I can...
> i.e. their abuse@ mailbox. :)
Oh, no we can't have *that*. Email support-contact@, or helpdesk@, or
take the message apart yourself and paste things in these 15 fields, or
paste the message into the body of a new message, but omit this bit and
that bit and these other 47,326 bits that will get your report rejected
as spam or "potentially malicious content" (well, yes, it was, that's
why I'm reporting it!).
-kgd
Re: RCVD_IN_IADB_VOUCHED pushed spam into false negatives
Posted by Matthias Leisi <ma...@leisi.net>.
On Wed, Apr 16, 2014 at 8:58 PM, John Hardin <jh...@impsec.org> wrote:
abuse@<easily identifiable, stable and unique domain> should be available.
>> Wiki and docs are fine, but should not be needed if possible.
>>
>
> Oh my god, yes! Sites who force you to go through a web page rather than
> having a working abuse@ address are saying "we really don't want you to
> report abuse to us."
Yes, and no. The quality of abuse@ mails varies widely. Feedback through a
structured form on a website can drastically improve the quality and make
such feedback actionable. But yes, abuse@ should still be available.
-- Matthias
Re: RCVD_IN_IADB_VOUCHED pushed spam into false negatives
Posted by John Hardin <jh...@impsec.org>.
On Wed, 16 Apr 2014, Matthias Leisi wrote:
> (FTR & transparency, speaking for dnswl.org - a whitelist without
> paid-for-listing model, but with a pay-for-heavy-use model)
>
> On Wed, Apr 16, 2014 at 6:43 PM, Greg Troxel <gd...@ir.bbn.com> wrote:
>> b) meet the following transparency and responsiveness rules
>> i) Have a page on the SA wiki which points to the way to
>> complain.
>
> abuse@<easily identifiable, stable and unique domain> should be available.
> Wiki and docs are fine, but should not be needed if possible.
Oh my god, yes! Sites who force you to go through a web page rather than
having a working abuse@ address are saying "we really don't want you to
report abuse to us."
>> ii) On the main web page of the whitelist, have a prominent link
>> about how to file a complaint about receiving spam from
>> whitelisted entities. This must be sufficiently prominent that
>> the number of people who fail to find it is essentially zero,
>
> ACK.
i.e. their abuse@ mailbox. :)
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Ten-millimeter explosive-tip caseless, standard light armor
piercing rounds. Why?
-----------------------------------------------------------------------
3 days until the 239th anniversary of The Shot Heard 'Round The World
Re: RCVD_IN_IADB_VOUCHED pushed spam into false negatives
Posted by Matthias Leisi <ma...@leisi.net>.
(FTR & transparency, speaking for dnswl.org - a whitelist without
paid-for-listing model, but with a pay-for-heavy-use model)
On Wed, Apr 16, 2014 at 6:43 PM, Greg Troxel <gd...@ir.bbn.com> wrote:
> b) meet the following transparency and responsiveness rules
> i) Have a page on the SA wiki which points to the way to
> complain.
>
abuse@<easily identifiable, stable and unique domain> should be available.
Wiki and docs are fine, but should not be needed if possible.
> ii) On the main web page of the whitelist, have a prominent link
> about how to file a complaint about receiving spam from
> whitelisted entities. This must be sufficiently prominent that
> the number of people who fail to find it is essentially zero,
>
ACK.
> and it should have equal or greater billing than material aimed
> at senders.
>
I don't think that this should be required. A policy should try to define
the what, not so much the how.
> iii) Complaints received should get a response with an incident
> number (or equivalent) within a business day.
>
For the case of dnswl.org, feedback via email gets into a request tracker,
but without auto-acknowledge (for obvious reasons).
> iv) Complaints should be dealt with within a week by either
> delisting the offending entity or addressing the issue so that
>
The action may depend on the merits of the abuse report and other
circumstances. At dnswl.org, we have a number of responses (add a "watch
flag", cross-check between emailed abuse reports and automated feedback
loops, start lowering the score, deactivate some or all entries of a given
record etc).
The response (eg, "watch" towards full deletion) should be proportionate to
the complaint.
Keeping any SLAs is difficult for volunteer-driven projects. While I agree
that action should be taken on relatively short notice (measured in "days",
ideally even below one day), hard SLAs may not always be possible to meet,
or may be delayed due to additional checks being performed.
> no spam recurs. (For the purposes of this guideline, invitations
> sent by a site to an address which was taken from an uploaded
> address book or equivalent are considered to be spam.)
>
I don't think that a policy should special-case invite-spam.
-- Matthias
Re: RCVD_IN_IADB_VOUCHED pushed spam into false negatives
Posted by Greg Troxel <gd...@ir.bbn.com>.
"Kevin A. McGrail" <KM...@PCCC.com> writes:
> We do have a policy for this:
> http://wiki.apache.org/spamassassin/DnsBlocklistsInclusionPolicy
Sorry for the delay. For some reason firefox will not load that page,
but will load other wiki pages; I gave up after a bit and fetched it a
different way.
So relative to what I was trying to say, that policy isn't good enough.
I think it's pretty easy to fix. The core issue is that running a
whitelist where people on the whitelist pay the whitelist provider is an
enormous conflict of interest. Mitigating that conflict of interest is
necessary, and is the duty of ASF as a public charity.
For normal rules, positive or negative points are helpful more than they
hurt, and there are some errors. That's fine, and unavoidable. For
pay-to-play whitelists, the situation is more complicated, as whitelist
operators can essentially sell negative points, and the only real
pressure is to kick them out of the default ruleset. So we get into
game theory rather than the normal probability.
To fix this, I'd add to the policy:
* Whitelists must either
a) be widely known or documented to not accept any compensation,
direct or indirect, from listed entities, so that they are clearly
free from a conflict of interest, or
b) meet the following transparency and responsiveness rules
i) Have a page on the SA wiki which points to the way to
complain.
ii) On the main web page of the whitelist, have a prominent link
about how to file a complaint about receiving spam from
whitelisted entities. This must be sufficiently prominent that
the number of people who fail to find it is essentially zero,
and it should have equal or greater billing than material aimed
at senders.
iii) Complaints received should get a response with an incident
number (or equivalent) within a business day.
iv) Complaints should be dealt with within a week by either
delisting the offending entity or addressing the issue so that
no spam recurs. (For the purposes of this guideline, invitations
sent by a site to an address which was taken from an uploaded
address book or equivalent are considered to be spam.)
I'm explicitly separating pay-to-play whitelist and others; the
requirements are only on the paid whitelists. The requirements aren't
onerous; they are basic steps any paid whitelist should be doing anyway.
If the whitelist company doesn't want to make a wiki page and be
transparent and responsive, SA users shouldn't have that whitelist
imposed on them.
So I'm not sure what you mean about volunteers; I view this as a basic
policy problem rather than a needs-implementation problem. Once policy
is declared, almost all the work is on the part of paid whitelist
operators to do things they should have been doing anyway.
Greg
Re: RCVD_IN_IADB_VOUCHED pushed spam into false negatives
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 4/14/2014 12:23 PM, Greg Troxel wrote:
> Dave Pooser <da...@pooserville.com> writes:
>
>> And looking at the IADB web page, what I see is them bragging about how
>> little checking they do. What I don't see on their Web site is any way to
>> report spam to them.
> I suggest filing a bugreport against spamassassin, complaining that it
> has a negative-points rule without a transparent process for reporting
> false negatives (and further, that leads to effective action). I have
> long complained that SA should have a transparency and responsiveness
> policy for all whitelists, including the whitelist's top-level page
> having prominent instructions for how to complain, and a track record
> of correcting issues.
>
We do have a policy for this:
http://wiki.apache.org/spamassassin/DnsBlocklistsInclusionPolicy
Beyond that, good ideas. Need volunteers to implement what you asked.
regards,
KAM
Re: RCVD_IN_IADB_VOUCHED pushed spam into false negatives
Posted by Greg Troxel <gd...@ir.bbn.com>.
Dave Pooser <da...@pooserville.com> writes:
> And looking at the IADB web page, what I see is them bragging about how
> little checking they do. What I don't see on their Web site is any way to
> report spam to them.
I suggest filing a bugreport against spamassassin, complaining that it
has a negative-points rule without a transparent process for reporting
false negatives (and further, that leads to effective action). I have
long complained that SA should have a transparency and responsiveness
policy for all whitelists, including the whitelist's top-level page
having prominent instructions for how to complain, and a track record
of correcting issues.