[gentoo-user] clamav and spamassassin

[gentoo-user] clamav and spamassassin

[Grant]

I haven't set up any antivirus measures on my Gentoo systems so I
think I should.  Is clamav run as a scheduled filesystem scanner on
each system and as an email scanner on the mail server all that's
necessary?

I'm currently greylisting email to prevent spam from getting through.
It catches a lot, but more and more gets through.  I'm not using any
mailfilters now and If I set up a clamav mailfilter I think I may as
well set up a spamassassin mailfilter to take the place of
greylisting.  Is this the best guide for clamav and spamassassin:

http://www.gentoo.org/doc/en/mailfilter-guide.xml

Could I run into any problems with clamav or spamassassin that might
make we wish I hadn't implemented them?

- Grant

Re: [gentoo-user] clamav and spamassassin

[Michael Orlitzky]

On 12/03/2011 02:52 PM, Grant wrote:
> I haven't set up any antivirus measures on my Gentoo systems so I
> think I should.  Is clamav run as a scheduled filesystem scanner on
> each system and as an email scanner on the mail server all that's
> necessary?

Nobody (as far as I know?) scans linux filesystems unless there's a 
legal requirement or the files might wind up on a Windows box.


> I'm currently greylisting email to prevent spam from getting through.
> It catches a lot, but more and more gets through.  I'm not using any
> mailfilters now and If I set up a clamav mailfilter I think I may as
> well set up a spamassassin mailfilter to take the place of
> greylisting.  Is this the best guide for clamav and spamassassin:

SpamAssassin shouldn't take the place of greylisting; they reject 
different stuff. Keep the greylisting unless the delays bother you, but 
use postscreen to do it (see below).


> http://www.gentoo.org/doc/en/mailfilter-guide.xml
>
> Could I run into any problems with clamav or spamassassin that might
> make we wish I hadn't implemented them?

Yeah. The first is false positives. The second, related problem is that 
you'll have to manage a quarantine unless you stick amavisd-new in front 
of the postfix queue.

It's in that respect that the tutorial is outdated; otherwise, it looks 
good (I just skimmed it).

