Re: GEO IP Truble after upgrade to 3.4.1

[Kevin A. McGrail]

You can likely just disable Geo::IP anyway.  See 
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=6824


On 3/2/2018 1:06 AM, Maurizio Caloro wrote:


Hello together

I have little Geo::IP Trouble

Yesterday i have upgraded Spamassassin to 3.4.1 on debian_version 8.10 
3.16.51-3+deb8u1


If  i start me service this GeiIP Plugin have some error messages

Mar 02 06:44:15 Servername spamd[22306]: plugin: failed to parse 
plugin (from @INC): Can't locate object method "lib_version" via 
package "Geo::IP" at 
/usr/local/share/perl/5.20.2/Mail/SpamAssassin/Plugin/URILocalBL.pm 
line 117.


Mar 02 06:44:15 Servername spamd[22306]: Compilation failed in require 
at (eval 102) line 1.


But me version of Geo ::IP are updated

cpan[1]> install Geo::IP

Reading '/root/.cpan/Metadata'

  Database was generated on Thu, 01 Mar 2018 22:55:21 GMT

Geo::IP is up to date (1.51).

URILocalBL.pm Line 117

But witch Version of GeoIP Library i have running on me machines ?

# need GeoIP C library 1.6.3 and GeoIP perl API 1.4.4 or later to 
avoid messages leaking - Bug 7153


my $gic_wanted = version->parse('v1.6.3');

my $gic_have = version->parse(Geo::IP->lib_version());

my $gip_wanted = version->parse('v1.4.4');

my $gip_have = version->parse($Geo::IP::VERSION);

Thanks for any possible help !

Regards

Mauri

GEO IP Truble after upgrade to 3.4.1

[Maurizio Caloro]

Hello together

 

I have little Geo::IP Trouble

Yesterday i have upgraded Spamassassin to 3.4.1 on debian_version 8.10
3.16.51-3+deb8u1

 

If  i start me service this GeiIP Plugin have some error messages

Mar 02 06:44:15 Servername spamd[22306]: plugin: failed to parse plugin
(from @INC): Can't locate object method "lib_version" via package "Geo::IP"
at /usr/local/share/perl/5.20.2/Mail/SpamAssassin/Plugin/URILocalBL.pm line
117.

Mar 02 06:44:15 Servername spamd[22306]: Compilation failed in require at
(eval 102) line 1.

 

But me version of Geo ::IP are updated

 

cpan[1]> install Geo::IP

Reading '/root/.cpan/Metadata'

  Database was generated on Thu, 01 Mar 2018 22:55:21 GMT

Geo::IP is up to date (1.51).

 

 

URILocalBL.pm Line 117

But witch Version of GeoIP Library i have running on me machines ?

 

# need GeoIP C library 1.6.3 and GeoIP perl API 1.4.4 or later to avoid
messages leaking - Bug 7153

my $gic_wanted = version->parse('v1.6.3');

my $gic_have = version->parse(Geo::IP->lib_version());

my $gip_wanted = version->parse('v1.4.4');

my $gip_have = version->parse($Geo::IP::VERSION);

 

 

Thanks for any possible help !

Regards

Mauri

 

 

 

 

Re: Can't Get Removed From List

[Miles Fidelman]

On 3/1/18 3:58 PM, Luis E. Muñoz wrote:


On 1 Mar 2018, at 11:54, Miles Fidelman wrote:
[...] and sometimes turn on VERP to narrow things down to an 
individual. It's all made so much worse by morons who confuse the 
"spam" button with their "delete" key when using webmail from a big 
provider. Sigh...)


Out of curiosity, why turn off VERP? Having it on all the time makes 
it much easier to deal with bounces.



Yes, but when you have lots of users on AOL & hotmail, you lose the 
opportunity to batch deliver - and that just burns cycles.


Miles

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Re: Can't Get Removed From List

[David B Funk]

On Thu, 1 Mar 2018, John Hardin wrote:

