Re: NO_RELAYS spam
Karsten Bräckelmann wrote: On Fri, 2010-06-18 at 23:54 +0200, Karsten Bräckelmann wrote: 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. Randy, any results? Did you find the cause for the issue? At this time, I have not. Since the messages are originally scanned with all the headers in tact and not having the time, I will look into this later. I am still not sure how to go about troubleshooting this however. Thanks, RCR
Re: NO_RELAYS spam
On Fri, 2010-06-18 at 23:54 +0200, Karsten Bräckelmann wrote:
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.
Randy, any results? Did you find the cause for the issue?
--
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
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. 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 Matus UHLAR - fantomas wrote: in this case, this problem belongs more to amavis mailing list, not to spamassassin one. On 18.06.10 11:45, 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. No, the format of headers showed that they were added by amavis, not spamassassin. While amavis uses spamassassin functions, it creates different headers. Doesn't the email simply get handed to Spamassasin by Amavis where the headers are modified by spam report etc...? usuallly not. -- 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. WinError #9: Out of error messages.
Re: NO_RELAYS spam
On Thu, Jun 17, 2010 at 11:13 AM, Randy Ramsdell rramsd...@activedg.com wrote: Charles Gregory 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. 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 Hmmm, this mail came in and went straight to the users inbox. 1. Postfix --- 2. Amavis ( Spamd/Clamd) --- 3. Postfix --- 4. Dovecot-deliver So the problem is somewhere during the 2 --- 3 or step 3 or 4. Step 4 it is unlikely since Deliver simply send the file to a directory location. Check your postfix header_checks file for any IGNORE rules.
Re: NO_RELAYS spam
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/17/10 11:13 AM, Randy Ramsdell wrote: Postfix --- 2. Amavis ( Spamd/Clamd) --- 3. Postfix --- 4. Dovecot-deliver No, I run a script on the mail server manually that simply moves the files. Then I check with spamassassin. I wonder about step 4, or 5... what does this script move? Is this an MBOX format file, or Maildir? Do you have a broken Sieve script? It sounds to me like the original scoring is correct, as it does not hit the NO_RELAYS rule, and that takes place in step 2. - -- David Morton morto...@dgrmm.net Morton Software Design http://www.dgrmm.net - Ruby on Rails PHP Applications Maia Mailguard http://www.maiamailguard.com- Spam management for mail servers -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFMHhYQUy30ODPkzl0RAmoTAKCf3SvnhHdDQkRLo1lOBnKVemfRLQCeORRI RqTt83Z8uNoKK76FDpZXVX8= =8L/5 -END PGP SIGNATURE-
Re: NO_RELAYS spam
On Sun, 2010-06-20 at 08:22 -0500, David Morton wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/17/10 11:13 AM, Randy Ramsdell wrote: Postfix --- 2. Amavis ( Spamd/Clamd) --- 3. Postfix --- 4. Dovecot-deliver No, I run a script on the mail server manually that simply moves the files. Then I check with spamassassin. I wonder about step 4, or 5... what does this script move? Is this an MBOX format file, or Maildir? Do you have a broken Sieve script? It sounds to me like the original scoring is correct, as it does not hit the NO_RELAYS rule, and that takes place in step 2. An easy way to check what's in the message at steps 2 and 4 would be to add an always_bcc directive to /etc/postfix/main.cf, which will send a copy of every mail message that passes through Postfix to a nominated mailbox. If amavis is being run as a Postfix service, i.e. using sendmail to re-inject the scanned message into the Postfix mail queue, then always_bcc will capture two copies of the message - (1) after delivery to Postfix and (2) on redelivery to Postfix after its been through amavis. You can then use procmail and/or mboxgrep to search through the captured messages. Martin
Re: NO_RELAYS spam
Randy Ramsdell rramsd...@activedg.com wrote: Using sendmail without certain areguments will cause the To: field to show up as undisclosed recipients:. Nothing would make sendmail write a bogus header like that one. That is not a valid email address. This is valid: To: undisclosed recipients:; It's the list syntax with a null list. The name of the list (undisclosed recipients) has no marks. The addresses in the list would be between the colon and semicolon and each would be in marks. The malformed undisclosed recipients: is probably a good clue to tracking down what software is involved. Most mail software would not write that. Joseph Brennan Columbia University Information Technology
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: 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: [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: 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; }}}
NO_RELAYS spam
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. Thanks, RCR
Re: NO_RELAYS spam
On 6/17/10 10:38 AM, Randy Ramsdell wrote: 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. its coming from you then :-( or, your mail server is stripping out or not adding headers. RFC's require your mail server to add the header for the SMTP server that connected to you and add a header. check your 'contact us' forms on your web site for holes. then, check the blacklists to see how to get removed. Thanks, RCR -- Michael Scheidell, CTO Phone: 561-999-5000, x 1259 *| *SECNAP Network Security Corporation * Certified SNORT Integrator * 2008-9 Hot Company Award Winner, World Executive Alliance * Five-Star Partner Program 2009, VARBusiness * Best Anti-Spam Product 2008, Network Products Guide * King of Spam Filters, SC Magazine 2008 __ This email has been scanned and certified safe by SpammerTrap(r). For Information please see http://www.secnap.com/products/spammertrap/ __
Re: NO_RELAYS spam
Michael Scheidell wrote: On 6/17/10 10:38 AM, Randy Ramsdell wrote: 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. its coming from you then :-( or, your mail server is stripping out or not adding headers. RFC's require your mail server to add the header for the SMTP server that connected to you and add a header. check your 'contact us' forms on your web site for holes. then, check the blacklists to see how to get removed. Thanks, RCR Blacklists? What makes you think we are on a blacklist? As far as I can tell we are not on any lists. Well looks like you are correct regarding the mail server stripping these. It makes no sense because we do not have rules that do this. The modifications done are done by spamassassin when it rewrites the header with a report and score. 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. 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 Any ideas how this could happen?
Re: NO_RELAYS spam
Michael Scheidell wrote: On 6/17/10 10:38 AM, Randy Ramsdell wrote: 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. its coming from you then :-( or, your mail server is stripping out or not adding headers. RFC's require your mail server to add the header for the SMTP server that connected to you and add a header. check your 'contact us' forms on your web site for holes. then, check the blacklists to see how to get removed. Thanks, RCR I just checked our spam reports and this rule never hits. It is not locally generated email either or I can not find any coming from us. This is an strange issue and I am not where to begin to determine what is doing this.
Re: NO_RELAYS spam
On 6/17/10 11:31 AM, Randy Ramsdell wrote: I just checked our spam reports and this rule never hits. It is not locally generated email either or I can not find any coming from us. This is an strange issue and I am not where to begin to determine what is doing this. if you have an insecure web form, contact form, 'email us' form, the spammers will use it to send spam. MAYBE it is coming from that. (and if it is, and spammers are using you, you will get on blacklists :-( ) do you need packet dumps? what about mail logs? does your mail server tell you where these emails are coming from? -- Michael Scheidell, CTO Phone: 561-999-5000, x 1259 *| *SECNAP Network Security Corporation * Certified SNORT Integrator * 2008-9 Hot Company Award Winner, World Executive Alliance * Five-Star Partner Program 2009, VARBusiness * Best Anti-Spam Product 2008, Network Products Guide * King of Spam Filters, SC Magazine 2008 __ This email has been scanned and certified safe by SpammerTrap(r). For Information please see http://www.secnap.com/products/spammertrap/ __
Re: NO_RELAYS spam
Michael Scheidell wrote: On 6/17/10 11:31 AM, Randy Ramsdell wrote: I just checked our spam reports and this rule never hits. It is not locally generated email either or I can not find any coming from us. This is an strange issue and I am not where to begin to determine what is doing this. if you have an insecure web form, contact form, 'email us' form, the spammers will use it to send spam. MAYBE it is coming from that. (and if it is, and spammers are using you, you will get on blacklists :-( ) do you need packet dumps? what about mail logs? does your mail server tell you where these emails are coming from? I understand how letting spammers send mail through our systems could 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
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. 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 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] Right there, we see 'RCVD_IN_SORBS'. This would not happen even if your own server was blacklisted with SORBS. There *was* a Received header for a relay, and somehow you have 'removed' it, either via a filtering mechanism outside SA, or by 'resending' or 'forwarding' the mail. After running spamassassin -D If this is what you used, then the forwarding and header rewriting must have occurred prior to this. Did someone 'forward' the spam to you as a complaint? Users often fail to properly forward with full headers enclosed. - C
Re: NO_RELAYS spam
Charles Gregory 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. 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 Hmmm, this mail came in and went straight to the users inbox. 1. Postfix --- 2. Amavis ( Spamd/Clamd) --- 3. Postfix --- 4. Dovecot-deliver So the problem is somewhere during the 2 --- 3 or step 3 or 4. Step 4 it is unlikely since Deliver simply send the file to a directory location. 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] Right there, we see 'RCVD_IN_SORBS'. This would not happen even if your own server was blacklisted with SORBS. There *was* a Received header for a relay, and somehow you have 'removed' it, either via a filtering mechanism outside SA, or by 'resending' or 'forwarding' the mail. After running spamassassin -D If this is what you used, then the forwarding and header rewriting must have occurred prior to this. Did someone 'forward' the spam to you as a complaint? Users often fail to properly forward with full headers enclosed. - C No, I run a script on the mail server manually that simply moves the files. Then I check with spamassassin.
Re: NO_RELAYS spam
On Thu, 17 Jun 2010, 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 So the problem is somewhere during the 2 --- 3 or step 3 or 4. Step 4 it is unlikely since Deliver simply send the file to a directory location. I'm afraid I'm going to have to side with the people who suggested that something in the above steps is deleting headers. Postfix is pretty much guaranteed to add at least one Received header, even if it is just 'Received from localhost'. so if you can guarantee that Step 1 is being done, then something in a later Step is removing headers. Good luck with finding it! :) - C
Re: NO_RELAYS spam
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.
--
Dave Funk University of Iowa
dbfunk (at) engineering.uiowa.eduCollege of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include std_disclaimer.h
Better is not better, 'standard' is better. B{
Re: NO_RELAYS spam
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 -- # Debian GNU/Linux Consultant ## Development of Intranet and Embedded Systems with Debian GNU/Linux itsyst...@tdnet France EURL itsyst...@tdnet UG (limited liability) Owner Michelle KonzackOwner Michelle Konzack Apt. 917 (homeoffice) 50, rue de Soultz Kinzigstraße 17 67100 Strasbourg/France 77694 Kehl/Germany Tel: +33-6-61925193 mobil Tel: +49-177-9351947 mobil Tel: +33-9-52705884 fix http://www.itsystems.tamay-dogan.net/ http://www.flexray4linux.org/ http://www.debian.tamay-dogan.net/ http://www.can4linux.org/ Jabber linux4miche...@jabber.ccc.de ICQ#328449886 Linux-User #280138 with the Linux Counter, http://counter.li.org/ signature.pgp Description: Digital signature