There is great benefit to the before-queue setup: mail will never 
disappear. Senders either get a rejection, or the mail is delivered. 
With the after-queue setup, you can no longer reject or else you'll be 
backscattering. So, you either deliver the spam, or you quarantine it 
(very bad if it's a false positive).

The downside is that you use more resources: one amavisd-new per 
connection. However, the addition of postscreen to postfix has largely 
ameliorated this. Since postscreen rejects most of the junk, amavis only 
gets started for smtpd sessions that are likely to succeed.

The easiest way to migrate is through incremental improvement. We used 
to use a system like the one in that guide. I enabled postscreen over 
the course of a week, and retired postgrey, which we had been using for 
greylisting. Once that was working properly, I simply dropped the 
content_filter in favor of smtpd_proxy_filter to move amavis in front of 
the queue.

Re: [gentoo-user] clamav and spamassassin

[Grant]

>> I haven't set up any antivirus measures on my Gentoo systems so I
>> think I should.  Is clamav run as a scheduled filesystem scanner on
>> each system and as an email scanner on the mail server all that's
>> necessary?
>
>
> Nobody (as far as I know?) scans linux filesystems unless there's a legal
> requirement or the files might wind up on a Windows box.

Very cool.  I found out clamscan and avgfree scan the filesystem so I
thought I should set it up, but if it's not necessary I won't bother.
All of my mail users are on Gentoo so do I need to bother having
clamav scan my incoming mail?

>> I'm currently greylisting email to prevent spam from getting through.
>> It catches a lot, but more and more gets through.  I'm not using any
>> mailfilters now and If I set up a clamav mailfilter I think I may as
>> well set up a spamassassin mailfilter to take the place of
>> greylisting.  Is this the best guide for clamav and spamassassin:
>
>
> SpamAssassin shouldn't take the place of greylisting; they reject different
> stuff. Keep the greylisting unless the delays bother you, but use postscreen
> to do it (see below).

I just did some reading on postscreen but it doesn't sound like a
greylister.  Should I use postscreen in addition to postgrey, or are
they substitutes for each other?

>> http://www.gentoo.org/doc/en/mailfilter-guide.xml
>>
>> Could I run into any problems with clamav or spamassassin that might
>> make we wish I hadn't implemented them?
>
>
> Yeah. The first is false positives. The second, related problem is that
> you'll have to manage a quarantine unless you stick amavisd-new in front of
> the postfix queue.

Now that sounds like a hassle.  Greylisting leaves me with about 50/50
spam/legit mail and maybe incorporating postscreen I'll do even
better.  Deleting spam in my inbox might be easier than dealing with
false positives and managing a quarantine.

- Grant


> It's in that respect that the tutorial is outdated; otherwise, it looks good
> (I just skimmed it).
>
> There is great benefit to the before-queue setup: mail will never disappear.
> Senders either get a rejection, or the mail is delivered. With the
> after-queue setup, you can no longer reject or else you'll be
> backscattering. So, you either deliver the spam, or you quarantine it (very
> bad if it's a false positive).
>
> The downside is that you use more resources: one amavisd-new per connection.
> However, the addition of postscreen to postfix has largely ameliorated this.
> Since postscreen rejects most of the junk, amavis only gets started for
> smtpd sessions that are likely to succeed.
>
> The easiest way to migrate is through incremental improvement. We used to
> use a system like the one in that guide. I enabled postscreen over the
> course of a week, and retired postgrey, which we had been using for
> greylisting. Once that was working properly, I simply dropped the
> content_filter in favor of smtpd_proxy_filter to move amavis in front of the
> queue.

Re: [gentoo-user] clamav and spamassassin

[Michael Orlitzky]

On 12/03/2011 07:59 PM, Grant wrote:
>>> I haven't set up any antivirus measures on my Gentoo systems so I
>>> think I should.  Is clamav run as a scheduled filesystem scanner on
>>> each system and as an email scanner on the mail server all that's
>>> necessary?
>>
>>
>> Nobody (as far as I know?) scans linux filesystems unless there's a legal
>> requirement or the files might wind up on a Windows box.
>
> Very cool.  I found out clamscan and avgfree scan the filesystem so I
> thought I should set it up, but if it's not necessary I won't bother.
> All of my mail users are on Gentoo so do I need to bother having
> clamav scan my incoming mail?

Well, they aren't going to get infected with anything, but ClamAV could 
still keep the virus message (which is obviously unwanted) out of their 
inbox. There are also some third-party signatures[1] for ClamAV that 
catch scam/phishing mail.


>>> I'm currently greylisting email to prevent spam from getting through.
>>> It catches a lot, but more and more gets through.  I'm not using any
>>> mailfilters now and If I set up a clamav mailfilter I think I may as
>>> well set up a spamassassin mailfilter to take the place of
>>> greylisting.  Is this the best guide for clamav and spamassassin:
>>
>>
>> SpamAssassin shouldn't take the place of greylisting; they reject different
>> stuff. Keep the greylisting unless the delays bother you, but use postscreen
>> to do it (see below).
>
> I just did some reading on postscreen but it doesn't sound like a
> greylister.  Should I use postscreen in addition to postgrey, or are
> they substitutes for each other?
>

Postscreen isn't a greylist daemon per se, but it has the same effect if 
you enable the "deep protocol" tests. Once it gets past the initial 
greeting (into the "deep" stages), postscreen can no longer hand off the 
session to a real smtpd. So, even if the client passes all of the tests, 
postscreen will send it a "4xx try again." That's essentially greylisting.

Postscreen, like Postgrey, keeps a database of good clients, so you 
shouldn't lose any functionality there. This is what makes the 
aforementioned 4xx strategy work: when the client reconnects, it 
bypasses postscreen entirely and goes to a real smtpd.

I would make the switch when you have some free time. Postscreen is part 
of postfix, so it removes one dependency from your mail system. It also 
adds a couple of nice anti-spam features for free. And, if you ever 
decide to implement Amavis, postscreen makes the before-queue setup viable.


>>> http://www.gentoo.org/doc/en/mailfilter-guide.xml
>>>
>>> Could I run into any problems with clamav or spamassassin that might
>>> make we wish I hadn't implemented them?
>>
>>
>> Yeah. The first is false positives. The second, related problem is that
>> you'll have to manage a quarantine unless you stick amavisd-new in front of
>> the postfix queue.
>
> Now that sounds like a hassle.  Greylisting leaves me with about 50/50
> spam/legit mail and maybe incorporating postscreen I'll do even
> better.  Deleting spam in my inbox might be easier than dealing with
> false positives and managing a quarantine.

You should be able to do a lot better than that with just postscreen and 
postfix. If you try to implement postscreen, post your main.cf over on 
postfix-users for review. The built-in restrictions combined with a few 
RBLs should get you well below 50/50.

Plus, if you still get too much spam, you'll already have postscreen in 
place and that will make adding amavisd-new that much easier.


[1] http://www.sanesecurity.com/

Re: [gentoo-user] clamav and spamassassin

[Grant]

>> Very cool.  I found out clamscan and avgfree scan the filesystem so I
>> thought I should set it up, but if it's not necessary I won't bother.
>> All of my mail users are on Gentoo so do I need to bother having
>> clamav scan my incoming mail?
>
>
> Well, they aren't going to get infected with anything, but ClamAV could
> still keep the virus message (which is obviously unwanted) out of their
> inbox. There are also some third-party signatures[1] for ClamAV that catch
> scam/phishing mail.

There is info on Linux viruses here:

http://en.wikipedia.org/wiki/Linux_malware

I shouldn't be concerned about that?

>> I just did some reading on postscreen but it doesn't sound like a
>> greylister.  Should I use postscreen in addition to postgrey, or are
>> they substitutes for each other?
>>
>
> Postscreen isn't a greylist daemon per se, but it has the same effect if you
> enable the "deep protocol" tests. Once it gets past the initial greeting
> (into the "deep" stages), postscreen can no longer hand off the session to a
> real smtpd. So, even if the client passes all of the tests, postscreen will
> send it a "4xx try again." That's essentially greylisting.

Got it.  Sounds like postscreen is the successor to postgrey.  I will
set that up ASAP.

Thanks,
Grant

Re: [gentoo-user] clamav and spamassassin

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 2682 bytes --]

On Dec 4, 2011 5:58 AM, "Michael Orlitzky" <michael@orlitzky.com> wrote:
>
> On 12/03/2011 02:52 PM, Grant wrote:
>>
>> I haven't set up any antivirus measures on my Gentoo systems so I
>> think I should.  Is clamav run as a scheduled filesystem scanner on
>> each system and as an email scanner on the mail server all that's
>> necessary?
>
>
> Nobody (as far as I know?) scans linux filesystems unless there's a legal
requirement or the files might wind up on a Windows box.
>
>
>
>> I'm currently greylisting email to prevent spam from getting through.
>> It catches a lot, but more and more gets through.  I'm not using any
>> mailfilters now and If I set up a clamav mailfilter I think I may as
>> well set up a spamassassin mailfilter to take the place of
>> greylisting.  Is this the best guide for clamav and spamassassin:
>
>
> SpamAssassin shouldn't take the place of greylisting; they reject
different stuff. Keep the greylisting unless the delays bother you, but use
postscreen to do it (see below).
>
>
>
>> http://www.gentoo.org/doc/en/mailfilter-guide.xml
>>
>> Could I run into any problems with clamav or spamassassin that might
>> make we wish I hadn't implemented them?
>
>
> Yeah. The first is false positives. The second, related problem is that
you'll have to manage a quarantine unless you stick amavisd-new in front of
the postfix queue.
>
> It's in that respect that the tutorial is outdated; otherwise, it looks
good (I just skimmed it).
>
> There is great benefit to the before-queue setup: mail will never
disappear. Senders either get a rejection, or the mail is delivered. With
the after-queue setup, you can no longer reject or else you'll be
backscattering. So, you either deliver the spam, or you quarantine it (very
bad if it's a false positive).
>
> The downside is that you use more resources: one amavisd-new per
connection. However, the addition of postscreen to postfix has largely
ameliorated this. Since postscreen rejects most of the junk, amavis only
gets started for smtpd sessions that are likely to succeed.
>
> The easiest way to migrate is through incremental improvement. We used to
use a system like the one in that guide. I enabled postscreen over the
course of a week, and retired postgrey, which we had been using for
greylisting. Once that was working properly, I simply dropped the
content_filter in favor of smtpd_proxy_filter to move amavis in front of
the queue.
>

This is new information to me. If you're subscribed to Gentoo-server,
you'll know that I am in the process of setting up a mailfiltering gateway
for my company.

Any resources on this "postscreen" facility? sounds like a very nice thing
to implement.

Rgds,

[-- Attachment #2: Type: text/html, Size: 3281 bytes --]

Re: [gentoo-user] clamav and spamassassin

[Michael Orlitzky]

On 12/03/2011 08:57 PM, Grant wrote:
>>> Very cool.  I found out clamscan and avgfree scan the filesystem so I
>>> thought I should set it up, but if it's not necessary I won't bother.
>>> All of my mail users are on Gentoo so do I need to bother having
>>> clamav scan my incoming mail?
>>
>>
>> Well, they aren't going to get infected with anything, but ClamAV could
>> still keep the virus message (which is obviously unwanted) out of their
>> inbox. There are also some third-party signatures[1] for ClamAV that catch
>> scam/phishing mail.
>
> There is info on Linux viruses here:
>
> http://en.wikipedia.org/wiki/Linux_malware
>
> I shouldn't be concerned about that?
>

The "big" risk (although still negligible) is that someone will mail 
your users an executable that does something bad. But, you would have to 
save it under /home, chmod +x it, and then run it manually for it to be 
dangerous.

If you use portage to install packages, you should not ever need to 
chmod +x anything. It's a big red flag and normal users don't even need 
to know how to do it.

Mount /home noexec for extra safety.

Note that antivirus wouldn't help anyway if your users are going to do 
whatever the email says without question =)

Re: [gentoo-user] clamav and spamassassin

[Michael Orlitzky]

On 12/03/2011 08:59 PM, Pandu Poluan wrote:
>
>
> This is new information to me. If you're subscribed to Gentoo-server,
> you'll know that I am in the process of setting up a mailfiltering
> gateway for my company.
>
> Any resources on this "postscreen" facility? sounds like a very nice
> thing to implement.
>
> Rgds,
>

Postscreen is just part of Postfix; it's a separate daemon added in the 
latest version.

This is the official README:

   http://www.postfix.org/POSTSCREEN_README.html

and the configuration parameters are documented in the usual place:

   http://www.postfix.org/postconf.5.html


Here's the entirety of my main.cf postscreen section for reference. I've 
deemed these safe, but you shouldn't enable them without reading what 
they do!


#
# Postscreen settings
#

postscreen_greet_action = enforce

postscreen_dnsbl_sites =
         psbl.surriel.com,
         bl.spamcop.net,
         zen.spamhaus.org,
         b.barracudacentral.org

postscreen_dnsbl_threshold = 1
postscreen_dnsbl_action = enforce


##
## Deep protocol tests
##

postscreen_pipelining_enable = yes
postscreen_pipelining_action = enforce

postscreen_non_smtp_command_enable = yes
postscreen_non_smtp_command_action = enforce

postscreen_bare_newline_enable = yes
postscreen_bare_newline_action = enforce

Re: [gentoo-user] clamav and spamassassin

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 1609 bytes --]

On Dec 4, 2011 9:21 AM, "Michael Orlitzky" <michael@orlitzky.com> wrote:
>
> On 12/03/2011 08:59 PM, Pandu Poluan wrote:
>>
>>
>>
>> This is new information to me. If you're subscribed to Gentoo-server,
>> you'll know that I am in the process of setting up a mailfiltering
>> gateway for my company.
>>
>> Any resources on this "postscreen" facility? sounds like a very nice
>> thing to implement.
>>
>> Rgds,
>>
>
> Postscreen is just part of Postfix; it's a separate daemon added in the
latest version.
>
> This is the official README:
>
>  http://www.postfix.org/POSTSCREEN_README.html
>
> and the configuration parameters are documented in the usual place:
>
>  http://www.postfix.org/postconf.5.html
>
>
> Here's the entirety of my main.cf postscreen section for reference. I've
deemed these safe, but you shouldn't enable them without reading what they
do!
>
>
> #
> # Postscreen settings
> #
>
> postscreen_greet_action = enforce
>
> postscreen_dnsbl_sites =
>        psbl.surriel.com,
>        bl.spamcop.net,
>        zen.spamhaus.org,
>        b.barracudacentral.org
>
> postscreen_dnsbl_threshold = 1
> postscreen_dnsbl_action = enforce
>
>
> ##
> ## Deep protocol tests
> ##
>
> postscreen_pipelining_enable = yes
> postscreen_pipelining_action = enforce
>
> postscreen_non_smtp_command_enable = yes
> postscreen_non_smtp_command_action = enforce
>
> postscreen_bare_newline_enable = yes
> postscreen_bare_newline_action = enforce
>

Thanks! Very helpful resources.

You mentioned amavisd-new. What's their relationship? I mean, if I deploy
postscreen, how will it affect amavisd-new?

TIA

Rgds,

[-- Attachment #2: Type: text/html, Size: 2572 bytes --]

Re: [gentoo-user] clamav and spamassassin

[Michael Orlitzky]

On 12/03/2011 09:48 PM, Pandu Poluan wrote:
>
>
> Thanks! Very helpful resources.
>
> You mentioned amavisd-new. What's their relationship? I mean, if I
> deploy postscreen, how will it affect amavisd-new?
>

Postscreen sits in front of smtpd, and handles all incoming connections. 
It hands the "good" connections off to the real smtpd daemon. 
Amavisd-new (in both before/after-queue configurations) interacts with 
the real smtpd, so postscreen doesn't directly affect it at all.

What was I talking about?

With amavisd-new, a before-queue filter is generally nicer, because you 
can reject spam, notifying the sender, rather than discarding it or 
backscattering. But, amavisd-new is a hog, and with a before-queue 
filter, an amavis process gets used every time ANY connection is made. 
Since 95% of your connections will be crap (that is a technical term), 
you waste tons of resources creating/killing amavisd-new processes for 
botnets and other scum that will be rejected quickly.

On a busy server, it will kill you.

Postscreen only passes the "good" connections to a real smtpd, so with 
postscreen running, new amavis processes only get used for those good 
connections. If postscreen can get reject 90% of the incoming 
connections, you'll use an order of magnitude less resources doing 
before-queue filtering than you would without postscreen.

So, in essence, postscreen is what allows you to run the before-queue 
filter with comparable resources to the after-queue filter.

Re: [gentoo-user] clamav and spamassassin

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 1694 bytes --]

On Dec 4, 2011 10:10 AM, "Michael Orlitzky" <michael@orlitzky.com> wrote:
>
> On 12/03/2011 09:48 PM, Pandu Poluan wrote:
>>
>>
>>
>> Thanks! Very helpful resources.
>>
>> You mentioned amavisd-new. What's their relationship? I mean, if I
>> deploy postscreen, how will it affect amavisd-new?
>>
>
> Postscreen sits in front of smtpd, and handles all incoming connections.
It hands the "good" connections off to the real smtpd daemon. Amavisd-new
(in both before/after-queue configurations) interacts with the real smtpd,
so postscreen doesn't directly affect it at all.
>
> What was I talking about?
>
> With amavisd-new, a before-queue filter is generally nicer, because you
can reject spam, notifying the sender, rather than discarding it or
backscattering. But, amavisd-new is a hog, and with a before-queue filter,
an amavis process gets used every time ANY connection is made. Since 95% of
your connections will be crap (that is a technical term), you waste tons of
resources creating/killing amavisd-new processes for botnets and other scum
that will be rejected quickly.
>
> On a busy server, it will kill you.
>
> Postscreen only passes the "good" connections to a real smtpd, so with
postscreen running, new amavis processes only get used for those good
connections. If postscreen can get reject 90% of the incoming connections,
you'll use an order of magnitude less resources doing before-queue
filtering than you would without postscreen.
>
> So, in essence, postscreen is what allows you to run the before-queue
filter with comparable resources to the after-queue filter.
>

Thanks for all the information. You really should write a wiki.g.o article
about the new setup :-)