A bunch of Javascript to display a *single image*? And it doesn't display 
*any content at all* if javascript is disabled for that site?


That's what I hate about the web these days, there's too much crap 
surrounding the useful content.


 "too much -vulnerable- crap" ...

it's one thing if the javascript is coming from the base site, but these days 
it often is coming from  a bunch of cloud based aggregation servers that could 
be full of who-knows-what.


Can you say AWS Bucket-brigade?

--
Dave Funk  University of Iowa
College of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{

Re: Can't Get Removed From List

[Luis E. Muñoz]

On 1 Mar 2018, at 11:54, Miles Fidelman wrote:
[...] and sometimes turn on VERP to narrow things down to an 
individual. It's all made so much worse by morons who confuse the 
"spam" button with their "delete" key when using webmail from a big 
provider. Sigh...)


Out of curiosity, why turn off VERP? Having it on all the time makes it 
much easier to deal with bounces.


Best regards

-lem

Re: Can't Get Removed From List

[John Hardin]

On Thu, 1 Mar 2018, Charles Sprickman wrote:


(OT)

I used to be much more angry at the “send to spam” clickers on AOL webmail, but 
if you look at the UI, it’s really AOL’s fault.  It’s terrible, and you can 
make it better by changing some default settings in their webmail, but most 
people aren’t going to do that.

See this screenshot, and tell me you might not click the “do not enter” icon 
instead of the “trash can” icon…

https://www.odrive.com/s/g/05672068-18d9-40b9-bc24-8c561bc70ef4-59e5936b


A bunch of Javascript to display a *single image*? And it doesn't display 
*any content at all* if javascript is disabled for that site?


That's what I hate about the web these days, there's too much crap 
surrounding the useful content.


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  Teach a man to fish, and he'll eat for life.
  Give him someone else's fish, and he'll vote for you.
---
 12 days until Albert Einstein's 139th Birthday

Re: Can't Get Removed From List

[Miles Fidelman]

On 3/1/18 3:02 PM, Charles Sprickman wrote:



On Mar 1, 2018, at 2:54 PM, Miles Fidelman 
mailto:mfidel...@meetinghouse.net>> wrote:


On 3/1/18 2:45 PM, David Jones wrote:


On 03/01/2018 01:01 PM, Kevin Viner wrote:



The following text is not SA "advice" nor report.

You should start by consulting who / what gave that text in 
response to

get details.


Thank you. I did, and they said that they can't give me any more
information. As I explained to them, I'm a professional entertainer 
with a
mailing list of 10,000+. I'm not receiving abuse reports, and 
everything is
opt-in. So if they are marking me as spam because of a couple 
complaints
they are receiving, that doesn't seem fair. Not really sure where 
to go from

here.



If Mailchimp won't help you, maybe it's time to try Contact Contact, 
EMMA or another mass emailing service that will.




Yes.  Indeed.  Your vendor should be able to check their mail logs 
and identify which email addresses are being rejected - so that you 
can then remove them from your list.


(I run a bunch of opt-in email lists off of our own server - Sympa 
for anyone who's interested - and every once in a while I have to 
track down complaints, remove people, and get our IP address of 
various blacklists.  A real pain.  Even more of a pain from sites 
that provide anonymized bounce reports - one has to then track down 
the recipient by checking message id's against the outbound mail, and 
sometimes turn on VERP to narrow things down to an individual. It's 
all made so much worse by morons who confuse the "spam" button with 
their "delete" key when using webmail from a big provider. Sigh…)


(OT)

I used to be much more angry at the “send to spam” clickers on AOL 
webmail, but if you look at the UI, it’s really AOL’s fault.  It’s 
terrible, and you can make it better by changing some default settings 
in their webmail, but most people aren’t going to do that.


See this screenshot, and tell me you might not click the “do not 
enter” icon instead of the “trash can” icon…


https://www.odrive.com/s/g/05672068-18d9-40b9-bc24-8c561bc70ef4-59e5936b


