I've got a rule for spotting a dodgy X-Originating-IP:
header PJ_BOGUS_XORIGIN X-Originating-IP =~ /\.([3-9][^. ][^. ]+|2[6-9][^.
]+|25[6-9][^. ]*)\./
I was investigating an unusual hit, when I noticed the following:
It will produce a positive hit when an email contains two lines like
Hi
I'm using spampd as a before filter with Postfix and it works really well...
except...
There is one specific message someone is trying to send to me, it has 4 or 5
Mb of pdf attachments and every time it hits my mail server it times out.
The thing that is strange is the first thing spampd
I receive a lot of emails from The IT JobBoard or JobsInThe City,
see example at
http://igor.chudov.com/tmp/spam002.txt
They look like outright spams to me, by looking at the way they are
relayed. I tried unsubscribing, which did not help very much.
Are there any more info on those
On Fri, Oct 05, 2007 at 11:30:30AM -0700, Tom Bombadil wrote:
Loren Wilton wrote:
I don't know how you would do it in exim (or if you even could) but in
theory you could have two SA setups. One would only have the clam
plugin enabled and no other rules, and the other would have the full
Or think of it as a way of SA saying when I get twelve spams of
score 10+ from ip 208.23.118.172...I will feed the auto-expiring RBL,
which *SENDMAIL* works off of, thus keeping my *SPAMASSASSIN* load
lower. Thus a spam deluge via a dictionary attack that may take hours
is mitigated in the
Per,
X-Originating-IP: [17.148.16.66]
X-Originating-IP: 134.32.140.207
...
It looks to me like the two X-Originating-IP lines are merged into
one, and my regex is then applied to:
X-Originating-IP: [17.148.16.66]134.32.140.207
True (with newline inbetween).
Is this normal/correct
Hello,
Which spam blacklists do you use in your MTA config. (postfix)
smptd_client_restrictions
Currently we only use : reject_rbl_client list.dsbl.org
We let spamassassin fight the rest of the spam. But the load of spam is
getting to high for our organisation. Wich list is safe enough to block
Mark Martinec wrote:
Per,
X-Originating-IP: [17.148.16.66]
X-Originating-IP: 134.32.140.207
...
It looks to me like the two X-Originating-IP lines are merged into
one, and my regex is then applied to:
X-Originating-IP: [17.148.16.66]134.32.140.207
True (with newline inbetween).
Is
On Tue, 2007-10-09 at 17:34 +0200, R.Smits wrote:
Hello,
Which spam blacklists do you use in your MTA config. (postfix)
smptd_client_restrictions
Currently we only use : reject_rbl_client list.dsbl.org
We let spamassassin fight the rest of the spam. But the load of spam is
getting to
R.Smits wrote:
Hello,
Which spam blacklists do you use in your MTA config. (postfix)
smptd_client_restrictions
Currently we only use : reject_rbl_client list.dsbl.org
We let spamassassin fight the rest of the spam. But the load of spam is
getting to high for our organisation. Wich list is
Per Jessen writes:
Mark Martinec wrote:
Per,
X-Originating-IP: [17.148.16.66]
X-Originating-IP: 134.32.140.207
...
It looks to me like the two X-Originating-IP lines are merged into
one, and my regex is then applied to:
X-Originating-IP: [17.148.16.66]134.32.140.207
None. I'd rather bump up my system resources than allow a system completely
out of my control to assess whether or not mail should run through my MTA
and SA.
- Skip
shalom hipsters
Running nuonce BQ machine(s) and this has been the deal with all of
them.
At some point our filters drop.( currenly the case see below)...mail
still gets sent as sendmail must not wait forever to hear back from MS.
My ( newbie ) self thinks spamassassitn in the culprit.
My
On Tue, 9 Oct 2007 at 10:00 -0700, [EMAIL PROTECTED] confabulated:
Spamhaus: yes. Use zen.spamhaus.org (you might end up needing to pay for
it, and use a local cache, if you're a heavy traffic site, but, frankly, it's
worth paying for).
We use Spamhaus here with their datefeed service. Our
jason lingnau wrote:
shalom hipsters
Running nuonce BQ machine(s) and this has been the deal with all of them.
At some point our filters drop.( currenly the case see below)...mail
still gets sent as sendmail must not wait forever to hear back from MS.
My ( newbie ) self thinks spamassassitn
Quoting John Rudd [EMAIL PROTECTED]:
R.Smits wrote:
Hello,
Which spam blacklists do you use in your MTA config. (postfix)
smptd_client_restrictions
Currently we only use : reject_rbl_client list.dsbl.org
We let spamassassin fight the rest of the spam. But the load of spam is
John Rudd wrote:
Spamcop: no. Don't use them as an MTA RBL. I'm leery of even using
them as a SA RBL, but it's a very bad idea to use them as an MTA RBL
(too many false positives).
Actually, sometime in the past several months, SpamCop's FP rate dropped
dramatically. I'm not privy to the
Jeff Chan writes:
Quoting John Rudd [EMAIL PROTECTED]:
R.Smits wrote:
Spamcop: no. Don't use them as an MTA RBL. I'm leery of even using
them as a SA RBL, but it's a very bad idea to use them as an MTA RBL
(too many false positives).
I was about to give the same answer
actually
* R.Smits [EMAIL PROTECTED]:
Hello,
Which spam blacklists do you use in your MTA config. (postfix)
smptd_client_restrictions
None, we put them like all restrictions into
smtpd_recipient_restrictions.
Currently we only use : reject_rbl_client list.dsbl.org
reject_rbl_client
Also, psbl.surriel.com has gotten much better in recent months. It used
to have occasional FPs, but I haven't seen any in a while. In my own
spam filtering, I merely score on RBLs and I don't outright block... but
if I were a large ISP which didn't have that luxury, I'd probably use
the
On 10/9/07, R.Smits [EMAIL PROTECTED] wrote:
Hello,
Which spam blacklists do you use in your MTA config. (postfix)
smptd_client_restrictions
Currently we only use : reject_rbl_client list.dsbl.org
We let spamassassin fight the rest of the spam. But the load of spam is
getting to high for
Base-64 encoding of HTML strikes me as a little odd. I wonder if it would
make a good spam sign.
Loren
To me it looks like a misfeature.
I think I would agree that it may be a misfeature in the case of this
specific header. In general though it may not be. Consider the case of two
separate Subject: headers, often with completely different subjects. There
was a time that was a quite decent
Hello,
Which spam blacklists do you use in your MTA config. (postfix)
smptd_client_restrictions
Currently we only use : reject_rbl_client list.dsbl.org
http://list.dsbl.org
We let spamassassin fight the rest of the spam. But the load of spam is
getting to
On Tue, 9 Oct 2007, Loren Wilton wrote:
Base-64 encoding of HTML strikes me as a little odd. I wonder if
it would make a good spam sign.
Very likely. The only reason to do that is to shield the HTML from
pattern matching filters that don't decode text body parts first.
Of course, it might
On Tue, 9 Oct 2007, Richard Smits wrote:
| Thanks for all the advice.. I think we will be using spamhaus. I am
| running a test and it blocks a lot of spam. Currently I use the
| sbl.spamhaus and pbl.spamhaus
| Is this wise, or should I also use the xbl and switch to zen.spamhaus?
You should
Well, in the real world, many of us who would have to scan
over 150,000 inbound emails a day, of which about 85% are
pure 100% spam simply don't have that luxury...
We've had best results with zen.spamhaus.org , other dnsbls
seem unreliable/not worth the effort
regards,
jp
On Tue, 9 Oct 2007, Skip wrote:
| I have a number of travelling personnel from my company. I don't want the
| call at 11pm on a Wednesday night or 6 am on a Sunday morning from a hotel
| and the network they are on is on one of those lists and they can't use
| their email.
Hi,
Your travellers
On Tue, 9 Oct 2007, Loren Wilton wrote:
Base-64 encoding of HTML strikes me as a little odd. I wonder if
it would make a good spam sign.
Very likely. The only reason to do that is to shield the HTML from
pattern matching filters that don't decode text body parts first.
Of
Dan Mahoney, System Admin wrote:
sa-update does NOT feed a local blocklist generated by *my* particular
corpus of spam emails. Think of it as the RBL equivalent of
sitewide-bayes. Or think of it as a way of SA saying when I get twelve
spams of score 10+ from ip 208.23.118.172...I will feed
-Original Message-
From: Skip [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 09, 2007 2:26 PM
To: users@spamassassin.apache.org
Subject: RE: Advice on MTA blacklist
Well, in the real world, many of us who would have to scan
over 150,000 inbound emails a day, of which about
From: Chris Edwards
Your travellers should be using one of:
- Authenticated SMTP submission bypassing your DNSBL tests
- VPN into your network
- Your webmail service
All of these are available. Unless I somehow had something configured
improperly, the blacklists were rejecting connection to
Skip,
Chris's point is that your users **should** use SMTP authorization to
distinguish their trusted connections from other connections that must
be spam filtered. Additionally, you should NOT do ANY spam filtering on
these SMTP Auth connections... especially not outright RBL blocking. You
On 9 Oct 2007 [EMAIL PROTECTED] wrote:
On Tue, 9 Oct 2007, Loren Wilton wrote:
Base-64 encoding of HTML strikes me as a little odd. I wonder if
it would make a good spam sign.
Very likely. The only reason to do that is to shield the HTML from
pattern matching filters that don't
On Tue, 9 Oct 2007, Skip wrote:
| Unless I somehow had something configured improperly, the blacklists
| were rejecting connection to the MTA before SMTP auth.
Hi,
That's the problem - you don't want to do blacklist lookups for SMTP-AUTH
submissions.
FWIW we use Exim which has plenty
On Tue, 9 Oct 2007, Steven Kurylo wrote:
Or think of it as a way of SA saying when I get twelve spams of score 10+
from ip 208.23.118.172...I will feed the auto-expiring RBL, which
*SENDMAIL* works off of, thus keeping my *SPAMASSASSIN* load lower. Thus a
spam deluge via a dictionary attack
I thought about that, but encoding the *entire* HTML body in base64 is
not a reasonable way to deal with that; you should just encode the
individual accented characters properly using standard HTML encoding
methods. Encoding the entire HTML body in base-64 is terribly
wasteful given how much it
Parsing the SA logs would be easy, but the connecting IP isn't listed
there.
As I mentioned, I'm parsing exim's logs. It contains the spam score and
the IP address.
On Tue, 9 Oct 2007, Steven Kurylo wrote:
Parsing the SA logs would be easy, but the connecting IP isn't listed
there.
As I mentioned, I'm parsing exim's logs. It contains the spam score and the
IP address.
Oh, that's true enough. I was musing on parsing my own logfiles as
opposed to
Dan Mahoney, System Admin wrote:
On Tue, 9 Oct 2007, Steven Kurylo wrote:
Parsing the SA logs would be easy, but the connecting IP isn't listed
there.
As I mentioned, I'm parsing exim's logs. It contains the spam score and the
IP address.
Oh, that's true enough. I was musing on
On Oct 9, 2007, at 10:37 AM, James E. Pratt wrote:
Well, in the real world, many of us who would have to scan over
150,000
inbound emails a day, of which about 85% are pure 100% spam simply
don't
have that luxury...
Are you using a 486 to process inbound mail? My 1.4Ghz Athlon 2
system
On Oct 9, 2007, at 11:31 AM, Chris Edwards wrote:
Your travellers should be using one of:
- Authenticated SMTP submission bypassing your DNSBL tests
- VPN into your network
- Your webmail service
Thus it shouldn't matter if their hotel is blacklisted (many are).
Both Crackberry and Verizon
On Tue, 9 Oct 2007, Jo Rhett wrote:
| Both Crackberry and Verizon force you to use their mail servers. Some other
| data providers are now doing transparent proxy on outbound e-mail. In short,
| the user can't always control that.
True, to an extent. I don't know about the *berry, but
On Tue, 9 Oct 2007, Jo Rhett wrote:
| Right, but transparent proxy of SMTP connections is available in even the
| lowest end firewalls now (like free ones you get with service).
OK.
| And very few clients will complain if they aren't required to do SMTP
| auth, which means that the user will
On Oct 9, 2007, at 3:52 PM, Chris Edwards wrote:
However, even assuming your user *is* using the *berry server or the
verizon transparent proxy, then mails they send will in the main
emerge
from a legit mail server run by grown-ups, which is far far less
likely to
be blacklisted then a user
On Oct 9, 2007, at 4:22 PM, Chris Edwards wrote:
Of course the best solution is for clients to always submit on port
465/587,
and hope that's allowed out by the hotels / mobile connectivity
providers.
Fairly often not. I've been lucky with T-Mobile, but Sprint and
Verizon apparently
Chris Edwards wrote:
On Tue, 9 Oct 2007, Jo Rhett wrote:
| Both Crackberry and Verizon force you to use their mail servers. Some other
| data providers are now doing transparent proxy on outbound e-mail. In
short,
| the user can't always control that.
True, to an extent. I don't know
47 matches
Mail list logo