Rgds,

[-- Attachment #2: Type: text/html, Size: 2034 bytes --]

Re: [gentoo-user] clamav and spamassassin

[Grant]

> Here's the entirety of my main.cf postscreen section for reference. I've
> deemed these safe, but you shouldn't enable them without reading what they
> do!
>
>
> #
> # Postscreen settings
> #
>
> postscreen_greet_action = enforce
>
> postscreen_dnsbl_sites =
>        psbl.surriel.com,
>        bl.spamcop.net,
>        zen.spamhaus.org,
>        b.barracudacentral.org
>
> postscreen_dnsbl_threshold = 1
> postscreen_dnsbl_action = enforce
>
>
> ##
> ## Deep protocol tests
> ##
>
> postscreen_pipelining_enable = yes
> postscreen_pipelining_action = enforce
>
> postscreen_non_smtp_command_enable = yes
> postscreen_non_smtp_command_action = enforce
>
> postscreen_bare_newline_enable = yes
> postscreen_bare_newline_action = enforce

I've looked up each of those parameters and they sound fine to me.
How long have you been running them?  Have you been notified of any
mistakenly rejected mail?  It's very important my server doesn't miss
any mail, even if it means dealing with more spam.

- Grant

Re: [gentoo-user] clamav and spamassassin

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 1461 bytes --]