True.  Also on Thunderbird (unless you modify your toolbar).  Still, I 
have folks who will not read mail for a week, and just mark everything 
that's accumulated as spam.  A real PITA.


Sigh...

Miles




--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Re: Can't Get Removed From List

[Charles Sprickman]

> On Mar 1, 2018, at 2:54 PM, Miles Fidelman  wrote:
> 
> On 3/1/18 2:45 PM, David Jones wrote:
> 
>> On 03/01/2018 01:01 PM, Kevin Viner wrote:
>>> 
 The following text is not SA "advice" nor report.
 
 You should start by consulting who / what gave that text in response to
 get details.
>>> 
>>> Thank you. I did, and they said that they can't give me any more
>>> information. As I explained to them, I'm a professional entertainer with a
>>> mailing list of 10,000+. I'm not receiving abuse reports, and everything is
>>> opt-in. So if they are marking me as spam because of a couple complaints
>>> they are receiving, that doesn't seem fair. Not really sure where to go from
>>> here.
>>> 
>> 
>> If Mailchimp won't help you, maybe it's time to try Contact Contact, EMMA or 
>> another mass emailing service that will.
>> 
> 
> Yes.  Indeed.  Your vendor should be able to check their mail logs and 
> identify which email addresses are being rejected - so that you can then 
> remove them from your list.
> 
> (I run a bunch of opt-in email lists off of our own server - Sympa for anyone 
> who's interested - and every once in a while I have to track down complaints, 
> remove people, and get our IP address of various blacklists.  A real pain.  
> Even more of a pain from sites that provide anonymized bounce reports - one 
> has to then track down the recipient by checking message id's against the 
> outbound mail, and sometimes turn on VERP to narrow things down to an 
> individual. It's all made so much worse by morons who confuse the "spam" 
> button with their "delete" key when using webmail from a big provider. Sigh…)

(OT)

I used to be much more angry at the “send to spam” clickers on AOL webmail, but 
if you look at the UI, it’s really AOL’s fault.  It’s terrible, and you can 
make it better by changing some default settings in their webmail, but most 
people aren’t going to do that.

See this screenshot, and tell me you might not click the “do not enter” icon 
instead of the “trash can” icon…

https://www.odrive.com/s/g/05672068-18d9-40b9-bc24-8c561bc70ef4-59e5936b 


Charles


> 
> Miles Fidelman
> 
> 
> -- 
> In theory, there is no difference between theory and practice.
> In practice, there is.   Yogi Berra

Re: Can't Get Removed From List

[Miles Fidelman]

On 3/1/18 2:45 PM, David Jones wrote:


On 03/01/2018 01:01 PM, Kevin Viner wrote:



The following text is not SA "advice" nor report.

You should start by consulting who / what gave that text in response to
get details.


Thank you. I did, and they said that they can't give me any more
information. As I explained to them, I'm a professional entertainer 
with a
mailing list of 10,000+. I'm not receiving abuse reports, and 
everything is

opt-in. So if they are marking me as spam because of a couple complaints
they are receiving, that doesn't seem fair. Not really sure where to 
go from

here.



If Mailchimp won't help you, maybe it's time to try Contact Contact, 
EMMA or another mass emailing service that will.




Yes.  Indeed.  Your vendor should be able to check their mail logs and 
identify which email addresses are being rejected - so that you can then 
remove them from your list.


(I run a bunch of opt-in email lists off of our own server - Sympa for 
anyone who's interested - and every once in a while I have to track down 
complaints, remove people, and get our IP address of various 
blacklists.  A real pain.  Even more of a pain from sites that provide 
anonymized bounce reports - one has to then track down the recipient by 
checking message id's against the outbound mail, and sometimes turn on 
VERP to narrow things down to an individual. It's all made so much worse 
by morons who confuse the "spam" button with their "delete" key when 
using webmail from a big provider. Sigh...)


Miles Fidelman


--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Re: IADB whitelist - again

[Luis E. Muñoz]

On 1 Mar 2018, at 10:29, Sebastian Arcus wrote:

