Re: Duplicate header question

[mouss]

Kevin W. Gagel wrote:
> - Original Message -
> From: mouss <[EMAIL PROTECTED]>
> To: 
> Cc: users@spamassassin.apache.org
> Subject: Re: Duplicate header question
> Date: Tue, 04 Dec 2007 23:47:21 +0100
>
>   
>> Kevin W. Gagel wrote:
>> 
>>> - Original Message -
>>>   
>>>   
 your amavisd-new is configured to reject mail with bad headers. as you
 see, this block legitimate mail.

 note that since your amavisd-new is sending bounces, you are a
 potential backscatter source. do not bounce mail after it was accepted
 by one of your servers. once mail is accepted, either deliver,
 quarantine or discard. discarding is bad, but bouncing is evil.
 
 
>>> Backscatter is not just ANY bounced email. Non-delivery notices are not
>>> bad either.
>>>
>>>   
>>>   
>> backscatter is when you send a bounce to someone who has not sent you
>> mail. so unless you can guarantee (at least, to some extent) that the
>> sender is whom you think, don't bounce: reject at smtp time or do
>> something else.
>> 
>
> I know what backskcatter is, I was mearly pointing out contrary to your
> assertion, backscatter is not ANY bounced email. I agree, if I didn't send,
> I consider backscatter as well.
>
> While this is the preferred method, address verification is not always
> advisable due to the large increase in queries that it can generate. I
> don't worry to much about it myself because my site is not that burdened,
> so I verify always. But - I have found a number of sites that verification
> fails on because the outgoing server does not store the mail or accept mail
> for their site. In those cases it's near impossible to do a quick
> verification. Besides, RFC's require accepting the message...
>
>   
>>> A mail server sending a bounce notice because a message was malformed is
>>> a correct action to take. 
>>>   
>> No:
>> 
>
> Yes! I did say "a correct" not THE correct. It is still A CORRECT action to
> take.
>   

I still disagree, but I won't argue.

>> 1- if you want to do this, then reject the message at SMTP time
>> 2- If you think the message is legitimate, then accept it. smtp is not
>> an educational channel.
>> 
>
> That has nothing to do with anything. If you have the resources to do smtp
> proxy and hold connections open while your scanning the message that is
> your perogative. 

Then don't be picky about malformed headers.

> It is NOT a requirement. It is a prefered way of doing
> things.
>
>   

It's not about requirements, it's about keeping mail usable. Again,
there is no problem if you send few misdirected bounces from to time.
but after a joe job, you'll start sending enormous quantities of
misdirected bounces, and this is bad netiquette, and can't be justified
by RFC conformance (unless you want to put pressure to make smtp obsolete).

after all, open relay was ok some years ago.

>>> Sending a bounce notice because the message was
>>> infected has turned into a bad thing and is now considered backscatter.
>>>   
>>>   
>> I have no problem with bounces to mail I _sent_. I have problems with
>> bounces to mail I _never_ sent. and there is no difference between
>> backscatter in the following cases:
>> - recipients are not validated at smtp time
>> - a filter thinks a message is infected or is spam
>> - a filter thinks the message is malformed
>> 
>
> I agree, but the RFC's still say we should be sending out notices...
>   

The RFC spirit is to avoid discarding mail. The RFC doesn't say to
bounce mail because of malformed headers.

Anyway, no RFC mandates accepting mail from outscatters.
>   
>> bounces from mailing lists and because of disk quota or system problems
>> is still acceptable, mostly because t doesn't happen to often.
>> 
>
> That depends on who your talking to. I've seen radical applications of
> rejections because of an automated, ANY, automated message.
>
> The key for any good admin is to balance out the RFC's and what works best
> for their company. While the RFC's are meant to keep all things working
> well together, if we all follow them to the letter many sites would not
> work because of minor errors on the part of their admins. (but then again,
> that might not be a bad idea either!).
>   

Re: Duplicate header question

[Mark Martinec]

On Tuesday 04 December 2007 17:05:04 Johnson, S wrote:
> 554 5.6.0 Reject, is=26786-18 - Bad_Header: Duplicate header field:
>   "Message-ID"
>
> This nondelivery report was generated by the program amavisd-new at host
> mail.maildomain.com. Our internal reference code for your message is
> 26786-18/vvPdH275wGUz

> Can anyone tell me what could be going on here?