On Dec 6, 2011 7:19 AM, "Grant" <emailgrant@gmail.com> wrote:
>
> > Here's the entirety of my main.cf postscreen section for reference. I've
> > deemed these safe, but you shouldn't enable them without reading what
they
> > do!
> >
> >
> > #
> > # Postscreen settings
> > #
> >
> > postscreen_greet_action = enforce
> >
> > postscreen_dnsbl_sites =
> >        psbl.surriel.com,
> >        bl.spamcop.net,
> >        zen.spamhaus.org,
> >        b.barracudacentral.org
> >
> > postscreen_dnsbl_threshold = 1
> > postscreen_dnsbl_action = enforce
> >
> >
> > ##
> > ## Deep protocol tests
> > ##
> >
> > postscreen_pipelining_enable = yes
> > postscreen_pipelining_action = enforce
> >
> > postscreen_non_smtp_command_enable = yes
> > postscreen_non_smtp_command_action = enforce
> >
> > postscreen_bare_newline_enable = yes
> > postscreen_bare_newline_action = enforce
>
> I've looked up each of those parameters and they sound fine to me.
> How long have you been running them?  Have you been notified of any
> mistakenly rejected mail?  It's very important my server doesn't miss
> any mail, even if it means dealing with more spam.
>

Similar situation with me. Because my company is in the financial sector,
false negatives are much more preferred than false positives.

(Although I can always weasel my way out of any problems caused by slight
configuration mistakes, I prefer not having to put myself into a situation
where weasel-ing is needed :-)

Rgds,

[-- Attachment #2: Type: text/html, Size: 2207 bytes --]

Re: [gentoo-user] clamav and spamassassin

[Michael Orlitzky]

On 12/05/2011 07:45 PM, Pandu Poluan wrote:
>
>  >
>  > I've looked up each of those parameters and they sound fine to me.
>  > How long have you been running them?  Have you been notified of any
>  > mistakenly rejected mail?  It's very important my server doesn't miss
>  > any mail, even if it means dealing with more spam.
>  >
>
> Similar situation with me. Because my company is in the financial
> sector, false negatives are much more preferred than false positives.
>

I have never had a false positive report that I traced back to one of 
the postscreen deep protocol tests.

That being said, they've only been in place for ~4 months.

Re: [gentoo-user] clamav and spamassassin

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

On Dec 6, 2011 7:58 AM, "Michael Orlitzky" <michael@orlitzky.com> wrote:
>
> On 12/05/2011 07:45 PM, Pandu Poluan wrote:
>>
>>
>>  >
>>  > I've looked up each of those parameters and they sound fine to me.
>>  > How long have you been running them?  Have you been notified of any
>>  > mistakenly rejected mail?  It's very important my server doesn't miss
>>  > any mail, even if it means dealing with more spam.
>>  >
>>
>> Similar situation with me. Because my company is in the financial
>> sector, false negatives are much more preferred than false positives.
>>
>
> I have never had a false positive report that I traced back to one of the
postscreen deep protocol tests.
>
> That being said, they've only been in place for ~4 months.
>

Four months without a false positive? Good enough for me. Where do I sign?
:-)