I know I have brought up this issue on this list before, and sorry for 
the persistence, but having 7 different rules adding scores for the 
IADB whitelist still seems either ridiculous, or outright suspect:


(Disclaimer, I have inner visibility into IADB and its processes)

I'm sorry, but it only seems "ridiculous" if you don't know how IADB 
works. Hopefully the details below will be helpful to assuage your 
worries.



-0.2 RCVD_IN_IADB_RDNS  RBL: IADB: Sender has reverse DNS record
 [199.127.240.84 listed in iadb.isipp.com]
-0.1 RCVD_IN_IADB_SPF   RBL: IADB: Sender publishes SPF record
-0.1 RCVD_IN_IADB_OPTIN RBL: IADB: All mailing list mail is opt-in
-0.0 RCVD_IN_IADB_SENDERID  RBL: IADB: Sender publishes Sender ID 
record

-0.0 RCVD_IN_IADB_LISTEDRBL: Participates in the IADB system
-0.1 RCVD_IN_IADB_DKRBL: IADB: Sender publishes Domain Keys 
record
-0.1 RCVD_IN_IADB_VOUCHED   RBL: ISIPP IADB lists as vouched-for 
sender


It really raises some very uncomfortable questions regarding the 
impartiality of SA and/or its anti-spam capabilities.


IADB provides a number of "signals" associated with the (vetted) 
practices of senders participating in its certification program. The 
purpose of the DNS data is to allow receivers to use those signals to 
augment their local anti-spam systems or to tweak the rules that are 
applied for filtering.


Claiming that IADB is an "anti-spam" resource is inaccurate, as this is 
not its intended purpose.


Rather, IADB allows for more precise filtering. Something that is also 
indirectly achieved, is that complaints sent to IADB's administration 
are escalated, researched and tracked until resolution, which can (and 
has!) include termination of the accreditation in the IADB.


And by the way, this message is definitely unsolicited, and in now way 
we gave any sort of permission or consent to this company or its 
"affiliates" to email us - so the whole "All mailing list mail is 
opt-in" is nonsense.


Then by all means, include ab...@isipp.com in your complaint -- They'll 
follow up with their customer and if applicable revoke their IADB 
membership. This is no different from an ESP sending to an "imported" 
email address. A complaint would be more helpful than this posting, as 
it would provide for more data to track the actual campaign that caused 
the issue, again, much like in the case of an ESP.


From memory, I haven't seen a single complaint against the organization 
199.127.240.84 is accredited under in more than two years.


And why have "Sender has reverse DNS record" and "Sender publishes SPF 
record" as separate IADB rules - when SA itself already checks for 
these? Isn't this just a glaring way of pumping up SA scores for the 
IADB subscribers?


In this case the IADB is confirming that at the time of their customer's 
accreditation, he claimed that his IP address should always have a valid 
rDNS and be covered by a valid SPF record. I happen to know of receivers 
that use lack of SPF/rDNS + these IADB records to bounce email.


As I'm sure it was mentioned before, the default scores are (or try to 
be) a balance useful for general cases. I've been running with defaults 
for these particular rules for years with no ill effect.


Best regards

-lem

Re: IADB whitelist - again

[David Jones]

On 03/01/2018 12:29 PM, Sebastian Arcus wrote:
I know I have brought up this issue on this list before, and sorry for 
the persistence, but having 7 different rules adding scores for the IADB 
whitelist still seems either ridiculous, or outright suspect:


-0.2 RCVD_IN_IADB_RDNS  RBL: IADB: Sender has reverse DNS record
  [199.127.240.84 listed in iadb.isipp.com]
-0.1 RCVD_IN_IADB_SPF   RBL: IADB: Sender publishes SPF record
-0.1 RCVD_IN_IADB_OPTIN RBL: IADB: All mailing list mail is opt-in
-0.0 RCVD_IN_IADB_SENDERID  RBL: IADB: Sender publishes Sender ID record
-0.0 RCVD_IN_IADB_LISTED    RBL: Participates in the IADB system
-0.1 RCVD_IN_IADB_DK    RBL: IADB: Sender publishes Domain Keys record
-0.1 RCVD_IN_IADB_VOUCHED   RBL: ISIPP IADB lists as vouched-for sender