1. the message received by amavisd had two or more instances of a
   Message-ID header field, and this is in violation with RFC 2822;
   Whether this is a cause for a bounce/rejection/notification is
   a matter of policy. If it was one of your own domain's MUAs which
   produced such mail it should be fixed or replaced.

2. amavisd was configured to reject or bounce a message with a
   bad header. This is not a default setting, and there is usually
   no good reason to reject such messages. If a message is coming
   from inside, consider sending the sender a notification.
   I'd suggest to keep $final_bad_header_destiny at a default
   setting of D_PASS.

Mark

Re: Duplicate header question

[Kevin W. Gagel]

- Original Message -
From: mouss <[EMAIL PROTECTED]>
To: 
Cc: users@spamassassin.apache.org
Subject: Re: Duplicate header question
Date: Tue, 04 Dec 2007 23:47:21 +0100

>Kevin W. Gagel wrote:
>> - Original Message -
>>   
>>> your amavisd-new is configured to reject mail with bad headers. as you
>>> see, this block legitimate mail.
>>>
>>> note that since your amavisd-new is sending bounces, you are a
>>> potential backscatter source. do not bounce mail after it was accepted
>>> by one of your servers. once mail is accepted, either deliver,
>>> quarantine or discard. discarding is bad, but bouncing is evil.
>>> 
>>
>> Backscatter is not just ANY bounced email. Non-delivery notices are not
>> bad either.
>>
>>   
>
>backscatter is when you send a bounce to someone who has not sent you
>mail. so unless you can guarantee (at least, to some extent) that the
>sender is whom you think, don't bounce: reject at smtp time or do
>something else.

I know what backskcatter is, I was mearly pointing out contrary to your
assertion, backscatter is not ANY bounced email. I agree, if I didn't send,
I consider backscatter as well.

While this is the preferred method, address verification is not always
advisable due to the large increase in queries that it can generate. I
don't worry to much about it myself because my site is not that burdened,
so I verify always. But - I have found a number of sites that verification
fails on because the outgoing server does not store the mail or accept mail
for their site. In those cases it's near impossible to do a quick
verification. Besides, RFC's require accepting the message...

>> A mail server sending a bounce notice because a message was malformed is
>> a correct action to take. 
>
>No:

Yes! I did say "a correct" not THE correct. It is still A CORRECT action to
take.
>1- if you want to do this, then reject the message at SMTP time
>2- If you think the message is legitimate, then accept it. smtp is not
>an educational channel.

That has nothing to do with anything. If you have the resources to do smtp
proxy and hold connections open while your scanning the message that is
your perogative. It is NOT a requirement. It is a prefered way of doing
things.

>> Sending a bounce notice because the message was
>> infected has turned into a bad thing and is now considered backscatter.
>>   
>
>I have no problem with bounces to mail I _sent_. I have problems with
>bounces to mail I _never_ sent. and there is no difference between
>backscatter in the following cases:
>- recipients are not validated at smtp time
>- a filter thinks a message is infected or is spam
>- a filter thinks the message is malformed

I agree, but the RFC's still say we should be sending out notices...

>bounces from mailing lists and because of disk quota or system problems
>is still acceptable, mostly because t doesn't happen to often.

That depends on who your talking to. I've seen radical applications of
rejections because of an automated, ANY, automated message.

The key for any good admin is to balance out the RFC's and what works best
for their company. While the RFC's are meant to keep all things working
well together, if we all follow them to the letter many sites would not
work because of minor errors on the part of their admins. (but then again,
that might not be a bad idea either!).


=
Kevin W. Gagel
Network Administrator
Information Technology Services
(250) 562-2131 local 5448
My Blog:
http://mail.cnc.bc.ca/blogs/gagel
My File share:
http://mail.cnc.bc.ca/users/gagel

---
The College of New Caledonia, Visit us at http://www.cnc.bc.ca
Virus scanning is done on all incoming and outgoing email.
Anti-spam information for CNC can be found at http://avas.cnc.bc.ca
---

Re: Duplicate header question

[mouss]

Kevin W. Gagel wrote:
> - Original Message -
>   
>> your amavisd-new is configured to reject mail with bad headers. as you
>> see, this block legitimate mail.
>>
>> note that since your amavisd-new is sending bounces, you are a potential
>> backscatter source. do not bounce mail after it was accepted by one of
>> your servers. once mail is accepted, either deliver, quarantine or
>> discard. discarding is bad, but bouncing is evil.
>> 
>
> Backscatter is not just ANY bounced email. Non-delivery notices are not bad
> either.
>
>   

