Re: NO_RELAYS spam
On Thu, 17 Jun 2010, Randy Ramsdell wrote: The original email did not hit the NO_RELAYS rule but subsequent runs through do hit this rule and it isn't on all email. Charles Gregory wrote: This sounds to me like you are 'resending' the mail from a local address to your mail server, rather than 'feeding' the original mail back into spamassassin. If this is the case, then you would naturally produce a new set of headers, and there would be no external relays, thus triggering the NO_RELAYS rule On 17.06.10 12:13, Randy Ramsdell wrote: Hmmm, this mail came in and went straight to the users inbox. 1. Postfix --- 2. Amavis ( Spamd/Clamd) --- 3. Postfix --- 4. Dovecot-deliver in this case, this problem belongs more to amavis mailing list, not to spamassassin one. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. 2B|!2B, that's a question!
Re: Please Help with SA Rule: FH_HOST_IN_ADDRARPA
On 6/17/2010 2:19 PM, gwilodailo wrote: I've discovered that some mail between two of my clients (on separate hosts) is getting flagged as spam, because of this rule (FH_HOST_IN_ADDRARPA). I'm not at all an expert with spamassassin, and I'm having some difficulty finding what this rule is about and what to do about it. On 17.06.10 14:47, Lee Dilkie wrote: the rule is flagging the fact that the servers are using non-assigned address space. no, it's flagging that some admin hhad a genial idea to point PTR to itself: 1.1.1.1.in-addr.arpa. PTR 1.1.1.1.in-addr.arpa. A 1.1.1.1 -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Christian Science Programming: Let God Debug It!.
Re: SpamAssassin Integration
Martin Gregorie-2 wrote: How are you assembling the message? About the best you can do is to grab it as a text string when the message is ready to be sent to the mail server. At thius point it should contain the headers your program has added and the assembled MIME format body, The string can then be written to spamc's stdin and its output read from stdout. Run spamc with the -R option: this will cause it to output a formatted report about the message preceeded with a line reading n/m (n=score, m=spam threshhold). If your mail client is written in Java you're probably using JavaMail. In this case the message will probably have been assembled in a MimeMessage object. When that's complete, i.e. just before you call the Transport.send() method to send the message, call MimeMessage.writeTo(OutputStream) and copy everything read from the OutputStream to spamc's stdin as described above. Hi Martin, Your recommended/suggested solution of assembly message exactly meets my use case requirement. Thanks for letting me know the existence of the method MimeMessage.writeTo(OutputStream). That's great! Thanks once again for that valuable solution. Regards, Gnanam -- View this message in context: http://old.nabble.com/SpamAssassin-Integration-tp28903365p28922585.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
difference between checking and processing?
HI, Can someone explain or point me to a documentation about the difference between checking and processing a message? The two methods are available as you can see in the code here: http://www.google.com/codesearch/p?hl=en#HXExPAVrUsQ/pub/OpenBSD/3.9/packages/sparc/p5-Mail-SpamAssassin-3.1.0p0.tgz%7CEw8i3Jlx5iw/bin/spamdq=spamd:%20processing%20messaged=7l=1246 but I haven't found any explanation about those two methods. Thanks Raphaël -- Web database: http://www.myowndb.com Free Software Developers Meeting: http://www.fosdem.org
Re: difference between checking and processing?
Raphael Bauduin wrote: Can someone explain or point me to a documentation about the difference between checking and processing a message? Have a look at http://spamassassin.apache.org/full/3.1.x/doc/Mail_SpamAssassin_Client.html#process I'm not exactly sure what the process call works like but you'll most likely notice the difference in return values of content_length, isspam, score, threshold and message. Daniel -- View this message in context: http://old.nabble.com/difference-between-checking-and-processing--tp28924569p28924705.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Writing Spamassassin plugin.
On Fri, 2010-06-18 at 09:38 +0200, Massimiliano Giovine wrote:
Hi all. I'm writing a simple spamassassin plugin that eval just
subject but it does not.
$self-register_eval_rule (check_header_token);
It's an eval() rule. So you also need to define a SA rule, that calls
the function. Please read the docs carefully. Also, looking at existing
code and basing off of it likely is a good idea...
http://spamassassin.apache.org/full/3.2.x/doc/Mail_SpamAssassin_Plugin.html
sub check_header_token
{
my ($self, $pms) = @_;
$subject = $pms-get('Subject');
if($subject == 'HELLO')
{
#bad message
return 0;
}
return 1;
Your eval() rule claims a hit, if the Subject does *not* match. You
reversed the logic.
What i miss? I put log message on new and on rule and i saw that it
did the new function but if i telnet a mail message with HELLO as a
subject it write it into mailbox.
Anyway, I hope this is just meant as a first attempt, not a real plugin.
It duplicates the existing WhiteListSubject plugin (which also handles
blacklisting subjects).
Moreover, for arbitrary scores, a simple header rule does the same, much
more flexible than a plugin.
header FOO Subject =~ /^bad subject$/
--
char *t=\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: difference between checking and processing?
On Fri, 18 Jun 2010 03:48:21 -0700 (PDT) Daniel Lemke le...@jam-software.com wrote: Raphael Bauduin wrote: Can someone explain or point me to a documentation about the difference between checking and processing a message? Have a look at http://spamassassin.apache.org/full/3.1.x/doc/Mail_SpamAssassin_Client.html#process I'm not exactly sure what the process call works like but you'll most likely notice the difference in return values of content_length, isspam, score, threshold and message. You need to look in spamd. # It might be a CHECK message, meaning that we should just check # if it's spam or not, then return the appropriate response. # If we get the PROCESS command, the client is going to send a # message that we need to filter. i.e. CHECK corresponds to the -c, --check option to spamc, PROCESS allows spamd to modify the email and and send the whole thing back to the client.
Re: Writing Spamassassin plugin.
Thanks for the answer:
I also put 25_myplugin.cf where other plugin's confs are.
I wrote on it:
if loadplugin myplugin
header MY_RULE eval:check_header_token()
endif
but it does not change spamassassin behaviour.
My plugin will be more complex and will do analysis of mail customized
headers. I'm trying to make just an example.
I read that docs thousand times but i never found the answers i need.
I have one more question:
when my eval rule is called?
i suppose this flow:
1) telnet an email with particular header
2) spamassassin(spamd not command line execution) calls my eval rule
3) the rule hitted (return 1) the message is deleted: the mail won't
be writed into /var/mail/mailbox.
Is this idea right?
I read razor2 and sfd plugins code and i do the same into *.pm file.
Probably i miss something else.
2010/6/18 Karsten Bräckelmann guent...@rudersport.de:
On Fri, 2010-06-18 at 09:38 +0200, Massimiliano Giovine wrote:
Hi all. I'm writing a simple spamassassin plugin that eval just
subject but it does not.
$self-register_eval_rule (check_header_token);
It's an eval() rule. So you also need to define a SA rule, that calls
the function. Please read the docs carefully. Also, looking at existing
code and basing off of it likely is a good idea...
http://spamassassin.apache.org/full/3.2.x/doc/Mail_SpamAssassin_Plugin.html
sub check_header_token
{
my ($self, $pms) = @_;
$subject = $pms-get('Subject');
if($subject == 'HELLO')
{
#bad message
return 0;
}
return 1;
Your eval() rule claims a hit, if the Subject does *not* match. You
reversed the logic.
What i miss? I put log message on new and on rule and i saw that it
did the new function but if i telnet a mail message with HELLO as a
subject it write it into mailbox.
Anyway, I hope this is just meant as a first attempt, not a real plugin.
It duplicates the existing WhiteListSubject plugin (which also handles
blacklisting subjects).
Moreover, for arbitrary scores, a simple header rule does the same, much
more flexible than a plugin.
header FOO Subject =~ /^bad subject$/
--
char *t=\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
--
-Massimiliano Giovine
Aksel Peter Jørgensen dice: Why make things difficult, when it is
possible to make them cryptic and totally illogic, with just a little
bit more effort?
Blog: http://opentalking.blogspot.com
Linus Torvalds doesn't die, he simply returns zero.
Re: Writing Spamassassin plugin.
These might be starting to get dated a little but I think that if you look at the Extending Apache SpamAssassin Using Plugin slides and notes from here: http://people.apache.org/~parker/presentations/index.html That will give you a good idea on what you need to accomplish for your plugin. Michael
Re: Writing Spamassassin plugin.
I read also the first part of that slides with the attached notes. I did exacly the same steps except the configuration parsing (i thought i don't need it, was i wrong?) I logged 2 messages 1 in the new funcion and one in eval rule function: It prints all mesages at spamd restart but not when i send messages to postfix via telnet. Can it help for the solution? 2010/6/18 Michael Parker park...@pobox.com: These might be starting to get dated a little but I think that if you look at the Extending Apache SpamAssassin Using Plugin slides and notes from here: http://people.apache.org/~parker/presentations/index.html That will give you a good idea on what you need to accomplish for your plugin. Michael -- -Massimiliano Giovine Aksel Peter Jørgensen dice: Why make things difficult, when it is possible to make them cryptic and totally illogic, with just a little bit more effort? Blog: http://opentalking.blogspot.com Linus Torvalds doesn't die, he simply returns zero.
Re: Writing Spamassassin plugin.
On Fri, 2010-06-18 at 16:38 +0200, Massimiliano Giovine wrote:
Thanks for the answer:
I also put 25_myplugin.cf where other plugin's confs are.
Don't. This will be lost on the next successful sa-update run. Instead,
use your site config dir for the custom cf file.
if loadplugin myplugin
header MY_RULE eval:check_header_token()
endif
That doesn't even lint. The loadplugin command is for actually loading
the plugin, which must be done prior to using it in rules.
The conditional should be ifplugin. Grep the stock rules for example
usage. And btw, the conditional is only necessary, if the plugin might
not be enabled -- if you know you load it, there isn't much need to
guard the rules...
but it does not change spamassassin behaviour.
My plugin will be more complex and will do analysis of mail customized
headers. I'm trying to make just an example.
OK then. However, is the custom header analysis going to be that
complex, that a bunch of header and probably meta rules would not do?
I read that docs thousand times but i never found the answers i need.
I have one more question:
when my eval rule is called?
When the corresponding rule is being evaluated.
Hint: dbg() lines in your plugin can help a lot. Observe your plugin's
behavior by calling spamassassin -D.
i suppose this flow:
1) telnet an email with particular header
2) spamassassin(spamd not command line execution) calls my eval rule
spamd must be restarted. And of course, your cf file must lint
cleanly...
3) the rule hitted (return 1) the message is deleted: the mail won't
be writed into /var/mail/mailbox.
Wrong. SA does NOT deliver mail. SA does NOT prevent delivering mail,
neither delete mail. SA evaluates a score. Any action whatsoever is the
responsibility of other tools in your mail processing chain.
Oh, and since you defined a single eval() rule, the resulting score will
just be changed by the rule's score. Whether the overall score exceeds
the spam threshold or not is another question.
What you just outlined is a single-hit kill-switch. While you /can/ do
that with SA, you will not find it in stock rules. SA is a scoring
system. (And again, performing action based on the kill-switch rule is
outside the scope of SA.)
And since you just mentioned return 1, but didn't get back to all my
comments -- the logic in the OP still is reversed. The rule hits, when
the Subject does not match your criteria.
--
char *t=\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: NO_RELAYS spam
Michelle Konzack wrote: Hello Randy Ramsdell, Am 2010-06-17 10:38:08, hacktest Du folgendes herunter: We are getting a ton of this type and it scores low because there are no received headers. What is this type of mail? I do not recall seeing these in the past. Hehehe... sounds like a new customer of me... His mailserver was accessd through telnet using scripts to generate the spam messages, hence, it had no Received: headers... Thanks, Greetings and nice Day/Evening Michelle Konzack Even so, all email should have a received header. In this case, the emails are sent to a content filter which will add received headers.
Re: NO_RELAYS spam
David B Funk wrote: On Thu, 17 Jun 2010, Randy Ramsdell wrote: get us added to lists, but Michael stated then, check the blacklists to see how to get removed. as if we are already on a list. We are not. Back to the main issue. Here is an example pastbin. http://pastebin.com/mJqRPzkv I found this message in the logs and it comes from yahoo. I don't think I will focus on our forms because general mail also has its received headers stripped. So the question is is what is doing this? I need help to determine how to isolate this problem down. If it is postfix, I will go to there lists etc... I have not implemented any rules that strip received headers nor do I want to. Thanks, RCR Given that it looks like something is taking the original To: header, mutating it into X-Original-To: then adding that bogus To: undisclosed recipients: and adding a X-Virus-Scanned: amavisd-new at activedatatech.net header I would guess that it's your amavisd-new process (or something in its path) that is doing the header damaging. Check the Amavisd site/list for trouble-shooting hints tips. There may be a way to put a 'tee' filter before after amavisd in your postfix confiuration. However, all the emails without the received header field do not show this. It is in this specific pastbin example that you see this. Using sendmail without certain areguments will cause the To: field to show up as undisclosed recipients:.
Re: NO_RELAYS spam
Matus UHLAR - fantomas wrote: On Thu, 17 Jun 2010, Randy Ramsdell wrote: The original email did not hit the NO_RELAYS rule but subsequent runs through do hit this rule and it isn't on all email. Charles Gregory wrote: This sounds to me like you are 'resending' the mail from a local address to your mail server, rather than 'feeding' the original mail back into spamassassin. If this is the case, then you would naturally produce a new set of headers, and there would be no external relays, thus triggering the NO_RELAYS rule On 17.06.10 12:13, Randy Ramsdell wrote: Hmmm, this mail came in and went straight to the users inbox. 1. Postfix --- 2. Amavis ( Spamd/Clamd) --- 3. Postfix --- 4. Dovecot-deliver in this case, this problem belongs more to amavis mailing list, not to spamassassin one. I have no problem going over there but I am not convinced that the Amavis program is the problem. The header field is changed by spamassassin. Doesn't the email simply get handed to Spamassasin by Amavis where the headers are modified by spam report etc...?
Re: Writing Spamassassin plugin.
Well. That sounds more clear.
Now, where is mysite config dir for the custom cf file? I have to
specify one to my spamassassin installation?
Can i assign to my rule a so high score to don let the message delivery?
OK then. However, is the custom header analysis going to be that
complex, that a bunch of header and probably meta rules would not do?
It need a database interaction so i have to use a plugin-eval rule.
When the corresponding rule is being evaluated.
So if i specify HEADER into cf file it will be calle for each
incoming mail header analysis?
Another important information i forgot, i'm on Gnu/Linux - Ubuntu.
2010/6/18 Karsten Bräckelmann guent...@rudersport.de:
On Fri, 2010-06-18 at 16:38 +0200, Massimiliano Giovine wrote:
Thanks for the answer:
I also put 25_myplugin.cf where other plugin's confs are.
Don't. This will be lost on the next successful sa-update run. Instead,
use your site config dir for the custom cf file.
if loadplugin myplugin
header MY_RULE eval:check_header_token()
endif
That doesn't even lint. The loadplugin command is for actually loading
the plugin, which must be done prior to using it in rules.
The conditional should be ifplugin. Grep the stock rules for example
usage. And btw, the conditional is only necessary, if the plugin might
not be enabled -- if you know you load it, there isn't much need to
guard the rules...
but it does not change spamassassin behaviour.
My plugin will be more complex and will do analysis of mail customized
headers. I'm trying to make just an example.
OK then. However, is the custom header analysis going to be that
complex, that a bunch of header and probably meta rules would not do?
I read that docs thousand times but i never found the answers i need.
I have one more question:
when my eval rule is called?
When the corresponding rule is being evaluated.
Hint: dbg() lines in your plugin can help a lot. Observe your plugin's
behavior by calling spamassassin -D.
i suppose this flow:
1) telnet an email with particular header
2) spamassassin(spamd not command line execution) calls my eval rule
spamd must be restarted. And of course, your cf file must lint
cleanly...
3) the rule hitted (return 1) the message is deleted: the mail won't
be writed into /var/mail/mailbox.
Wrong. SA does NOT deliver mail. SA does NOT prevent delivering mail,
neither delete mail. SA evaluates a score. Any action whatsoever is the
responsibility of other tools in your mail processing chain.
Oh, and since you defined a single eval() rule, the resulting score will
just be changed by the rule's score. Whether the overall score exceeds
the spam threshold or not is another question.
What you just outlined is a single-hit kill-switch. While you /can/ do
that with SA, you will not find it in stock rules. SA is a scoring
system. (And again, performing action based on the kill-switch rule is
outside the scope of SA.)
And since you just mentioned return 1, but didn't get back to all my
comments -- the logic in the OP still is reversed. The rule hits, when
the Subject does not match your criteria.
--
char *t=\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
--
-Massimiliano Giovine
Aksel Peter Jørgensen dice: Why make things difficult, when it is
possible to make them cryptic and totally illogic, with just a little
bit more effort?
Blog: http://opentalking.blogspot.com
Linus Torvalds doesn't die, he simply returns zero.
Re: Writing Spamassassin plugin.
On Fri, 2010-06-18 at 17:47 +0200, Massimiliano Giovine wrote:
Well. That sounds more clear.
Now, where is mysite config dir for the custom cf file? I have to
specify one to my spamassassin installation?
man spamassassin
Your site config dir (since you're on Ubuntu) is /etc/spamassassin, the
same location where you find your local.cf.
Can i assign to my rule a so high score to don let the message delivery?
No. *sigh*
As I said in my previous post, SA does NOT deliver your mail, and it
does NOT prevent delivery. SA evaluates mail and returns a score
representing the confidence of the mail's spamminess.
Any action based on that score and/or headers SA adds to the processed
mail is the duty of other programs.
That said -- yes, you /can/ assign a really high score to your custom
rule, that basically will over-rule anything else. However, yet again,
performing the desired action based on the score is NOT within the scope
of SA.
OK then. However, is the custom header analysis going to be that
complex, that a bunch of header and probably meta rules would not do?
It need a database interaction so i have to use a plugin-eval rule.
So the data changes frequently?
When the corresponding rule is being evaluated.
So if i specify HEADER into cf file it will be calle for each
incoming mail header analysis?
Err -- sorry, I don't mean to come across insulting, but...
Did you read the documentation? In particular the Conf docs, rule
definitions. Do you know what a header rule is?
You really should not get your feet wet with SA by writing a plugin. A
solid background, at the very least configuration and tweaking, is
required.
--
char *t=\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: [sa] Re: NO_RELAYS spam
On Fri, 18 Jun 2010, Randy Ramsdell wrote: I have no problem going over there but I am not convinced that the Amavis program is the problem. The header field is changed by spamassassin. Doesn't the email simply get handed to Spamassasin by Amavis where the headers are modified by spam report etc...? The headers are missing. Spamassassin records this fact, but is not responsible for it. So find out what happens to your message BEFORE spamassassin is called. Amavis is just a suggested starting place. And if it is to blame, someone on their list will reocgnize your query as soon as you post it. Suggestion: After each step of your mail processing, if you can, save a copy of the mail to a log file. At least that way you get a quick overview of *which* component removes those headers - C
Re: [sa] Re: NO_RELAYS spam
Charles Gregory wrote: On Fri, 18 Jun 2010, Randy Ramsdell wrote: I have no problem going over there but I am not convinced that the Amavis program is the problem. The header field is changed by spamassassin. Doesn't the email simply get handed to Spamassasin by Amavis where the headers are modified by spam report etc...? The headers are missing. Spamassassin records this fact, but is not responsible for it. So find out what happens to your message BEFORE spamassassin is called. Amavis is just a suggested starting place. And if it is to blame, someone on their list will reocgnize your query as soon as you post it. Suggestion: After each step of your mail processing, if you can, save a copy of the mail to a log file. At least that way you get a quick overview of *which* component removes those headers - C Not exactly. Spamassassin sees the original messages including the received headers, then it modifies those headers with its information. I see these issues when running subsequent tests with spamassasin. So this is why I am not convinced that spamassassin is not causing the problem. Just clarifying the issue here. So it could be amavis, spamassassin or postfix but I am leaning towards spamassassin at the moment. From an earlier post in which I wrote: ( You see that the original scan saw the headers, but after delivery they were gone. ) Example: Original rules hit. X-Spam-Status: No, score=-0.394 tagged_above=- required=5tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619,URG_BIZ=1.585] After running spamassassin -D X-Spam-Status: No, score=4.2 required=5.0 tests=AWL,BAYES_80,HTML_MESSAGE,NO_RECEIVED,NO_RELAYS,TO_MALFORMED,URG_BIZ autolearn=no version=3.2.5
Re: Writing Spamassassin plugin.
To the OP: here are a couple of, hopefully, useful ideas: 1) If all your new plug-in is intended to do is fish a set of patterns out of the database and run them against the subject line, you may want to look at my 'portmanteau' script, which will probably run faster since the patterns don't need to be compiled for each message. It builds a rule from a list of patterns and a few directives that set the rule name, say what part of the message it scans, etc. 2) Take a look at my 'spamkiller' program, which is designed to be placed downstream of spamc and only returns ham to the MTA. I use it to handle inbound mail before it gets to Postfix in a pipeline: getmail - spamc - spamkiller - sendmail - postfix It discards spam by only calling sendmail for ham. I think it can be used in a Postfix service or with other MTAs, but I'm certain somebody will speak up if this isn't the case. It could also be modified to change the delivery address so that the MTA delivers spam to a quarantine mailbox, ready for further processing or analysis. 3) If the spamkiller approach isn't useful, you can use procmail to send spam to /dev/null or use your MUA to do the same thing - most modern MUAs can filter spam on the headers or the [SPAM] prefix that SA adds to the subject line. You can find 'portmanteau' and 'spamkiller' at http://www.libelle-systems.com/free/ Martin
Re: NO_RELAYS spam
On Fri, 2010-06-18 at 13:33 -0400, Randy Ramsdell wrote:
Charles Gregory wrote:
On Fri, 18 Jun 2010, Randy Ramsdell wrote:
I have no problem going over there but I am not convinced that the
Amavis program is the problem. The header field is changed by
spamassassin. Doesn't the email simply get handed to Spamassasin by
Amavis where the headers are modified by spam report etc...?
No. While (I believe) Amavis actually can use spamd, it is most common
not using it. Amavis uses its own instance of SA, *similar* to what
spamd does. Also, in that case, SA doesn't add headers, but Amavis code
does.
Moreover, SA generally does not modify any headers but the Subject if
specifically configured to do so, and there are a very few rarely-used
options for rewriting (two) other headers. None of these ever harms
Received headers.
Suggestion: After each step of your mail processing, if you can, save
a copy of the mail to a log file. At least that way you get a quick
overview of *which* component removes those headers
Not exactly. Spamassassin sees the original messages including the
received headers, then it modifies those headers with its information. I
see these issues when running subsequent tests with spamassasin. So this
is why I am not convinced that spamassassin is not causing the problem.
Just clarifying the issue here. So it could be amavis, spamassassin or
postfix but I am leaning towards spamassassin at the moment.
I don't see how SA could do this, and believe it must be something else.
But hey, that's just an as uneducated guess as yours. And it doesn't get
us closer to the culprit.
From an earlier post in which I wrote: ( You see that the original
scan saw the headers, but after delivery they were gone. )
Original rules hit.
X-Spam-Status: No, score=-0.394 tagged_above=-
required=5tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001,
RCVD_IN_SORBS_WEB=0.619,URG_BIZ=1.585]
Note that this header has been added by Amavis, *not* SA. Despite you
repeating it is SA adding the headers. And your claim of using spamd,
which is rather unlikely when using Amavis.
Are you really using spamd with Amavis?
After running spamassassin -D
X-Spam-Status: No, score=4.2 required=5.0
tests=AWL,BAYES_80,HTML_MESSAGE,NO_RECEIVED,NO_RELAYS,TO_MALFORMED,URG_BIZ
autolearn=no version=3.2.5
So, yeah -- we do know that the Received headers have been present when
the incoming mail initially has been passed to Amavis (and its SA
instance). What we do *not* know is, where exactly after that headers
get lost. Some verbose logging of headers before and after *all*
following stages will be necessary.
Also it is left kind of unclear, how and where you got the mail with the
headers lost for re-feeding to SA. From your description I assume you
got it by directly snipering a raw message file out of the Dovecot
Maildir backend storage. But that's just a guess, unless you can confirm
the exact steps you did that.
Your issue is kind of weird and far less than common. Read, I cannot
recall coming across such a report *ever* on this list.
Thus, the collective list's lack of pin-pointing the cause with the info
given. The very reason we need you to dig deeper, provide debug logs,
header dumps at all stages -- or any evidence at all this might be SA.
guenther
--
char *t=\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