Rgds,

[-- Attachment #2: Type: text/html, Size: 1152 bytes --]

Re: [gentoo-user] clamav and spamassassin

[Michael Orlitzky]

On 12/05/2011 08:01 PM, Pandu Poluan wrote:
>
>
> Four months without a false positive? Good enough for me. Where do I
> sign? :-)
>

main.cf

=)

Re: [gentoo-user] clamav and spamassassin

[Grant]

>>  > I've looked up each of those parameters and they sound fine to me.
>>  > How long have you been running them?  Have you been notified of any
>>  > mistakenly rejected mail?  It's very important my server doesn't miss
>>  > any mail, even if it means dealing with more spam.
>>  >
>>
>> Similar situation with me. Because my company is in the financial
>> sector, false negatives are much more preferred than false positives.
>>
>
> I have never had a false positive report that I traced back to one of the
> postscreen deep protocol tests.
>
> That being said, they've only been in place for ~4 months.

What about trouble with the DNSBL lists?  I know when I changed my IP
address I had to work to get the new one removed from a few blacklists
it had previously been placed on.  I wasn't sending spam, but my
messages would have been blocked under that config if I hadn't done
the work to get the IP off the lists.

- Grant

Re: [gentoo-user] clamav and spamassassin

[Michael Orlitzky]

On 12/05/2011 10:24 PM, Grant wrote:
>
> What about trouble with the DNSBL lists?  I know when I changed my IP
> address I had to work to get the new one removed from a few blacklists
> it had previously been placed on.  I wasn't sending spam, but my
> messages would have been blocked under that config if I hadn't done
> the work to get the IP off the lists.
>
> - Grant
>

We do get false positives from the blacklists on rare occasion, but 
they're the same ones we got before postscreen.

Before postscreen, we had,

   smtpd_recipient_restrictions =
	permit_mynetworks,
         ...
         reject_rbl_client psbl.surriel.com,
  	reject_rbl_client bl.spamcop.net,
  	reject_rbl_client zen.spamhaus.org,
         reject_rbl_client b.barracudacentral.org,
  	permit

After postscreen, we have,

   smtpd_recipient_restrictions =
	permit_mynetworks,
         ...
  	permit

   postscreen_dnsbl_sites =
         psbl.surriel.com,
         bl.spamcop.net,
         zen.spamhaus.org,
         b.barracudacentral.org

The two should be more or less equivalent considering that 
postscreen_dnsbl_threshold = 1. (I should mention that you have to 
register with barracuda before using their list.)

Re: [gentoo-user] clamav and spamassassin

[Grant]

>> What about trouble with the DNSBL lists?  I know when I changed my IP
>> address I had to work to get the new one removed from a few blacklists
>> it had previously been placed on.  I wasn't sending spam, but my
>> messages would have been blocked under that config if I hadn't done
>> the work to get the IP off the lists.
>>
>> - Grant
>>
>
> We do get false positives from the blacklists on rare occasion, but they're
> the same ones we got before postscreen.
>
> Before postscreen, we had,
>
>  smtpd_recipient_restrictions =
>        permit_mynetworks,
>        ...
>        reject_rbl_client psbl.surriel.com,
>        reject_rbl_client bl.spamcop.net,
>        reject_rbl_client zen.spamhaus.org,
>        reject_rbl_client b.barracudacentral.org,
>        permit
>
> After postscreen, we have,
>
>  smtpd_recipient_restrictions =
>        permit_mynetworks,
>        ...
>        permit
>
>
>  postscreen_dnsbl_sites =
>        psbl.surriel.com,
>        bl.spamcop.net,
>        zen.spamhaus.org,
>        b.barracudacentral.org
>
> The two should be more or less equivalent considering that
> postscreen_dnsbl_threshold = 1. (I should mention that you have to register
> with barracuda before using their list.)

Got it.  Your explanations are positively lucid.

I added this to /etc/postifx/main.cf:

postscreen_greet_action = enforce
postscreen_pipelining_enable = yes
postscreen_pipelining_action = enforce
postscreen_non_smtp_command_enable = yes
postscreen_non_smtp_command_action = enforce
postscreen_bare_newline_enable = yes
postscreen_bare_newline_action = enforce

and I commented this and restarted postfix:

#check_policy_service inet:127.0.0.1:10030

Should this effectively disable postgrey and enable postscreen?

- Grant

Re: [gentoo-user] clamav and spamassassin

[Michael Orlitzky]

On 12/06/11 11:32, Grant wrote:
> 
> Got it.  Your explanations are positively lucid.
> 
> I added this to /etc/postifx/main.cf:
> 
> postscreen_greet_action = enforce
> postscreen_pipelining_enable = yes
> postscreen_pipelining_action = enforce
> postscreen_non_smtp_command_enable = yes
> postscreen_non_smtp_command_action = enforce
> postscreen_bare_newline_enable = yes
> postscreen_bare_newline_action = enforce
> 
> and I commented this and restarted postfix:
> 
> #check_policy_service inet:127.0.0.1:10030
> 
> Should this effectively disable postgrey and enable postscreen?
> 

That will disable postgrey, but isn't enough to enable postscreen. There
are a couple of daemons you have to enable in master.cf (steps 2 through 6):

  http://www.postfix.org/POSTSCREEN_README.html#enable

That README refers to lines that are commented-out in master.cf; of
course, if you've upgraded from an earlier of postfix, you won't have them.

What I did was to untar the latest postfix release under my home
directory, and find the master.cf that ships with it. Then, I
copy/pasted the lines mentioned in the README over to my real master.cf.

After a restart, you should see lines like this in your mail log:

  Dec  6 03:13:46 mx1 postfix/postscreen[2810]: CONNECT from ...

that let you know its' working.

Re: [gentoo-user] clamav and spamassassin

[Paul Hartman]

On Tue, Dec 6, 2011 at 11:11 AM, Michael Orlitzky <michael@orlitzky.com> wrote:
> On 12/06/11 11:32, Grant wrote:
>>
>> Got it.  Your explanations are positively lucid.
>>
>> I added this to /etc/postifx/main.cf:
>>
>> postscreen_greet_action = enforce
>> postscreen_pipelining_enable = yes
>> postscreen_pipelining_action = enforce
>> postscreen_non_smtp_command_enable = yes
>> postscreen_non_smtp_command_action = enforce
>> postscreen_bare_newline_enable = yes
>> postscreen_bare_newline_action = enforce
>>
>> and I commented this and restarted postfix:
>>
>> #check_policy_service inet:127.0.0.1:10030
>>
>> Should this effectively disable postgrey and enable postscreen?
>>
>
> That will disable postgrey, but isn't enough to enable postscreen. There
> are a couple of daemons you have to enable in master.cf (steps 2 through 6):
>
>  http://www.postfix.org/POSTSCREEN_README.html#enable
>
> That README refers to lines that are commented-out in master.cf; of
> course, if you've upgraded from an earlier of postfix, you won't have them.
>
> What I did was to untar the latest postfix release under my home
> directory, and find the master.cf that ships with it. Then, I
> copy/pasted the lines mentioned in the README over to my real master.cf.
>
> After a restart, you should see lines like this in your mail log:
>
>  Dec  6 03:13:46 mx1 postfix/postscreen[2810]: CONNECT from ...
>
> that let you know its' working.

Thanks for bringing up postscreen and the rest of your responses to
Grant in this thread, I wasn't aware of it either. None of the HOWTOs
I read ever mentioned it. :) I'm going to give it a try and see how it
goes.

Re: [gentoo-user] clamav and spamassassin

[Grant]

>> Got it.  Your explanations are positively lucid.
>>
>> I added this to /etc/postifx/main.cf:
>>
>> postscreen_greet_action = enforce
>> postscreen_pipelining_enable = yes
>> postscreen_pipelining_action = enforce
>> postscreen_non_smtp_command_enable = yes
>> postscreen_non_smtp_command_action = enforce
>> postscreen_bare_newline_enable = yes
>> postscreen_bare_newline_action = enforce
>>
>> and I commented this and restarted postfix:
>>
>> #check_policy_service inet:127.0.0.1:10030
>>
>> Should this effectively disable postgrey and enable postscreen?
>>
>
> That will disable postgrey, but isn't enough to enable postscreen. There
> are a couple of daemons you have to enable in master.cf (steps 2 through 6):
>
>  http://www.postfix.org/POSTSCREEN_README.html#enable
>
> That README refers to lines that are commented-out in master.cf; of
> course, if you've upgraded from an earlier of postfix, you won't have them.
>
> What I did was to untar the latest postfix release under my home
> directory, and find the master.cf that ships with it. Then, I
> copy/pasted the lines mentioned in the README over to my real master.cf.
>
> After a restart, you should see lines like this in your mail log:
>
>  Dec  6 03:13:46 mx1 postfix/postscreen[2810]: CONNECT from ...
>
> that let you know its' working.

Do you know how smtps comes into play?  Right now I've got the
following uncommented in master.cf:

smtp      inet  n       -       n       -       -       smtpd
smtps     inet  n       -       n       -       -       smtpd
  -o smtpd_tls_wrappermode=yes

Should I write an smtpsd line or does tlsproxy make that unnecessary?

- Grant

Re: [gentoo-user] clamav and spamassassin

[Michael Orlitzky]

On 12/06/2011 04:34 PM, Grant wrote:
>
> Do you know how smtps comes into play?  Right now I've got the
> following uncommented in master.cf:
>
> smtp      inet  n       -       n       -       -       smtpd
> smtps     inet  n       -       n       -       -       smtpd
>    -o smtpd_tls_wrappermode=yes
>
> Should I write an smtpsd line or does tlsproxy make that unnecessary?

SMTPS is deprecated. You probably don't need it at all, unless you do. 
Some older (Microsoft...) clients can't use anything else for encryption.

These days, the "proper" way to secure your users' connections is with 
TLS on the submission port, 587. You should also have a commented-out 
'submission' line in your master.cf; that's what it's for.

The idea is that you can force encryption on port 587, and have your 
users connect there instead of port 25. Then, the only restriction you 
need for those connections is that the username/password be correct. The 
rest of the mail comes in on port 25, unencrypted, as usual, and is 
subjected to your anti-spam checks.

If you're using either SMTPS or the submission service, you don't need 
to change them. Your users will continue to connect to port 465 (smtps) 
or 587 (submission), bypassing postscreen entirely.

If you're not using the submission service, i.e. both external and 
user-submitted mail come in on port 25, then you'll probably want to 
exempt your users from the postscreen restrictions:

   http://www.postfix.org/postconf.5.html#postscreen_access_list

but you should really be using the submission port!

Re: [gentoo-user] clamav and spamassassin

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 2111 bytes --]

On Dec 7, 2011 2:22 AM, "Paul Hartman" <paul.hartman+gentoo@gmail.com>
wrote:
>
> On Tue, Dec 6, 2011 at 11:11 AM, Michael Orlitzky <michael@orlitzky.com>
wrote:
> > On 12/06/11 11:32, Grant wrote:
> >>
> >> Got it.  Your explanations are positively lucid.
> >>
> >> I added this to /etc/postifx/main.cf:
> >>
> >> postscreen_greet_action = enforce
> >> postscreen_pipelining_enable = yes
> >> postscreen_pipelining_action = enforce
> >> postscreen_non_smtp_command_enable = yes
> >> postscreen_non_smtp_command_action = enforce
> >> postscreen_bare_newline_enable = yes
> >> postscreen_bare_newline_action = enforce
> >>
> >> and I commented this and restarted postfix:
> >>
> >> #check_policy_service inet:127.0.0.1:10030
> >>
> >> Should this effectively disable postgrey and enable postscreen?
> >>
> >
> > That will disable postgrey, but isn't enough to enable postscreen. There
> > are a couple of daemons you have to enable in master.cf (steps 2
through 6):
> >
> >  http://www.postfix.org/POSTSCREEN_README.html#enable
> >
> > That README refers to lines that are commented-out in master.cf; of
> > course, if you've upgraded from an earlier of postfix, you won't have
them.
> >
> > What I did was to untar the latest postfix release under my home
> > directory, and find the master.cf that ships with it. Then, I
> > copy/pasted the lines mentioned in the README over to my real master.cf.
> >
> > After a restart, you should see lines like this in your mail log:
> >
> >  Dec  6 03:13:46 mx1 postfix/postscreen[2810]: CONNECT from ...
> >
> > that let you know its' working.
>
> Thanks for bringing up postscreen and the rest of your responses to
> Grant in this thread, I wasn't aware of it either. None of the HOWTOs
> I read ever mentioned it. :) I'm going to give it a try and see how it
> goes.
>

Indeed. They are also unclear on how to configure SASL (but that's a
different story).

Luckily, I'm building my mailfiltering gateway from scratch, and have been
logging everything I do. When everything's finished and the mfgw works
well, I'll distill my log into yet-another-wiki-article.

Rgds,

[-- Attachment #2: Type: text/html, Size: 3111 bytes --]

Re: [gentoo-user] clamav and spamassassin

[Grant]

> That will disable postgrey, but isn't enough to enable postscreen. There
> are a couple of daemons you have to enable in master.cf (steps 2 through 6):
>
>  http://www.postfix.org/POSTSCREEN_README.html#enable
>
> That README refers to lines that are commented-out in master.cf; of
> course, if you've upgraded from an earlier of postfix, you won't have them.

Don't you let etc-update add them for you?

> What I did was to untar the latest postfix release under my home
> directory, and find the master.cf that ships with it. Then, I
> copy/pasted the lines mentioned in the README over to my real master.cf.
>
> After a restart, you should see lines like this in your mail log:
>
>  Dec  6 03:13:46 mx1 postfix/postscreen[2810]: CONNECT from ...
>
> that let you know its' working.

Working now, thanks a lot.  I should only need the tlsproxy line if my
users connect to port 25 to send mail, correct?

- Grant

Re: [gentoo-user] clamav and spamassassin

[Grant]

> SMTPS is deprecated. You probably don't need it at all, unless you do. Some
> older (Microsoft...) clients can't use anything else for encryption.
>
> These days, the "proper" way to secure your users' connections is with TLS
> on the submission port, 587. You should also have a commented-out
> 'submission' line in your master.cf; that's what it's for.
>
> The idea is that you can force encryption on port 587, and have your users
> connect there instead of port 25. Then, the only restriction you need for
> those connections is that the username/password be correct. The rest of the
> mail comes in on port 25, unencrypted, as usual, and is subjected to your
> anti-spam checks.
>
> If you're using either SMTPS or the submission service, you don't need to
> change them. Your users will continue to connect to port 465 (smtps) or 587
> (submission), bypassing postscreen entirely.
>
> If you're not using the submission service, i.e. both external and
> user-submitted mail come in on port 25, then you'll probably want to exempt
> your users from the postscreen restrictions:
>
>  http://www.postfix.org/postconf.5.html#postscreen_access_list
>
> but you should really be using the submission port!

Aye aye.  Should I make the change like this:

#smtps     inet  n       -       n       -       -       smtpd
#  -o smtpd_tls_wrappermode=yes
submission inet n       -       n       -       -       smtpd
  -o smtpd_tls_security_level=encrypt
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING

And then switch my clients from port 465 to 587?

- Grant

Re: [gentoo-user] clamav and spamassassin

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]

On Dec 7, 2011 8:01 AM, "Grant" <emailgrant@gmail.com> wrote:
>
> > That will disable postgrey, but isn't enough to enable postscreen. There
> > are a couple of daemons you have to enable in master.cf (steps 2
through 6):
> >
> >  http://www.postfix.org/POSTSCREEN_README.html#enable
> >
> > That README refers to lines that are commented-out in master.cf; of
> > course, if you've upgraded from an earlier of postfix, you won't have
them.
>
> Don't you let etc-update add them for you?
>
> > What I did was to untar the latest postfix release under my home
> > directory, and find the master.cf that ships with it. Then, I
> > copy/pasted the lines mentioned in the README over to my real master.cf.
> >
> > After a restart, you should see lines like this in your mail log:
> >
> >  Dec  6 03:13:46 mx1 postfix/postscreen[2810]: CONNECT from ...
> >
> > that let you know its' working.
>
> Working now, thanks a lot.  I should only need the tlsproxy line if my
> users connect to port 25 to send mail, correct?
>

I've perused the relevant documentation, and to my knowledge you need to
enable tlsproxy if you want to use TLS, be it through port 25 or 587.

Don't forget to test it using openssl s_client.

Rgds,

[-- Attachment #2: Type: text/html, Size: 1778 bytes --]

Re: [gentoo-user] clamav and spamassassin

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 134 bytes --]

Michael, after I configured postscreen, how do I test it?

I tried doing out of turn talking but it didn't seem to block me...

Rgds,

[-- Attachment #2: Type: text/html, Size: 165 bytes --]

Re: [gentoo-user] clamav and spamassassin

[Grant]

> Michael, after I configured postscreen, how do I test it?
>
> I tried doing out of turn talking but it didn't seem to block me...

Are you getting lines like this in your mail log:

Dec  6 03:13:46 mx1 postfix/postscreen[2810]: CONNECT from ...

- Grant

Re: [gentoo-user] clamav and spamassassin

[Michael Orlitzky]

On 12/06/11 19:57, Grant wrote:
>> That will disable postgrey, but isn't enough to enable postscreen. There
>> are a couple of daemons you have to enable in master.cf (steps 2 through 6):
>>
>>  http://www.postfix.org/POSTSCREEN_README.html#enable
>>
>> That README refers to lines that are commented-out in master.cf; of
>> course, if you've upgraded from an earlier of postfix, you won't have them.
> 
> Don't you let etc-update add them for you?

Well, etc-update offers to overwrite the old one with the new, but that
would be bad since we have a few custom services. I do try to patch the
new comments into my configuration files when possible, but my master.cf
is so far away from upstream's that the patch file is basically,

 - Everything old
 + Everything new

These days I'm almost ready to claim that I actually understand how
postfix works, so I'm not afraid to maintain main.cf and master.cf by
hand anymore.


> Working now, thanks a lot.  I should only need the tlsproxy line if my
> users connect to port 25 to send mail, correct?

You should enable it anyway: many remote MTAs will use encryption if you
let them.

Re: [gentoo-user] clamav and spamassassin

[Michael Orlitzky]

On 12/06/11 20:02, Grant wrote:
> 
> Aye aye.  Should I make the change like this:
> 
> #smtps     inet  n       -       n       -       -       smtpd
> #  -o smtpd_tls_wrappermode=yes
> submission inet n       -       n       -       -       smtpd
>   -o smtpd_tls_security_level=encrypt
> #  -o smtpd_sasl_auth_enable=yes
> #  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
> #  -o milter_macro_daemon_name=ORIGINATING
> 
> And then switch my clients from port 465 to 587?
> 
> - Grant
> 

Yup, but be sure to uncomment the rest of the -o lines.

Depending on which mail clients you use, you may have to fiddle with the
"secure connection" setting. Some of them allow you to choose between
SSL and TLS (ignoring that the distinction is ambiguous). You'll want to
set them to (START)TLS if you have the option.

Re: [gentoo-user] clamav and spamassassin

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 446 bytes --]

On Dec 7, 2011 11:05 PM, "Grant" <emailgrant@gmail.com> wrote:
>
> > Michael, after I configured postscreen, how do I test it?
> >
> > I tried doing out of turn talking but it didn't seem to block me...
>
> Are you getting lines like this in your mail log:
>
> Dec  6 03:13:46 mx1 postfix/postscreen[2810]: CONNECT from ...
>

No... but then I realize I've been testing from a host that's part of
$my_networks >.<

It indeed works now :-)

Rgds,

[-- Attachment #2: Type: text/html, Size: 646 bytes --]

Re: [gentoo-user] clamav and spamassassin

[Grant]

>>> That will disable postgrey, but isn't enough to enable postscreen. There
>>> are a couple of daemons you have to enable in master.cf (steps 2 through 6):
>>>
>>>  http://www.postfix.org/POSTSCREEN_README.html#enable
>>>
>>> That README refers to lines that are commented-out in master.cf; of
>>> course, if you've upgraded from an earlier of postfix, you won't have them.
>>
>> Don't you let etc-update add them for you?
>
> Well, etc-update offers to overwrite the old one with the new, but that
> would be bad since we have a few custom services. I do try to patch the
> new comments into my configuration files when possible, but my master.cf
> is so far away from upstream's that the patch file is basically,
>
>  - Everything old
>  + Everything new

Yeah, I try to keep mine as close to default as possible (comments and
all) so etc-update does an easy "interactive" merge.

- Grant


> These days I'm almost ready to claim that I actually understand how
> postfix works, so I'm not afraid to maintain main.cf and master.cf by
> hand anymore.
>
>
>> Working now, thanks a lot.  I should only need the tlsproxy line if my
>> users connect to port 25 to send mail, correct?
>
> You should enable it anyway: many remote MTAs will use encryption if you
> let them.

Re: [gentoo-user] clamav and spamassassin

[Grant]

>> Aye aye.  Should I make the change like this:
>>
>> #smtps     inet  n       -       n       -       -       smtpd
>> #  -o smtpd_tls_wrappermode=yes
>> submission inet n       -       n       -       -       smtpd
>>   -o smtpd_tls_security_level=encrypt
>> #  -o smtpd_sasl_auth_enable=yes
>> #  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
>> #  -o milter_macro_daemon_name=ORIGINATING
>>
>> And then switch my clients from port 465 to 587?
>>
>> - Grant
>>
>
> Yup, but be sure to uncomment the rest of the -o lines.

Are you sure?  I was using smtps like this:

smtps     inet  n       -       n       -       -       smtpd
  -o smtpd_tls_wrappermode=yes
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING

but I should switch to the below?

submission inet n       -       n       -       -       smtpd
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING

- Grant

Re: [gentoo-user] clamav and spamassassin

[Michael Orlitzky]

On 12/07/11 13:16, Grant wrote:
> 
> Are you sure?  I was using smtps like this:
> 
> smtps     inet  n       -       n       -       -       smtpd
>   -o smtpd_tls_wrappermode=yes
> #  -o smtpd_sasl_auth_enable=yes
> #  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
> #  -o milter_macro_daemon_name=ORIGINATING
> 
> but I should switch to the below?

Are all of your clients in mynetworks? If so, it doesn't really matter
unless you want to prevent your own users from forging the envelope
sender or "From:" address.

This would enable SASL:

>   -o smtpd_sasl_auth_enable=yes


This would allow authenticated users to relay, and reject everything else:

>   -o smtpd_client_restrictions=permit_sasl_authenticated,reject


And this does nothing unless you use a filter and want to distinguish
between incoming and outgoing mail:

>   -o milter_macro_daemon_name=ORIGINATING

Re: [gentoo-user] clamav and spamassassin

[Michael Orlitzky]

On 12/07/11 13:56, Michael Orlitzky wrote:
> 
> Are all of your clients in mynetworks? If so, it doesn't really matter
> unless you want to prevent your own users from forging the envelope
> sender or "From:" address.
> 

Whoops, correction: you can still forge the "From:" header with
reject_authenticated_sender_login_mismatch.

Re: [gentoo-user] clamav and spamassassin

[Grant]

>> Are you sure?  I was using smtps like this:
>>
>> smtps     inet  n       -       n       -       -       smtpd
>>   -o smtpd_tls_wrappermode=yes
>> #  -o smtpd_sasl_auth_enable=yes
>> #  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
>> #  -o milter_macro_daemon_name=ORIGINATING
>>
>> but I should switch to the below?
>
> Are all of your clients in mynetworks? If so, it doesn't really matter
> unless you want to prevent your own users from forging the envelope
> sender or "From:" address.
>
> This would enable SASL:
>
>>   -o smtpd_sasl_auth_enable=yes
>
>
> This would allow authenticated users to relay, and reject everything else:
>
>>   -o smtpd_client_restrictions=permit_sasl_authenticated,reject
>
>
> And this does nothing unless you use a filter and want to distinguish
> between incoming and outgoing mail:
>
>>   -o milter_macro_daemon_name=ORIGINATING

Thanks a lot Michael.  Much appreciated.

- Grant