backscatter is when you send a bounce to someone who has not sent you
mail. so unless you can guarantee (at least, to some extent) that the
sender is whom you think, don't bounce: reject at smtp time or do
something else.

> A mail server sending a bounce notice because a message was malformed is a
> correct action to take. 

No:
1- if you want to do this, then reject the message at SMTP time
2- If you think the message is legitimate, then accept it. smtp is not
an educational channel.

> Sending a bounce notice because the message was
> infected has turned into a bad thing and is now considered backscatter.
>   

I have no problem with bounces to mail I _sent_. I have problems with
bounces to mail I _never_ sent. and there is no difference between
backscatter in the following cases:
- recipients are not validated at smtp time
- a filter thinks a message is infected or is spam
- a filter thinks the message is malformed


bounces from mailing lists and because of disk quota or system problems
is still acceptable, mostly because t doesn't happen to often.

Re: spamassassin 3.2.0 default setup detects legitimate email as spam

[mouss]

[EMAIL PROTECTED] wrote:
> Hi gurus,
>
> Recently, I've upgraded to spamassassin 3.2.0 called from amavisd-new.
> I've seen that this version is more agressive, and for example it
> detect as spam
> a legitimate email with next score:
>
> X-Spam-Status: Yes, score=4.884 tagged_above=-999 required=3.5
>tests=[MIME_BASE64_TEXT=2.796, RCVD_BAD_ID=2.088]
>

SA doesn't think this is spam (score < 5). _you_ decided it is spam.
Rule score are computed using the threshold of 5. Using another
threshold may work, but don't forget that the optimization problem that
the perceptron solves is not linear.

if a lot of spam is missed, don't lower the threshold. Instead, find out
if you can add rules to detect that spam.
> Is this correct?
>
> I know that, perhaps, email was'nt sent correctly, but what can i do?
>
> - increase required score until 6 or 7 for example?
> - avoid these tests: MIME_BASE64_TEXT, RCVD_BAD_ID or
> score with  lower punctuation

depends on how many legitimate mail you get that trigger these.
> - other solutions,
>

use Bayes and train on errors.

Re: Duplicate header question

[Kevin W. Gagel]

- Original Message -
>your amavisd-new is configured to reject mail with bad headers. as you
>see, this block legitimate mail.
>
>note that since your amavisd-new is sending bounces, you are a potential
>backscatter source. do not bounce mail after it was accepted by one of
>your servers. once mail is accepted, either deliver, quarantine or
>discard. discarding is bad, but bouncing is evil.

Backscatter is not just ANY bounced email. Non-delivery notices are not bad
either.

A mail server sending a bounce notice because a message was malformed is a
correct action to take. Sending a bounce notice because the message was
infected has turned into a bad thing and is now considered backscatter.

=
Kevin W. Gagel
Network Administrator
Information Technology Services
(250) 562-2131 local 5448
My Blog:
http://mail.cnc.bc.ca/blogs/gagel
My File share:
http://mail.cnc.bc.ca/users/gagel

---
The College of New Caledonia, Visit us at http://www.cnc.bc.ca
Virus scanning is done on all incoming and outgoing email.
Anti-spam information for CNC can be found at http://avas.cnc.bc.ca
---

Re: Duplicate header question

[mouss]

Johnson, S wrote:
> I just upgraded my Spamassassin/postfix/amavisd/sqlgrey to the current
> version and now have a few users from MSN and Yahoo reporting an error
> similar to this:
>
>  
>
> 554 5.6.0 Reject, is=26786-18 - Bad_Header: Duplicate header field:
> "Message-ID"
>
> This nondelivery report was generated by the program amavisd-new at host
> mail.maildomain.com. Our internal reference code for your message is
> 26786-18/vvPdH275wGUz
>
> Return-Path: [EMAIL PROTECTED]
>
> Message-ID: [EMAIL PROTECTED]
>
> User-Agent: Microsoft-Entourage/11.3.6.070618 
>
> Subject: Presentations
>
> Duplicate Header Field
>
>  
>
>  
>
> Can anyone tell me what could be going on here?
>
>  

your amavisd-new is configured to reject mail with bad headers. as you
see, this block legitimate mail.

