Hi,
Excuse my ignorance (I'm new to this...), but what is the difference between
filter_helo and filter_relay?
My assumption is that helo is used when a client directly logs in through
SMTP to send an email (generally a local user, so most likely going to be
OUTBOUND or INTERNAL emails) whereas
On Fri, Apr 21, 2006 at 01:57:38PM +0800, Mark van Proctor wrote:
Excuse my ignorance (I'm new to this...), but what is the difference between
filter_helo and filter_relay?
My assumption is that helo is used when a client directly logs in through
SMTP to send an email (generally a local
On Apr 20, 2006, at 10:57 PM, Mark van Proctor wrote:
Hi,
Excuse my ignorance (I'm new to this...), but what is the difference
between
filter_helo and filter_relay?
My assumption is that helo is used when a client directly logs in
through
SMTP to send an email (generally a local user, so
On Thu, 20 Apr 2006, John Rudd wrote:
On Apr 20, 2006, at 16:34, nathan r. hruby wrote:
- ratware infected boxen on campus use campus relays which relay by IP.
They spew, we queue. Badness for everyone.
We no longer have our student-residential IP block in our relay domain for
this
--On Thursday, April 20, 2006 21:12 -0500 Les Mikesell
[EMAIL PROTECTED] wrote:
The
logs show that it is hit by dictionary attacks fairly often
with the interesting part being that the messages are being
sent by many different machines at the same time but rate
limited somehow so there are
--On Friday, April 21, 2006 9:30 -0400 nathan r. hruby [EMAIL PROTECTED]
wrote:
- Inbound ratware using SMTP AUTH to authenticate as a real user
Hm. We haven't seen this at all yet. That's not a good sign.
Yeah. We were *thrilled* to see this happening. *Thrilled* I tell you.
-Original Message-
From: Martin Blapp
Sent: Monday, April 17, 2006 8:00 AM
Spamassassin version is 3.1.0, looks like I'll have to upgrade to 3.1.1
to get this to work?
Seems so, yes. I'll correct the manual.
Has this package/plugin been updated yet with the various fixes
John Rudd wrote:
On Apr 20, 2006, at 16:34, nathan r. hruby wrote:
- Inbound ratware using SMTP AUTH to authenticate as a real user
Hm. We haven't seen this at all yet. That's not a good sign.
I see this as a good thing. You can tie the spam back to a particular user.
They change their
[EMAIL PROTECTED] wrote on 04/21/2006 02:05:52
PM:
I see this as a good thing. You can tie the spam back to a
particular user. They change their password, and the ratware is
blocked.
Are the credentials really stolen, or is the ratware actually using the
credentials that belong on the
WBrown wrote:
Are the credentials really stolen, or is the ratware actually using
the credentials that belong on the zombied computer. I would bet the
later. User changes password without cleaning off the infection and
goes right back to sending spam.
... in which case you can infer that
[EMAIL PROTECTED] wrote:
... in which case you can infer that they're infected, and the problem has gone
from a technical one to a business one. Do you cut off the customer's access,
fix their infection, send them a warning note... ?
I would think it depends on who you are... an ISP, a
Maybe another possibility is to limit what accounts get images..
I've been thinking about this, in relation to clients wanting their
email address on their webpages (uurrgghh). If there is a [EMAIL PROTECTED]
or abuse@ postmaster@ webmaster@ (etc...), would it be worth it to
deny connections,
Hi,
On a different note concerning images, what about an email filter logging the
possibility of the images containing hidden data (i.e. Steganography test).
I already log possible text (I count alphanummeric chars in the ocr output)
+header SPAMPIC_ALPHA_1 OCR-Output =~
On 4/21/06, Paul Whittney [EMAIL PROTECTED] wrote:
Maybe another possibility is to limit what accounts get images..
I've been thinking about this, in relation to clients wanting their
email address on their webpages (uurrgghh). If there is a [EMAIL PROTECTED]
or abuse@ postmaster@ webmaster@
Thanks, this makes perfect sense now!
So basically $RelayAddr is who they really are and $Helo is who they *say* they
are...
Thanks!
BTW - I would class a locally originating email destined for a local user as
INTERNAL, a locally originating email destined for a remote email address as
Martin Blapp wrote:
I already log possible text (I count alphanummeric chars in the ocr output)
I think it would be interesting to add a new text/plain part to the e-mail
consisting of the OCR'd text, and feed that into Bayes. Even if OCR gets
some words wrong, I bet the same mis-spelled
16 matches
Mail list logo