It really raises some very uncomfortable questions regarding the 
impartiality of SA and/or its anti-spam capabilities. And by the way, 
this message is definitely unsolicited, and in now way we gave any sort 
of permission or consent to this company or its "affiliates" to email us 
- so the whole "All mailing list mail is opt-in" is nonsense.


And why have "Sender has reverse DNS record" and "Sender publishes SPF 
record" as separate IADB rules - when SA itself already checks for 
these? Isn't this just a glaring way of pumping up SA scores for the 
IADB subscribers?


Once in a while, even the best senders can get a bad customer of theirs 
that obtained email addresses by a violation of their terms and conditions.


Just block that sender with a local "blacklist_from *@example.com" entry 
and report it to SpamCop.  If the message headers have any abuse 
reporting information then send the headers there too.  They should do 
their own internal investigation and shutdown that bad customer of theirs.


--
David Jones

Re: IADB whitelist - again

[Anne P. Mitchell Esq.]

 
> 
> On Thu, 1 Mar 2018, Sebastian Arcus wrote:
> 
>> I know I have brought up this issue on this list before, and sorry for the 
>> persistence, but having 7 different rules adding scores for the IADB 
>> whitelist still seems either ridiculous, or outright suspect:
>> 
>> -0.2 RCVD_IN_IADB_RDNS  RBL: IADB: Sender has reverse DNS record
>>[199.127.240.84 listed in iadb.isipp.com]
>> -0.1 RCVD_IN_IADB_SPF   RBL: IADB: Sender publishes SPF record
>> -0.1 RCVD_IN_IADB_OPTIN RBL: IADB: All mailing list mail is opt-in
>> -0.0 RCVD_IN_IADB_SENDERID  RBL: IADB: Sender publishes Sender ID record
>> -0.0 RCVD_IN_IADB_LISTEDRBL: Participates in the IADB system
>> -0.1 RCVD_IN_IADB_DKRBL: IADB: Sender publishes Domain Keys record
>> -0.1 RCVD_IN_IADB_VOUCHED   RBL: ISIPP IADB lists as vouched-for sender
>> 
>> 
>> It really raises some very uncomfortable questions regarding the 
>> impartiality of SA and/or its anti-spam capabilities. And by the way, this 
>> message is definitely unsolicited, and in now way we gave any sort of 
>> permission or consent to this company or its "affiliates" to email us - so 
>> the whole "All mailing list mail is opt-in" is nonsense.
>> 
>> And why have "Sender has reverse DNS record" and "Sender publishes SPF 
>> record" as separate IADB rules - when SA itself already checks for these? 
>> Isn't this just a glaring way of pumping up SA scores for the IADB 
>> subscribers?
> 
> Don't assume malice right off the bat. More likely it is that IADB provides 
> all those status codes and SA exposes a rule for each, with minimal scores, 
> to allow local tuning if desired.
> 
> Also, there is RCVD_IN_IADB_DOPTIN, so RCVD_IN_IADB_OPTIN may be "someone 
> somehow gave us your name somewhere" (i.e. "single opt-in") rather than "we 
> confirmed you actually want to receive our garbage" ("double opt-in").
> 
> The scores appear hardcoded (50_scores.cf) vs. from masscheck (72_scores.cf) 
> so they may be *very* stale.

The IADB codes were designed in conjunction with Craig Hughes, who at the time 
was very involved with SA, for the specific purpose of allowing SA, and other 
systems like SA, to take advantage of the very granular nature of the codes 
for, as John observes, local (and very fine) tuning.   It is not up to us to 
tell receivers what email they should and should not choose to deliver - it is 
up to us to give receivers as much *useful* information as possible.Some 
receivers actually want to deliver single opt-in mail so long as they can 
confirm enough other data points about the email and the sender themselves.