note that since your amavisd-new is sending bounces, you are a potential
backscatter source. do not bounce mail after it was accepted by one of
your servers. once mail is accepted, either deliver, quarantine or
discard. discarding is bad, but bouncing is evil.

Re: spamassassin 3.2.0 default setup detects legitimate email as spam

[Richard Frovarp]

[EMAIL PROTECTED] wrote:

Hi gurus,

Recently, I've upgraded to spamassassin 3.2.0 called from amavisd-new.
I've seen that this version is more agressive, and for example it 
detect as spam

a legitimate email with next score:

X-Spam-Status: Yes, score=4.884 tagged_above=-999 required=3.5
   tests=[MIME_BASE64_TEXT=2.796, RCVD_BAD_ID=2.088]

Is this correct?

I know that, perhaps, email was'nt sent correctly, but what can i do?

- increase required score until 6 or 7 for example?
- avoid these tests: MIME_BASE64_TEXT, RCVD_BAD_ID or
score with  lower punctuation
- other solutions,

Jordi Renye
Universitat Politecnica de Catalunya



The score that SA 3.2 is tuned for is 5.0. So given that score, the 
message wouldn't have been caught, but definitely close. 3.5 is probably 
too low.

spamassassin 3.2.0 default setup detects legitimate email as spam

[jordir]

Hi gurus,

Recently, I've upgraded to spamassassin 3.2.0 called from amavisd-new.
I've seen that this version is more agressive, and for example it detect 
as spam

a legitimate email with next score:

X-Spam-Status: Yes, score=4.884 tagged_above=-999 required=3.5
   tests=[MIME_BASE64_TEXT=2.796, RCVD_BAD_ID=2.088]

Is this correct?

I know that, perhaps, email was'nt sent correctly, but what can i do?

- increase required score until 6 or 7 for example?
- avoid these tests: MIME_BASE64_TEXT, RCVD_BAD_ID or
score with  lower punctuation
- other solutions,

Jordi Renye
Universitat Politecnica de Catalunya

Re: Duplicate header question

[Evan Platt]

At 08:05 AM 12/4/2007, Johnson, S wrote:
I just upgraded my 
Spamassassin/postfix/amavisd/sqlgrey to the 
current version and now have a few users from 
MSN and Yahoo reporting an error similar to this:


554 5.6.0 Reject, is=26786-18 – Bad_Header: 
Duplicate header field: “Message-ID”
This nondelivery report was generated by the 
program amavisd-new at host mail.maildomain.com. 
Our internal reference code for your message is 26786-18/vvPdH275wGUz

Return-Path: [EMAIL PROTECTED]
Message-ID: 
[EMAIL PROTECTED]

User-Agent: Microsoft-Entourage/11.3.6.070618
Subject: Presentations
Duplicate Header Field


Can anyone tell me what could be going on here?


That message was generated by amavisd, so you'd 
probably have more luck asking in a group for them if no one here can help.

Duplicate header question

[Johnson, S]

I just upgraded my Spamassassin/postfix/amavisd/sqlgrey to the current
version and now have a few users from MSN and Yahoo reporting an error
similar to this:

 

554 5.6.0 Reject, is=26786-18 - Bad_Header: Duplicate header field:
"Message-ID"

This nondelivery report was generated by the program amavisd-new at host
mail.maildomain.com. Our internal reference code for your message is
26786-18/vvPdH275wGUz

Return-Path: [EMAIL PROTECTED]

Message-ID: [EMAIL PROTECTED]

User-Agent: Microsoft-Entourage/11.3.6.070618 

Subject: Presentations

Duplicate Header Field

 

 

Can anyone tell me what could be going on here?

 

 Thanks much.

sa-update error, again!

[Juergen . Boehm]

Okay thx for the help with my sa-update problem yesterday.
now i am a step further and get the next error .-)
Here is the Dump, error is at the end

[1722] dbg: logger: adding facilities: all
[1722] dbg: logger: logging level is DBG
[1722] dbg: generic: SpamAssassin version 3.2.3
[1722] dbg: config: score set 0 chosen.
[1722] dbg: dns: no ipv6
[1722] dbg: dns: is Net::DNS::Resolver available? yes
[1722] dbg: dns: Net::DNS version: 0.61
[1722] dbg: generic: sa-update version svn540384
[1722] dbg: generic: using update directory: 
/var/lib/spamassassin/3.002003
[1722] dbg: diag: perl platform: 5.006001 linux
[1722] dbg: diag: module installed: Digest::SHA1, version 2.11
[1722] dbg: diag: module installed: HTML::Parser, version 3.56
[1722] dbg: diag: module installed: Net::DNS, version 0.61
[1722] dbg: diag: module installed: MIME::Base64, version 3.07
[1722] dbg: diag: module installed: DB_File, version 1.75
[1722] dbg: diag: module installed: Net::SMTP, version 2.31
[1722] dbg: diag: module installed: Mail::SPF, version v2.005
[1722] dbg: diag: module installed: Mail::SPF::Query, version 1.999001
[1722] dbg: diag: module installed: IP::Country::Fast, version 604.001
[1722] dbg: diag: module not installed: Razor2::Client::Agent ('require' 
failed)
[1722] dbg: diag: module not installed: Net::Ident ('require' failed)
[1722] dbg: diag: module installed: IO::Socket::INET6, version (undef)
[1722] dbg: diag: module not installed: IO::Socket::SSL ('require' failed)
[1722] dbg: diag: module installed: Compress::Zlib, version 1.16
[1722] dbg: diag: module installed: Time::HiRes, version 1.9708
[1722] dbg: diag: module installed: Mail::DomainKeys, version 1.0
[1722] dbg: diag: module installed: Mail::DKIM, version 0.29
[1722] dbg: diag: module installed: DBI, version 1.601
[1722] dbg: diag: module installed: Getopt::Long, version 2.37
[1722] dbg: diag: module installed: LWP::UserAgent, version 2.036
[1722] dbg: diag: module installed: HTTP::Date, version 1.47
[1722] dbg: diag: module installed: Archive::Tar, version 1.36
[1722] dbg: diag: module installed: IO::Zlib, version 1.08
[1722] dbg: diag: module not installed: Encode::Detect ('require' failed)
[1722] dbg: gpg: reading in gpgfile /etc/mail/spamassassin/keys
[1722] dbg: gpg: adding key id 856AA88A
[1722] dbg: gpg: adding key id 5244EC45
[1722] dbg: gpg: Searching for 'gpg'
[1722] dbg: util: current PATH is: 
/usr/sbin:/bin:/usr/bin:/sbin:/usr/X11R6/bin
[1722] dbg: util: executable for gpg was found at /usr/bin/gpg
[1722] dbg: gpg: found /usr/bin/gpg
[1722] dbg: gpg: release trusted key id list: 
5E541DC959CB8BAC7C78DFDC4056A61A5244EC45 5244EC45 
0C2B1D7175B852C64B3CDC716C55397824F434CE 856AA88A 
26C900A46DD40CD5AD24F6D7DEE01987265FA05B
[1722] dbg: channel: reading in channelfile 
/etc/mail/spamassassin/sare-sa-update-channels.txt
[1722] dbg: channel: adding updates.spamassassin.org
[1722] dbg: channel: adding 70_sare_stocks.cf.sare.sa-update.dostech.net
[1722] dbg: channel: adding 70_sare_adult.cf.sare.sa-update.dostech.net
[1722] dbg: channel: adding 70_sare_spoof.cf.sare.sa-update.dostech.net
[1722] dbg: channel: adding 
70_sare_bayes_poison_nxm.cf.sare.sa-update.dostech.net
[1722] dbg: channel: adding 
70_sare_genlsubj_x30.cf.sare.sa-update.dostech.net
[1722] dbg: channel: adding 70_sare_oem.cf.sare.sa-update.dostech.net
[1722] dbg: channel: adding 70_sare_random.cf.sare.sa-update.dostech.net
[1722] dbg: channel: adding 70_sare_specific.cf.sare.sa-update.dostech.net
[1722] dbg: channel: adding 70_zmi_german.cf.zmi.sa-update.dostech.net
[1722] dbg: channel: adding 
88_fvgt_bayes_poison.cf.sare.sa-update.dostech.net
[1722] dbg: channel: adding 88_fvgt_tripwire.cf.sare.sa-update.dostech.net
[1722] dbg: channel: adding 88_fvgt_rawbody.cf.sare.sa-update.dostech.net
[1722] dbg: channel: adding 88_fvgt_subject.cf.sare.sa-update.dostech.net
[1722] dbg: channel: adding chickenpox.cf.sare.sa-update.dostech.net
[1722] dbg: channel: attempting channel updates.spamassassin.org
[1722] dbg: channel: update directory 
/var/lib/spamassassin/3.002003/updates_spamassassin_org
[1722] dbg: channel: channel cf file 
/var/lib/spamassassin/3.002003/updates_spamassassin_org.cf
[1722] dbg: channel: channel pre file 
/var/lib/spamassassin/3.002003/updates_spamassassin_org.pre
[1722] dbg: channel: metadata version = 590061
[1722] dbg: dns: 3.2.3.updates.spamassassin.org => 590061, parsed as 
590061
[1722] dbg: channel: current version is 590061, new version is 590061, 
skipping channel
[1722] dbg: channel: attempting channel 
70_sare_stocks.cf.sare.sa-update.dostech.net
[1722] dbg: channel: update directory 
/var/lib/spamassassin/3.002003/70_sare_stocks_cf_sare_sa-update_dostech_net
[1722] dbg: channel: channel cf file 
/var/lib/spamassassin/3.002003/70_sare_stocks_cf_sare_sa-update_dostech_net.cf
[1722] dbg: channel: channel pre file 
/var/lib/spamassassin/3.002003/70_sare_stocks_cf_sare_sa-update_dostech_net.pre
[1722] dbg: dns: 3.2.3.70_sare_stocks.cf.sare.sa-update.dostech.net 

Re: sa-update error

[Philipp Snizek]

Hi

> Thx so far. Yes thats it. Its our DNS on the Router. In all other cases it
> works fine but it don't like 3.2.3.updates.spamassassin.org.
> Can i somehow tell sa-update to use another (global) DNS Server?

Yes, you can. The first choice probably would be the DNS servers of your ISP.
However, you could also run a DNS cache server on your antispam box or on
some other linux/unix/windows based machine. This would give you a
performance advantage.

Philipp

> PS.: I've got the newest version of the updates because i manually built
> the directories and copied the files from my private machine .-)
>
>
>
>
> Jürgen Böhm <[EMAIL PROTECTED]>
> 04.12.2007 06:26
>
> An
> [EMAIL PROTECTED]
> Kopie
>
> Thema
> [Fwd: Re: sa-update error]
>
>
>
>
>
>
>
>
>
> - Nachricht von "Daryl C. W. O'Shea" <[EMAIL PROTECTED]> auf
> Mon, 03 Dec 2007 11:14:32 -0500 -
> An:
> [EMAIL PROTECTED]
> Kopie:
> users@spamassassin.apache.org
> Thema:
> Re: sa-update error
>
> [EMAIL PROTECTED] wrote:
>
>> i get following error when i run sa-update.
>> uery failed: 3.2.3.updates.spamassassin.org => answer section incomplete
>> can anybody help me with this?
>> here is the whole dump from sa-update:
>
> I'm getting the proper response from all five of our name servers.
>
> Try the query manually to see if you can spot a problem.
>
> dig txt 3.2.3.updates.spamassassin.org
>
> Be sure to run the query against the first name server listed in your
> /etc/resolv.conf file since it's the only one that will be uses (maybe
> it's down or having problems).
>
>> [31625] dbg: channel: metadata version = 590061
>
> Note that 590061 is the current version so you had to have successfully
> updated the channel in the past.
>
> Daryl
>
>
>
>
> - Nachricht von "Daryl C. W. O'Shea" <[EMAIL PROTECTED]> auf
> Mon, 03 Dec 2007 11:14:32 -0500 -
> An:
> [EMAIL PROTECTED]
> Kopie:
> users@spamassassin.apache.org
> Thema:
> Re: sa-update error
>
> [EMAIL PROTECTED] wrote:
>
>> i get following error when i run sa-update.
>> uery failed: 3.2.3.updates.spamassassin.org => answer section incomplete
>> can anybody help me with this?
>> here is the whole dump from sa-update:
>
> I'm getting the proper response from all five of our name servers.
>
> Try the query manually to see if you can spot a problem.
>
> dig txt 3.2.3.updates.spamassassin.org
>
> Be sure to run the query against the first name server listed in your
> /etc/resolv.conf file since it's the only one that will be uses (maybe
> it's down or having problems).
>
>> [31625] dbg: channel: metadata version = 590061
>
> Note that 590061 is the current version so you had to have successfully
> updated the channel in the past.
>
> Daryl
>
>
>
>

Re: Testing with My Yahoo Account Spams

[Matthias Haegele]

mozafar rowshan schrieb:

