You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Randy Ramsdell <rr...@activedg.com> on 2010/06/17 16:38:08 UTC
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
Posted by Noel Jones <no...@gmail.com>.
On Thu, Jun 17, 2010 at 11:13 AM, Randy Ramsdell <rr...@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
Posted by Charles Gregory <cg...@hwcn.org>.
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
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>>>> 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, uhlar@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 #99999: Out of error messages.
Re: NO_RELAYS spam
Posted by Randy Ramsdell <rr...@activedg.com>.
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
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
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\0.@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;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: NO_RELAYS spam
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
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=-9999
> 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\0.@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;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: [sa] Re: NO_RELAYS spam
Posted by Randy Ramsdell <rr...@activedg.com>.
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=-9999
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: [sa] Re: NO_RELAYS spam
Posted by Charles Gregory <cg...@hwcn.org>.
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: NO_RELAYS spam
Posted by Randy Ramsdell <rr...@activedg.com>.
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: NO_RELAYS spam
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>> 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, uhlar@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
Posted by Martin Gregorie <ma...@gregorie.org>.
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
Posted by David Morton <mo...@dgrmm.net>.
-----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 <mo...@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
Posted by Randy Ramsdell <rr...@activedg.com>.
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=-9999
>> 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
Posted by Charles Gregory <cg...@hwcn.org>.
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=-9999
> 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
Posted by Randy Ramsdell <rr...@activedg.com>.
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=-9999
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
Posted by Joseph Brennan <br...@columbia.edu>.
Randy Ramsdell <rr...@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
Posted by Randy Ramsdell <rr...@activedg.com>.
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
Posted by David B Funk <db...@engineering.uiowa.edu>.
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.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: NO_RELAYS spam
Posted by Randy Ramsdell <rr...@activedg.com>.
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
Posted by Michael Scheidell <sc...@secnap.net>.
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
Posted by Randy Ramsdell <rr...@activedg.com>.
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
Posted by Michael Scheidell <sc...@secnap.net>.
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
Posted by Randy Ramsdell <rr...@activedg.com>.
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
Posted by Michelle Konzack <li...@tamay-dogan.net>.
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
itsystems@tdnet France EURL itsystems@tdnet UG (limited liability)
Owner Michelle Konzack Owner 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 linux4michelle@jabber.ccc.de
ICQ #328449886
Linux-User #280138 with the Linux Counter, http://counter.li.org/