In fact, many of our data response codes were developed at the request of 
receivers such as SA, Spamcop, and others.

One of the reasons that we receive the scores that we do is because we are a 
trusted source of data (for which we are very proud)  - because I came out of 
MAPS (I was their in-house counsel), and any email person in our org comes from 
the anti-spam side as well - we all view our first responsibility as being to 
the receivers who use our data, not the senders who are certified with us.  
Too, folks in the receiving industries know that we take abuse reports (we 
don't receive many, but of course we do receive some) *very* seriously, and 
have no problem firing a sender if they stray to the dark - or heck, even gray 
or slightly soiled white - side. (It helps that we have no contract, and no 
sender pays us very much, so it's very easy to fire them and there is no 
financial incentive to keep any particular sender on. ;-) ) 

We make sure that our senders are - and stay - white hat.  We are unique in 
that way, and that was the promise when we worked with SA in the beginning, and 
we have kept that promise.

Anyone applying for certification with us has to pass a stringent, exhaustive 
background check in terms of their mailing practices, their email reputation, 
etc..

Relatedly, and somewhat humourously, if you look at our codes, they include 
codes such as:

127.3.100.2 Accepts unverified sign-ups such as through web page
127.3.100.3 Accepts unverified sign-ups, gives chance to opt out

Of *course* we would *never* certify anyone to whom those codes would apply, 
but *they* don't know that - those codes are there as 'trick questions', if you 
will.  Anyone applying for certification who checks those boxes doesn't even 
get in the door, let alone through our background check.

P.S.  You will probably have noted in my .sig that I authored part of CAN-SPAM. 
 While CAN-SPAM is essentially a joke for the most part, I'm actually very 
proud of the work I did on Section 6* - it's one of the few aspects of CAN-SPAM 
with teeth - it's the vendor liability section, which actually means the "you 
don't get to run an affiliate program and look the other way while you profit 
from your affiliates spamming - we're looking at you Gevalia" section." (*For 
those of you who are also law/policy wonks, te

Re: Can't Get Removed From List

[David Jones]

On 03/01/2018 01:01 PM, Kevin Viner wrote:



The following text is not SA "advice" nor report.

You should start by consulting who / what gave that text in response to
get details.


Thank you. I did, and they said that they can't give me any more
information. As I explained to them, I'm a professional entertainer with a
mailing list of 10,000+. I'm not receiving abuse reports, and everything is
opt-in. So if they are marking me as spam because of a couple complaints
they are receiving, that doesn't seem fair. Not really sure where to go from
here.



If Mailchimp won't help you, maybe it's time to try Contact Contact, 
EMMA or another mass emailing service that will.


--
David Jones

Re: IADB whitelist - again

[John Hardin]

On Thu, 1 Mar 2018, Sebastian Arcus wrote:

I know I have brought up this issue on this list before, and sorry for the 
persistence, but having 7 different rules adding scores for the IADB 
whitelist still seems either ridiculous, or outright suspect:


-0.2 RCVD_IN_IADB_RDNS  RBL: IADB: Sender has reverse DNS record
[199.127.240.84 listed in iadb.isipp.com]
-0.1 RCVD_IN_IADB_SPF   RBL: IADB: Sender publishes SPF record
-0.1 RCVD_IN_IADB_OPTIN RBL: IADB: All mailing list mail is opt-in
-0.0 RCVD_IN_IADB_SENDERID  RBL: IADB: Sender publishes Sender ID record
-0.0 RCVD_IN_IADB_LISTEDRBL: Participates in the IADB system
-0.1 RCVD_IN_IADB_DKRBL: IADB: Sender publishes Domain Keys record
-0.1 RCVD_IN_IADB_VOUCHED   RBL: ISIPP IADB lists as vouched-for sender