Hi friends!
 
 I've installed SpamAssassin 3.2.3 in CentOS 5, now for testing

 purposes. I've checked SA (spamc/d) and It works for package spam and non-spam
 sample files.
 
 As far as I remember, I did not play with SA settings, so the

 configuration is default.
 
 Anyway, I tested SA with some spam mails from my Yahoo account Bulk

 folder and It did not identify them as spam.


You should not forward mail to SA for spamchecking, try to use SA with 
your actual accounts not any other accounts, spam is individual.


 I like to know that what are reasons for this...?? 
 For example, I think with myself that the loss of some headers like

 Received: headers in my Yahoo spams is such a reason (I should mention
 that my Yahoo spam mails have only four headers: Date:, From:, To: and
 Subject: ) or training is needed. 


For Training you need at least 200 ham/spam messages (messages from 
which sa-learn could learn, so if there are no new "tokens" to learn you 
need probably more messages), iirc.


Headers are essential for SA ...


 Very thanks.



http://wiki.apache.org/spamassassin/FrequentlyAskedQuestions
http://wiki.apache.org/spamassassin/SpamAssassin
http://wiki.apache.org/spamassassin/TestingInstallation

hth
--
Grüsse/Greetings
MH


Dont send mail to: [EMAIL PROTECTED]
--

Re: Why not score mails without __ENV_AND_HDR_FROM_MATCH

[Justin Mason]

ram writes:
> Almost all of the phising mails I can see have 
> (!__ENV_AND_HDR_FROM_MATCH)
> 
> Can I simple give a high score to all mails whose header from and env
> from dont match 
> 
> I will have to whitelist all mailing lists , yahoogroups etc. But is
> there any other issue with this 

it's *extremely* common in nonspam -- appears in 26% of our test
corpora in fact.  That's a *lot* of whitelisting.

http://ruleqa.spamassassin.org/?q=__ENV_AND_HDR_FROM_MATCH

--j.

Re: sa-update error

[Juergen . Boehm]

Thx so far. Yes thats it. Its our DNS on the Router. In all other cases it 
works fine but it don't like 3.2.3.updates.spamassassin.org.
Can i somehow tell sa-update to use another (global) DNS Server?
PS.: I've got the newest version of the updates because i manually built 
the directories and copied the files from my private machine .-)




Jürgen Böhm <[EMAIL PROTECTED]> 
04.12.2007 06:26

An
[EMAIL PROTECTED]
Kopie

Thema
[Fwd: Re: sa-update error]









- Nachricht von "Daryl C. W. O'Shea" <[EMAIL PROTECTED]> auf 
Mon, 03 Dec 2007 11:14:32 -0500 -
An:
[EMAIL PROTECTED]
Kopie:
users@spamassassin.apache.org
Thema:
Re: sa-update error

[EMAIL PROTECTED] wrote:

> i get following error when i run sa-update.
> uery failed: 3.2.3.updates.spamassassin.org => answer section incomplete
> can anybody help me with this?
> here is the whole dump from sa-update:

I'm getting the proper response from all five of our name servers.

Try the query manually to see if you can spot a problem.

dig txt 3.2.3.updates.spamassassin.org

Be sure to run the query against the first name server listed in your 
/etc/resolv.conf file since it's the only one that will be uses (maybe 
it's down or having problems).

> [31625] dbg: channel: metadata version = 590061

Note that 590061 is the current version so you had to have successfully 
updated the channel in the past.

Daryl




- Nachricht von "Daryl C. W. O'Shea" <[EMAIL PROTECTED]> auf 
Mon, 03 Dec 2007 11:14:32 -0500 -
An:
[EMAIL PROTECTED]
Kopie:
users@spamassassin.apache.org
Thema:
Re: sa-update error

[EMAIL PROTECTED] wrote:

> i get following error when i run sa-update.
> uery failed: 3.2.3.updates.spamassassin.org => answer section incomplete
> can anybody help me with this?
> here is the whole dump from sa-update:

I'm getting the proper response from all five of our name servers.

Try the query manually to see if you can spot a problem.

dig txt 3.2.3.updates.spamassassin.org

Be sure to run the query against the first name server listed in your 
/etc/resolv.conf file since it's the only one that will be uses (maybe 
it's down or having problems).

> [31625] dbg: channel: metadata version = 590061

Note that 590061 is the current version so you had to have successfully 
updated the channel in the past.

Daryl