On 6/30/2006 11:08 PM, Ross Boylan wrote:
To clear up an ambiguity in my original:
On Fri, 2006-06-30 at 19:19 -0700, Ross Boylan wrote:
Does a machine that is not part of my domain qualify as a client?
Suppose my MTA is contacted by a dial-up IP for somewhere.com (not my
domain), and that I do
I want to block outgoing mail to commonly misspelled domains that
are owned by typosquatters/redirect/spam/datamining people.
It's one thing to end up at http://www.earchlink.net by mistake,
but to send mail to [EMAIL PROTECTED] is quite another. :-(
If you're willing to build them yourself
On 6/30/2006 9:29 PM, Mark Martinec wrote:
Daryl,
You've told SA that your users aren't a part of your internal network
though. If you configure SA to treat your users as part of your
internal network then it won't do net tests on them.
For clarity, I should have said RBL and SPF tests here
Ross Boylan wrote:
> On Thu, 2006-06-29 at 19:52 -0400, Matt Kettler wrote:
>
>> Ross Boylan wrote:
>>
>>> On Thu, 2006-06-29 at 00:30 -0400, Matt Kettler wrote:
>>>
>>>
>>>
No, internal must never receive mail directly from a dialup node. SA
applies DUL RBLs and other s
To clear up an ambiguity in my original:
On Fri, 2006-06-30 at 19:19 -0700, Ross Boylan wrote:
> Does a machine that is not part of my domain qualify as a client?
> Suppose my MTA is contacted by a dial-up IP for somewhere.com (not my
> domain), and that I do want to accept such mail.
The human c
Now for the "3 tests" as they apply to my non-hypothetical case.
On Wed, 2006-06-28 at 01:45 -0400, Daryl C. W. O'Shea wrote:
[..]
> Mail Submission Agent... accepts mail from your own clients' MUAs (also
> known as UAs).
>
>
> >> You can not add your MSA to your internal_networks unless you can
On Fri, 2006-06-30 at 18:00 -0400, Daryl C. W. O'Shea wrote:
> I'm going to skip to the end pretty quick... where I tell you exactly
> the config YOU need (except I don't know your IPs, so you'll have to
> fill that in).
My setup is a bit more complex than the one described here; I said
"assume f
Daryl,
> You've told SA that your users aren't a part of your internal network
> though. If you configure SA to treat your users as part of your
> internal network then it won't do net tests on them.
I forgot what was the original reason that it became a must to treat
MSA as non-internal. Was it
On 6/30/06, Marc Perkel <[EMAIL PROTECTED]> wrote:
Yeah - but what I'm thinking of is something that is automatic and
reputation based rather that paying someone to certify you. In other
words your server get whitelisted because you never send spam.
Paid or otherwise, how do you get on the lis
Bart Schaefer wrote:
On 6/30/06, Marc Perkel <[EMAIL PROTECTED]> wrote:
Who likes this idea?
Evidently habeas.com does, as that's now their business model. Also
Bonded Sender (I think they changed the name recently, but I forget to
what). And I believe the ISIPP maintains several such list
From: "Daryl C. W. O'Shea" <[EMAIL PROTECTED]>
This inspired me to make a brute force test. Something has changed in
the machine's configuration that allows me to remove all references to
internal or trusted networks and still run without ALL_TRUSTED coming
up and bugging me. Maybe those entrie
On 1 Jul 2006, at 00:32, Daryl C. W. O'Shea wrote:
Jamie L. Penman-Smithson wrote:
It's better to look at the 'Authenticated sender':
Received: from bar.example.org (bar.example.org [127.0.0.1])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client did not present a certif
> > It is only a partial solution. It covers only one method
> > of authorizing roaming users for submitting mail to their
> > organization's MSA. It would be much better to have
> > a more general solution, trusting MSA to do its job
> > (see parallel thread "internal/trusted again, MSA tested
> >
Mark Martinec wrote:
What do you have to do to get that "Authenticated sender:" line? It's
not unpatched Postfix, is it? I know the Wietse was against such info
being provided.
Apparently postfix 2.3 will support auth tokens.
Any link document that? I'd like to add it to the wiki.
http://w
> What do you have to do to get that "Authenticated sender:" line? It's
> not unpatched Postfix, is it? I know the Wietse was against such info
> being provided.
> > Apparently postfix 2.3 will support auth tokens.
> Any link document that? I'd like to add it to the wiki.
http://www.postfix.org
From: "Stefan Jakobs" <[EMAIL PROTECTED]>
Am Freitag, 30. Juni 2006 02:09 schrieb Rick Macdougall:
Hi,
Hello,
And my hit rates are
For HAM
RANKRULE NAMECOUNT %OFRULES %OFMAIL %OFSPAM %OFHAM
1BAYES_00 2281924.15 54.611.65 96.70
And SPAM
RANKRULE NAME
Jamie L. Penman-Smithson wrote:
It's better to look at the 'Authenticated sender':
Received: from bar.example.org (bar.example.org [127.0.0.1])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client did not present a certificate)
(Authenticated sender: sender.example.ne
jdow wrote:
From: "Daryl C. W. O'Shea" <[EMAIL PROTECTED]>
jdow wrote:
From: "Daryl C. W. O'Shea" <[EMAIL PROTECTED]>
jdow wrote:
From: "Daryl C. W. O'Shea" <[EMAIL PROTECTED]>
The Earthlink mail servers are ABSODAMNLUTELY not part
of my internal network. But if I do not list them with tr
On 30 Jun 2006, at 23:25, Daryl C. W. O'Shea wrote:
martin f krafft wrote:
Sure you do... at least auth headers that you know you added.
Your problem is that Postfix doesn't include RFC 3848 style (or
any) auth tokens.
This TLS line is only added when someone authenticates
successfully, r
We recently installed a new CentOS4 server, which comes with SA 3.0.6
prepackaged, to serve as our local mail store (runs sendmail,
clamassassin, spamd, and an imap server). The perl version is 5.8.5,
and it's an x86_64 platform.
Since migrating our users to this machine we frequently have spam
Bart Schaefer wrote:
On 6/30/06, Daryl C. W. O'Shea <[EMAIL PROTECTED]> wrote:
OK, I see now that you want to unconditionally trust the MSA *and* all
hosts after it. Which is reasonable if the MSA is just an MSA. For
whatever reason you don't want to rely on auth tokens, etc. Seems
reasonabl
On 6/30/06, Daryl C. W. O'Shea <[EMAIL PROTECTED]> wrote:
OK, I see now that you want to unconditionally trust the MSA *and* all
hosts after it. Which is reasonable if the MSA is just an MSA. For
whatever reason you don't want to rely on auth tokens, etc. Seems
reasonable to me.
That would
On 6/30/06, Marc Perkel <[EMAIL PROTECTED]> wrote:
Who likes this idea?
Evidently habeas.com does, as that's now their business model. Also
Bonded Sender (I think they changed the name recently, but I forget to
what). And I believe the ISIPP maintains several such lists. Do a
Google on "repu
martin f krafft wrote:
also sprach Daryl C. W. O'Shea <[EMAIL PROTECTED]> [2006.06.06.2021 +0200]:
If you provide a full set of received headers that are being
passed to SA, someone can help you out with the correct settings.
I am having difficulties recreating the problem. Sometimes SA will
h
martin f krafft wrote:
also sprach martin f krafft <[EMAIL PROTECTED]> [2006.06.06.1401 +0200]:
Regarding the issue I raised in February (to which I have not yet
found an answer), you may be interested in checking out the last
paragraph of http://blog.madduck.net/geek/2006.06.06-delayed-mail,
wh
I'm going to skip to the end pretty quick... where I tell you exactly
the config YOU need (except I don't know your IPs, so you'll have to
fill that in).
Ross Boylan wrote:
Well, I've obviously missed something. In this message I will focus
exclusively on the question of whether a host that r
I want to propose and idea that I've been testing with some success. But
there are plenty of people who are a lot sharper than I am that can
implement it better. Here's what I'm thinking.
We are all familiar with DNS blacklists to block spam. But what about
lists of other servers? What about w
Ben Wylie wrote:
No. Internal only if it's not directly accepting mail from client IPs
that you WANT to accept mail from. MXes and everything (internal
relays) after them are ALWAYS in both trusted and internal networks.
>
> This is what tells SA that mail was sent directly from "questionab
Mark Martinec wrote:
Daryl C. W. O'Shea writes:
Yeah, and correct. Your MSA is the host responsible for sending the
mail to your server running SA. Your SPF record must cover the MSAs IP.
Ok, as a stop-gap solution this works, thanks.
But it is not the right general-purpose solution. This i
Radoslaw Zielinski wrote:
Daryl C. W. O'Shea <[EMAIL PROTECTED]> [30-06-2006 00:45]:
Mark Martinec wrote:
Hmm, I don't think that our own is supposed to be tested for SPF.
It is normal?
Yeah, and correct. Your MSA is the host responsible for sending the
mail to your server running SA. Y
Well, I've obviously missed something. In this message I will focus
exclusively on the question of whether a host that receives messages
from dial-up hosts should go on internal_networks. Assume for
simplicity I have a mail domain b.c. The MX records point to a.b.c.
I'm running SA on a.b.c for m
On Thu, 2006-06-29 at 19:52 -0400, Matt Kettler wrote:
> Ross Boylan wrote:
> > On Thu, 2006-06-29 at 00:30 -0400, Matt Kettler wrote:
> >
> >
> >> No, internal must never receive mail directly from a dialup node. SA
> >> applies DUL RBLs and other such tests against hosts delivering mail to
> >
Is there an RBL or a list of commonly misspelled domain names that ARE
registered?
I want to block outgoing mail to commonly misspelled domains that are
owned by typosquatters/redirect/spam/datamining people.
It's one thing to end up at http://www.earchlink.net by mistake, but to
send mail
>>SpamAssassin version 3.1.1
>>
>>We are getting valid mail from outlook express users on btinternet
>>tagged as FORGED_MUA_OUTLOOK. It looks to me like spamassassin does
not
>>identify the message-id as an outlook express message-id and therefore
>>marks it as forged.
>>
>>Is anyone else seeing
also sprach martin f krafft <[EMAIL PROTECTED]> [2006.06.06.1401 +0200]:
> Regarding the issue I raised in February (to which I have not yet
> found an answer), you may be interested in checking out the last
> paragraph of http://blog.madduck.net/geek/2006.06.06-delayed-mail,
> which also includes
In article <[EMAIL PROTECTED]
c.ac.uk>, brandon pearson (BITS) <[EMAIL PROTECTED]> writes
>SpamAssassin version 3.1.1
>
>We are getting valid mail from outlook express users on btinternet
>tagged as FORGED_MUA_OUTLOOK. It looks to me like spamassassin does not
>identify the message-id as an outlook
> > Is it normal that our own MSA ip address is being submitted for RBL
> > tests?
Daryl C. W. O'Shea writes:
> It' normal, in the sense that that's what the code says to do. I'm sure
> that this isn't optimal, but it works better than the way we did it
> before (lastuntrusted FP'd all over).
S
Hi everyone,
The message-ID's of mails that have been (auto-)learned by Bayes are
stored indefinitely in bayes_seen. Which, over the years that we've used
SpamAssassin now, has grown to a 320MB file. We're using site-wide Bayes
databases. What would be the best way to trim down this database,
SpamAssassin version 3.1.1
We are getting valid mail from outlook express users on btinternet
tagged as FORGED_MUA_OUTLOOK. It looks to me like spamassassin does not
identify the message-id as an outlook express message-id and therefore
marks it as forged.
Is anyone else seeing this?
Thanks,
Br
Daryl C. W. O'Shea <[EMAIL PROTECTED]> [30-06-2006 00:45]:
> Mark Martinec wrote:
[...]
>> dbg: dns: checking RBL sbl-xbl.spamhaus.org., set sblxbl
>> dbg: dns: IPs found: full-external: ,
>> untrusted: originating:
>> dbg: dns: only inspecting the following IPs:
>> Good, is being t
You can find a Bayes starter DB over at http://www.fsl.com/support/
I've used it here after our Bayes database got trashed
without having any false positive problems.
We use Bayes autolearn here, and after some good manual
training I've never seen it cause problems.
The key is to have a
Am Freitag, 30. Juni 2006 02:09 schrieb Rick Macdougall:
> Hi,
Hello,
> And my hit rates are
>
> For HAM
> RANKRULE NAMECOUNT %OFRULES %OFMAIL %OFSPAM %OFHAM
> 1BAYES_00 2281924.15 54.611.65 96.70
>
> And SPAM
> RANKRULE NAMECOUNT %OFRULES %OFMAIL %OFSPAM
No. Internal only if it's not directly accepting mail from client IPs
that you WANT to accept mail from. MXes and everything (internal
relays) after them are ALWAYS in both trusted and internal networks.
>
> This is what tells SA that mail was sent directly from "questionable
> IPs" to your sy
Hi,
Loren Wilton wrote:
You are into the land of opinions here, so you will get different answers.
Once you have the basic stuff I personally prefer to leave auto-learning
turned off and only had Bayes hams and spams that might be
misclassified, or ones where the bayes score isn't high e
44 matches
Mail list logo