It really raises some very uncomfortable questions regarding the impartiality 
of SA and/or its anti-spam capabilities. And by the way, this message is 
definitely unsolicited, and in now way we gave any sort of permission or 
consent to this company or its "affiliates" to email us - so the whole "All 
mailing list mail is opt-in" is nonsense.


And why have "Sender has reverse DNS record" and "Sender publishes SPF 
record" as separate IADB rules - when SA itself already checks for these? 
Isn't this just a glaring way of pumping up SA scores for the IADB 
subscribers?


Don't assume malice right off the bat. More likely it is that IADB 
provides all those status codes and SA exposes a rule for each, with 
minimal scores, to allow local tuning if desired.


Also, there is RCVD_IN_IADB_DOPTIN, so RCVD_IN_IADB_OPTIN may be "someone 
somehow gave us your name somewhere" (i.e. "single opt-in") rather than 
"we confirmed you actually want to receive our garbage" ("double opt-in").


The scores appear hardcoded (50_scores.cf) vs. from masscheck 
(72_scores.cf) so they may be *very* stale.



--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  ...to announce there must be no criticism of the President or to
  stand by the President right or wrong is not only unpatriotic and
  servile, but is morally treasonous to the American public.
  -- Theodore Roosevelt, 1918
---
 12 days until Albert Einstein's 139th Birthday

Re: Can't Get Removed From List

[Kevin Viner]

> The following text is not SA "advice" nor report.
> 
> You should start by consulting who / what gave that text in response to
> get details.

Thank you. I did, and they said that they can't give me any more
information. As I explained to them, I'm a professional entertainer with a
mailing list of 10,000+. I'm not receiving abuse reports, and everything is
opt-in. So if they are marking me as spam because of a couple complaints
they are receiving, that doesn't seem fair. Not really sure where to go from
here.



--
Sent from: http://spamassassin.1065346.n5.nabble.com/SpamAssassin-Users-f3.html

IADB whitelist - again

[Sebastian Arcus]

I know I have brought up this issue on this list before, and sorry for 
the persistence, but having 7 different rules adding scores for the IADB 
whitelist still seems either ridiculous, or outright suspect:


-0.2 RCVD_IN_IADB_RDNS  RBL: IADB: Sender has reverse DNS record
 [199.127.240.84 listed in iadb.isipp.com]
-0.1 RCVD_IN_IADB_SPF   RBL: IADB: Sender publishes SPF record
-0.1 RCVD_IN_IADB_OPTIN RBL: IADB: All mailing list mail is opt-in
-0.0 RCVD_IN_IADB_SENDERID  RBL: IADB: Sender publishes Sender ID record
-0.0 RCVD_IN_IADB_LISTEDRBL: Participates in the IADB system
-0.1 RCVD_IN_IADB_DKRBL: IADB: Sender publishes Domain Keys record
-0.1 RCVD_IN_IADB_VOUCHED   RBL: ISIPP IADB lists as vouched-for sender


It really raises some very uncomfortable questions regarding the 
impartiality of SA and/or its anti-spam capabilities. And by the way, 
this message is definitely unsolicited, and in now way we gave any sort 
of permission or consent to this company or its "affiliates" to email us 
- so the whole "All mailing list mail is opt-in" is nonsense.


And why have "Sender has reverse DNS record" and "Sender publishes SPF 
record" as separate IADB rules - when SA itself already checks for 
these? Isn't this just a glaring way of pumping up SA scores for the 
IADB subscribers?

Re: how to grep multiline add-header X-Spam lines

[Bill Cole]

On 28 Feb 2018, at 16:13 (-0500), RW wrote:


On Wed, 28 Feb 2018 21:01:36 +0100
Benny Pedersen wrote:


how do one make multiline grep of add-header line, this is imho
triggy since it on long lines continue on next line with a first char
space, if one could help me solve it i be thankfull


If you want to use grep, you can pipe the files through an awk
one-liner to unfold the headers.


That works, but it is probably more convenient (if one has the procmail 
package installed or can install it easily and doesn't have awk syntax 
in the wetware) to use formmail -cs



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole