Can't get authentication to my Dovecot IMAP to work

Hi, Brian.

Brian Carroll wrote:
>
> Heya Maia Mailguard Users and Devs!
>
>  
>
> I have a nice little ISP-style build:
>
>  
>
> CentOS 5
>
> postfix-2.3.3-2
>
> php-5.1.6-15.el5
>
> dovecot-1.0.9-0_65.el5
>
> Postfixadmin (maybe not the latest…got it from SVN in
December)
>
> Squirrelmail 1.4.13
>
> Maia Mailguard 1.0.2a
>
    I am currently using a setup much like this on FreeBSD.

>  
>
> When I use amavisd-new it all works, but of course
there is no
> quarantine management/spam setting control so I want to
deploy Maia
> Mailguard. I have gone through and followed the install
instructions
> and think I am very close...but…
>
>  
>
> 1.  I cannot get it to log me in at all. I figured to
use the Dovecot
> IMAP server since it is already working against the
Postfix database
> (why re-invent the wheel?) but I can’t seem to make
this work. The
> Squirrelmail auths users in the same manner, which
works just fine and
> clients are using this mail (i.e. their MUA’s are
working against it
> just fine) server so I know my base setup is good. Maia
is the last
> piece of my little puzzle…
>
>  
>
>  I am using the setup as shown in the “address
re-writing” document
> (http
://www.maiamailguard.org/maia/wiki/Addresses and the
README
> :Postfix files) to hand the email to amavisd-maia
without being
> re-written, and consequently “$address_rewriting_type
= 0”. All emails
> appear in /var/log/maillog as ‘userdomain.tld’. But it just won’t do
> it. The answer is “NO, Authentication failed.” I
have tried with and
> without SSL, I have tried POP3 (also served by Dovecot
of course). I
> have tried sql auth pointing it to my Postfixadmin
database and using
> the same value for “user name” and “user email
address” as
> Postfixadmin uses them as one and the same.  I have
looked through
> this mail lists archives and found people asking the
question, but no
> definitive answer except the address rewriting thing.
Any help would
> be greatly appreciated.
>
    Well, this shouldn't be an error in the Dovecot
configuration at all
if users are able to authenticate. My guess is that your
'address-rewrite' configuration option in the Maia-Mailguard
config.inc.php file should be set to '4' and not '0'. This
will use the
full email address for the authentication. Like I said, I
have a setup
very similar to this on FreeBSD and I have my
'address-rewrite' set to
'4' and all works swimmingly. If you'd like, you can see the
Maia-Mailguard installation how-to for FreeBSD that I wrote
by visiting
http://www.purple
hat.org/?page_id=4 and browse to the 'Maia-Mailguard
Install' page. It will show you the configuration that I am
successfully
using which is currently SQL Authentication via the MySQL
socket (Seems
safer to me). But, it works so check it out and see if it
helps.

>  
>
> 2. It doesn’t seem to be able to pick up on the GTUBE
spam test. It
> delivers it when I expect it to quarantine it.
Obviously from #1 above
> I cannot log in and set my personal spam prefs, so I am
assuming it
> will use the defaults from amavisd.conf, which I have
tightened up a
> bit as follows:
>
>  
>
> $sa_tag_level_deflt  = 2.0; # add spam info headers if
at, or above
> that level
>
> $sa_tag2_level_deflt = 4.2;  # add 'spam detected'
headers at that level
>
> $sa_kill_level_deflt = $sa_tag2_level_deflt;  #
triggers spam evasive
> actions
>
> $sa_dsn_cutoff_level = 8;   # spam level beyond which a
DSN is not sent
>
>  
>
> Note that my amavisd-new picks up the GTUBE test every
time.
>
>  
>
> I have tried this with the default values also, it
still delivers the
> GTUBE as clean mail.
>
>  
>
> I did also re-import my SA rules to make sure they were
in play (well,
> as sure as I know how to be…)
>
    I'm assuming this will be fixed as soon as you log in
and make a few
adjustments. Also, as Maia-Mailguard learns it should be
blocked without
an issue at all.

>  
>
> 3. How do I configure amavisd-maia to just DROP
anything identified as
> a virus without quarantining it? Frankly, I trust Clam
AV a LOT more
> than I trust my users not to do something really
stupid. Can I maybe
> just have anything id’d as a virus put in the
quarantine directory
> where I might find it but my users have no access to
it? I really
> don’t want any users to have any chance to do
something silly with a
> virus. I got enough trouble without adding to them by
giving them any
> view into something Clam says is infected….
>
    This, however, is easily done by setting the values in
the web
interface once you've logged in. Each domain inherits the
settings from
the Default Domain (.). So,  just set the default domain's
'Virus
Scanning' to 'Enabled' and the 'Detected viruses should
be...' to
'Discarded'. Any email labeled as containing a virus will be
silently
deleted.

>  
>
> Regards, and TIA!
>
>  
>
> Brian Carroll
>
    I hope this all helps!

Regards,
Janky Jay, III

>  
>
>  
>
>  
>
>
------------------------------------------------------------
------------
>
> _______________________________________________
> Maia-users mailing list
> Maia-usersrenaissoft.com
> http://www.renaissoft.com/mailman/listinfo/maia-users
>   

_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Feb 13, 2008, at 12:51 AM, Brian Carroll wrote:
>
> 1.  I cannot get it to log me in at all. I figured to
use the  
> Dovecot IMAP server since it is already working against
the
...
>  Postfixadmin uses

Use address_rewriting_type = 4 - it needs the full email
address as a  
login.

> 2. It doesn$B!G(Bt seem to be able to pick up on the
GTUBE spam test. It  
> delivers it when I expect it to quarantine it.
Obviously from #1  
> above I cannot log in and set my personal spam prefs,
so I am  
> assuming it will use the defaults from amavisd.conf,
which I have  
> tightened up a bit as follows:

No, you can't use amavisd.conf - the settings in sql
override them.   
The default settings (for catch all domain .) are
set very  
permissive, with only virus filtering enabled.  This allow
you to  
install Maia into a live mail stream without causing any
sudden  
changes to the end user.  (Can you believe I got complaints
the first  
time I put a spam blocker in the mail stream?)
Then you can test with a small group of accounts or domains,
or  
activate accounts gradually.

> 3. How do I configure amavisd-maia to just DROP
anything identified  
> as a virus without quarantining it? Frankly, I trust
Clam AV a LOT  
> more than I trust my users not to do something really
stupid. Can I  
> maybe just have anything id$B!G(Bd as a virus put in
the quarantine  
> directory where I might find it but my users have no
access to it? I  
> really don$B!G(Bt want any users to have any chance
to do something silly  
> with a virus. I got enough trouble without adding to
them by giving  
> them any view into something Clam says is
infected$B!D(B.


Well, you can set the final destiny in amavisd.conf to
D_DROP, but I  
highly advise against it.  Despite your distrust of your end
users, I  
have never heard of anyone releasing a virus accidentally,
and I  
*have* heard of a few false positives by clamav.  The whole
point of  
Maia is to give the end user the power to help train and to
rescue  
false positives.

David Morton
Maia Mailguard http://www.maiamailguard
.com
mortondadgrmm.net



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFHswiQUy30ODPkzl0RAk3tAJ4r6I3l+tLoqrmzSm4lt4EI6MY2LgCf
aOc0
Xkrnn5gyV4kN/t6/S+y2WCg=
=KoWc
-----END PGP SIGNATURE-----
_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users

Heya All,

Would you happen to know why I would get a blank page after
the login?
"welcome.php" is blank...

I have looked at this page
(http
://www.maiamailguard.com/maia/wiki/BlankPage) and made
sure my
permissions on 'themes/*/complied' are as specified.
'Apache" is in the
'amavis' group (This is CentOS so my www user is 'Apache').

I have looked at the Templates setup
(http://www.maiamailguard.com/maia/wiki/TemplatePermiss
ions) and
verified I have created a 'webfilter.conf' in
/etc/httpd/conf.d/ which
looks like (my maia is installed at
/var/www/html/webfilter):


Alias /webfilter "/var/www/html/webfilter"

<Directory "/var/amavis/maia/templates/">
    Order allow,deny
    Allow from all
</Directory>


I also have verified that the user 'amavis' has the correct
rights
there:

drwxr-xr-x 2 amavis amavis 4096 Feb  7 21:57 scripts
drwxr-xr-x 2 amavis amavis 4096 Feb  7 21:58 templates

and in the 'Templates" dir itself:

-rw-r--r-- 1 amavis amavis 2428 Feb  7 21:58 digest.tpl
-rw-r--r-- 1 amavis amavis  857 Feb  7 21:58 newuser.tpl
-rw-r--r-- 1 amavis amavis  812 Feb  7 21:58 reminder.tpl

I do see 4 files like
'%%46^463^463266CC%%login_head.tpl.php' in the
theme 'ocean_surf/compiled' directory, but the other two
default theme
dirs are blank. I did try 'chmod 777 themes/*/compiled' to
no avail.

SELinux and 'Security Level' are disabled and verified by
the
'system-config-securitylevel' command.

I have no errors in /var/log/php_errors.

I have no errors in /var/log/httpd/error_log.

I was seeing:

[Wed Feb 13 21:06:25 2008] [error] [client ::1] Directory
index
forbidden by Options directive: /var/www/html/

But those seem to have gone away since I created the
'/etc/httpd/conf.d/webfilter.conf' file.

On the bright side, I did get the login to accept my
credentials and I
thank you very much for that!

Regards,

Brian Carroll
_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users

Hello, Brian.


Brian Carroll wrote:
> Heya All,
>
> Would you happen to know why I would get a blank page
after the login?
> "welcome.php" is blank...
>   

    When you visit your
'http(s)://www.domain.tld/maia-mailguard/configtest.php',
what does it
say? Is there anything missing? If so, what?

> I have looked at this page
> (http
://www.maiamailguard.com/maia/wiki/BlankPage) and made
sure my
> permissions on 'themes/*/complied' are as specified.
'Apache" is in the
> 'amavis' group (This is CentOS so my www user is
'Apache').
>
> I have looked at the Templates setup
> (http://www.maiamailguard.com/maia/wiki/TemplatePermiss
ions) and
> verified I have created a 'webfilter.conf' in
/etc/httpd/conf.d/ which
> looks like (my maia is installed at
/var/www/html/webfilter):
>
>
> Alias /webfilter "/var/www/html/webfilter"
>
> <Directory
"/var/amavis/maia/templates/">
>     Order allow,deny
>     Allow from all
> </Directory>
>
>
> I also have verified that the user 'amavis' has the
correct rights
> there:
>
> drwxr-xr-x 2 amavis amavis 4096 Feb  7 21:57 scripts
> drwxr-xr-x 2 amavis amavis 4096 Feb  7 21:58 templates
>
> and in the 'Templates" dir itself:
>
> -rw-r--r-- 1 amavis amavis 2428 Feb  7 21:58
digest.tpl
> -rw-r--r-- 1 amavis amavis  857 Feb  7 21:58
newuser.tpl
> -rw-r--r-- 1 amavis amavis  812 Feb  7 21:58
reminder.tpl
>
> I do see 4 files like
'%%46^463^463266CC%%login_head.tpl.php' in the
> theme 'ocean_surf/compiled' directory, but the other
two default theme
> dirs are blank. I did try 'chmod 777 themes/*/compiled'
to no avail.
>
> SELinux and 'Security Level' are disabled and verified
by the
> 'system-config-securitylevel' command.
>
> I have no errors in /var/log/php_errors.
>
> I have no errors in /var/log/httpd/error_log.
>
> I was seeing:
>
> [Wed Feb 13 21:06:25 2008] [error] [client ::1]
Directory index
> forbidden by Options directive: /var/www/html/
>
> But those seem to have gone away since I created the
> '/etc/httpd/conf.d/webfilter.conf' file.
>
> On the bright side, I did get the login to accept my
credentials and I
> thank you very much for that!
>   

    Ah. Excellent. Glad to see authentication is a go.

> Regards,
>
> Brian Carroll
>
>   

Regards,
Janky Jay, III
_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users

Mr. Jay and Mr. Morton,

First off, you guys were exactly correct, I should have been
using type
'4'. I also should have read the danged file better because
it was right
there in front of my nose! Doh! So thank you to both of you
for that.

Mr. Jay, Why do you feel that logging in through SQL is more
secure? In
my limited understanding, one must be root to use lo0
(127.0.0.1) so
what makes the SQL more secure? 

I am not challenging you, I just seek understanding. I do
sort of see
that if this server were to get very busy, going direct to
SQL, as
opposed to going via Dovecot, could be more efficient. So
once I have
everything worked out (see my Blank Page post I just sent) I
will very
likely switch to SQL authentication.

Regards,

Brian Carroll

> -----Original Message-----
> From: Janky Jay, III [mailto:jankyjunfs.us]
> Sent: Wednesday, February 13, 2008 3:12 AM
> To: Brian Carroll
> Cc: maia-usersrenaissoft.com
> Subject: Re: [Maia-users] Can't get authentication to
my Dovecot IMAP
to
> work
> 
> Hi, Brian.
> 
> Brian Carroll wrote:
> >
> > Heya Maia Mailguard Users and Devs!
> >
> >
> >
> > I have a nice little ISP-style build:
> >
> >
> >
> > CentOS 5
> >
> > postfix-2.3.3-2
> >
> > php-5.1.6-15.el5
> >
> > dovecot-1.0.9-0_65.el5
> >
> > Postfixadmin (maybe not the latest...got it from
SVN in December)
> >
> > Squirrelmail 1.4.13
> >
> > Maia Mailguard 1.0.2a
> >
>     I am currently using a setup much like this on
FreeBSD.
> 
> >
> >
> > When I use amavisd-new it all works, but of course
there is no
> > quarantine management/spam setting control so I
want to deploy Maia
> > Mailguard. I have gone through and followed the
install instructions
> > and think I am very close...but...
> >
> >
> >
> > 1.  I cannot get it to log me in at all. I figured
to use the
Dovecot
> > IMAP server since it is already working against
the Postfix database
> > (why re-invent the wheel?) but I can't seem to
make this work. The
> > Squirrelmail auths users in the same manner, which
works just fine
and
> > clients are using this mail (i.e. their MUA's are
working against it
> > just fine) server so I know my base setup is good.
Maia is the last
> > piece of my little puzzle...
> >
> >
> >
> >  I am using the setup as shown in the
"address re-writing" document
> > (http
://www.maiamailguard.org/maia/wiki/Addresses and the
README
> > :Postfix files) to hand the email to amavisd-maia
without being
> > re-written, and consequently
"$address_rewriting_type = 0". All
emails
> > appear in /var/log/maillog as 'userdomain.tld'. But it just won't
do
> > it. The answer is "NO, Authentication
failed." I have tried with and
> > without SSL, I have tried POP3 (also served by
Dovecot of course). I
> > have tried sql auth pointing it to my Postfixadmin
database and
using
> > the same value for "user name" and
"user email address" as
> > Postfixadmin uses them as one and the same.  I
have looked through
> > this mail lists archives and found people asking
the question, but
no
> > definitive answer except the address rewriting
thing. Any help would
> > be greatly appreciated.
> >
>     Well, this shouldn't be an error in the Dovecot
configuration at
all
> if users are able to authenticate. My guess is that
your
> 'address-rewrite' configuration option in the
Maia-Mailguard
> config.inc.php file should be set to '4' and not '0'.
This will use
the
> full email address for the authentication. Like I said,
I have a setup
> very similar to this on FreeBSD and I have my
'address-rewrite' set to
> '4' and all works swimmingly. If you'd like, you can
see the
> Maia-Mailguard installation how-to for FreeBSD that I
wrote by
visiting
> http://www.purple
hat.org/?page_id=4 and browse to the 'Maia-Mailguard
> Install' page. It will show you the configuration that
I am
successfully
> using which is currently SQL Authentication via the
MySQL socket
(Seems
> safer to me). But, it works so check it out and see if
it helps.
> 
> >
> >
> > 2. It doesn't seem to be able to pick up on the
GTUBE spam test. It
> > delivers it when I expect it to quarantine it.
Obviously from #1
above
> > I cannot log in and set my personal spam prefs, so
I am assuming it
> > will use the defaults from amavisd.conf, which I
have tightened up a
> > bit as follows:
> >
> >
> >
> > $sa_tag_level_deflt  = 2.0; # add spam info
headers if at, or above
> > that level
> >
> > $sa_tag2_level_deflt = 4.2;  # add 'spam detected'
headers at that
level
> >
> > $sa_kill_level_deflt = $sa_tag2_level_deflt;  #
triggers spam
evasive
> > actions
> >
> > $sa_dsn_cutoff_level = 8;   # spam level beyond
which a DSN is not
sent
> >
> >
> >
> > Note that my amavisd-new picks up the GTUBE test
every time.
> >
> >
> >
> > I have tried this with the default values also, it
still delivers
the
> > GTUBE as clean mail.
> >
> >
> >
> > I did also re-import my SA rules to make sure they
were in play
(well,
> > as sure as I know how to be...)
> >
>     I'm assuming this will be fixed as soon as you log
in and make a
few
> adjustments. Also, as Maia-Mailguard learns it should
be blocked
without
> an issue at all.
> 
> >
> >
> > 3. How do I configure amavisd-maia to just DROP
anything identified
as
> > a virus without quarantining it? Frankly, I trust
Clam AV a LOT more
> > than I trust my users not to do something really
stupid. Can I maybe
> > just have anything id'd as a virus put in the
quarantine directory
> > where I might find it but my users have no access
to it? I really
> > don't want any users to have any chance to do
something silly with a
> > virus. I got enough trouble without adding to them
by giving them
any
> > view into something Clam says is infected....
> >
>     This, however, is easily done by setting the values
in the web
> interface once you've logged in. Each domain inherits
the settings
from
> the Default Domain (.). So,  just set the
default domain's 'Virus
> Scanning' to 'Enabled' and the 'Detected viruses should
be...' to
> 'Discarded'. Any email labeled as containing a virus
will be silently
> deleted.
> 
> >
> >
> > Regards, and TIA!
> >
> >
> >
> > Brian Carroll
> >
>     I hope this all helps!
> 
> Regards,
> Janky Jay, III
> 
> >
> >
> >
> >
> >
> >
> >
------------------------------------------------------------
------------
> >
> > _______________________________________________
> > Maia-users mailing list
> > Maia-usersrenaissoft.com
> > http://www.renaissoft.com/mailman/listinfo/maia-users
> >

_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users

Hello, Brian.

Brian Carroll wrote:
> Mr. Jay and Mr. Morton,
>
> First off, you guys were exactly correct, I should have
been using type
> '4'. I also should have read the danged file better
because it was right
> there in front of my nose! Doh! So thank you to both of
you for that.
>   

    Ah. Great to hear. :P

> Mr. Jay, Why do you feel that logging in through SQL is
more secure? In
> my limited understanding, one must be root to use lo0
(127.0.0.1) so
> what makes the SQL more secure? 
>
> I am not challenging you, I just seek understanding. I
do sort of see
> that if this server were to get very busy, going direct
to SQL, as
> opposed to going via Dovecot, could be more efficient.
So once I have
> everything worked out (see my Blank Page post I just
sent) I will very
> likely switch to SQL authentication.
>   

    I'm sorry. I should have probably extrapolated a bit on
that. I
didn't mean that the SQL authentication was more secure. I
was strictly
talking about changing the 'tcp(localhost:3306)/maia'
to use
'unix(/tmp/mysql.sock)/maia' instead. Just seems more
secure to me to
access the socket directly as opposed to using a TCP
connection (Not
that connecting to localhost could really cause much issue).
That was
just a tossed-in opinion of mine. Sorry about the
misunderstanding. :P
IMAP(S) authentication is perfectly fine and if you're
comfortable with,
stick with it. Besides that, I believe you'd need quite a
bit of load to
notice a difference in the speed between authenticating via
IMAP other
than straight to SQL. At least a few dozen users... The only
reason this
would be an issue is that the user authenticates through
IMAP which
authenticates the user via MySQL. I just prefer to jump
right to the source.

> Regards,
>
> Brian Carroll
>
>   
    I hope this helps! Again, sorry for any confusion...

Regards,
Janky Jay, III

>> -----Original Message-----
>> From: Janky Jay, III [mailto:jankyjunfs.us]
>> Sent: Wednesday, February 13, 2008 3:12 AM
>> To: Brian Carroll
>> Cc: maia-usersrenaissoft.com
>> Subject: Re: [Maia-users] Can't get authentication
to my Dovecot IMAP
>>     
> to
>   
>> work
>>
>> Hi, Brian.
>>
>> Brian Carroll wrote:
>>     
>>> Heya Maia Mailguard Users and Devs!
>>>
>>>
>>>
>>> I have a nice little ISP-style build:
>>>
>>>
>>>
>>> CentOS 5
>>>
>>> postfix-2.3.3-2
>>>
>>> php-5.1.6-15.el5
>>>
>>> dovecot-1.0.9-0_65.el5
>>>
>>> Postfixadmin (maybe not the latest...got it
from SVN in December)
>>>
>>> Squirrelmail 1.4.13
>>>
>>> Maia Mailguard 1.0.2a
>>>
>>>       
>>     I am currently using a setup much like this on
FreeBSD.
>>
>>     
>>> When I use amavisd-new it all works, but of
course there is no
>>> quarantine management/spam setting control so I
want to deploy Maia
>>> Mailguard. I have gone through and followed the
install instructions
>>> and think I am very close...but...
>>>
>>>
>>>
>>> 1.  I cannot get it to log me in at all. I
figured to use the
>>>       
> Dovecot
>   
>>> IMAP server since it is already working against
the Postfix database
>>> (why re-invent the wheel?) but I can't seem to
make this work. The
>>> Squirrelmail auths users in the same manner,
which works just fine
>>>       
> and
>   
>>> clients are using this mail (i.e. their MUA's
are working against it
>>> just fine) server so I know my base setup is
good. Maia is the last
>>> piece of my little puzzle...
>>>
>>>
>>>
>>>  I am using the setup as shown in the
"address re-writing" document
>>> (http
://www.maiamailguard.org/maia/wiki/Addresses and the
README
>>> :Postfix files) to hand the email to
amavisd-maia without being
>>> re-written, and consequently
"$address_rewriting_type = 0". All
>>>       
> emails
>   
>>> appear in /var/log/maillog as 'userdomain.tld'. But it just won't
>>>       
> do
>   
>>> it. The answer is "NO, Authentication
failed." I have tried with and
>>> without SSL, I have tried POP3 (also served by
Dovecot of course). I
>>> have tried sql auth pointing it to my
Postfixadmin database and
>>>       
> using
>   
>>> the same value for "user name" and
"user email address" as
>>> Postfixadmin uses them as one and the same.  I
have looked through
>>> this mail lists archives and found people
asking the question, but
>>>       
> no
>   
>>> definitive answer except the address rewriting
thing. Any help would
>>> be greatly appreciated.
>>>
>>>       
>>     Well, this shouldn't be an error in the Dovecot
configuration at
>>     
> all
>   
>> if users are able to authenticate. My guess is that
your
>> 'address-rewrite' configuration option in the
Maia-Mailguard
>> config.inc.php file should be set to '4' and not
'0'. This will use
>>     
> the
>   
>> full email address for the authentication. Like I
said, I have a setup
>> very similar to this on FreeBSD and I have my
'address-rewrite' set to
>> '4' and all works swimmingly. If you'd like, you
can see the
>> Maia-Mailguard installation how-to for FreeBSD that
I wrote by
>>     
> visiting
>   
>> http://www.purple
hat.org/?page_id=4 and browse to the 'Maia-Mailguard
>> Install' page. It will show you the configuration
that I am
>>     
> successfully
>   
>> using which is currently SQL Authentication via the
MySQL socket
>>     
> (Seems
>   
>> safer to me). But, it works so check it out and see
if it helps.
>>
>>     
>>> 2. It doesn't seem to be able to pick up on the
GTUBE spam test. It
>>> delivers it when I expect it to quarantine it.
Obviously from #1
>>>       
> above
>   
>>> I cannot log in and set my personal spam prefs,
so I am assuming it
>>> will use the defaults from amavisd.conf, which
I have tightened up a
>>> bit as follows:
>>>
>>>
>>>
>>> $sa_tag_level_deflt  = 2.0; # add spam info
headers if at, or above
>>> that level
>>>
>>> $sa_tag2_level_deflt = 4.2;  # add 'spam
detected' headers at that
>>>       
> level
>   
>>> $sa_kill_level_deflt = $sa_tag2_level_deflt;  #
triggers spam
>>>       
> evasive
>   
>>> actions
>>>
>>> $sa_dsn_cutoff_level = 8;   # spam level beyond
which a DSN is not
>>>       
> sent
>   
>>>
>>> Note that my amavisd-new picks up the GTUBE
test every time.
>>>
>>>
>>>
>>> I have tried this with the default values also,
it still delivers
>>>       
> the
>   
>>> GTUBE as clean mail.
>>>
>>>
>>>
>>> I did also re-import my SA rules to make sure
they were in play
>>>       
> (well,
>   
>>> as sure as I know how to be...)
>>>
>>>       
>>     I'm assuming this will be fixed as soon as you
log in and make a
>>     
> few
>   
>> adjustments. Also, as Maia-Mailguard learns it
should be blocked
>>     
> without
>   
>> an issue at all.
>>
>>     
>>> 3. How do I configure amavisd-maia to just DROP
anything identified
>>>       
> as
>   
>>> a virus without quarantining it? Frankly, I
trust Clam AV a LOT more
>>> than I trust my users not to do something
really stupid. Can I maybe
>>> just have anything id'd as a virus put in the
quarantine directory
>>> where I might find it but my users have no
access to it? I really
>>> don't want any users to have any chance to do
something silly with a
>>> virus. I got enough trouble without adding to
them by giving them
>>>       
> any
>   
>>> view into something Clam says is infected....
>>>
>>>       
>>     This, however, is easily done by setting the
values in the web
>> interface once you've logged in. Each domain
inherits the settings
>>     
> from
>   
>> the Default Domain (.). So,  just set the
default domain's 'Virus
>> Scanning' to 'Enabled' and the 'Detected viruses
should be...' to
>> 'Discarded'. Any email labeled as containing a
virus will be silently
>> deleted.
>>
>>     
>>> Regards, and TIA!
>>>
>>>
>>>
>>> Brian Carroll
>>>
>>>       
>>     I hope this all helps!
>>
>> Regards,
>> Janky Jay, III
>>
>>     
>>>
>>>
>>>
>>>
>>>
>>>       
>
------------------------------------------------------------
------------
>   
>>>
_______________________________________________
>>> Maia-users mailing list
>>> Maia-usersrenaissoft.com
>>> http://www.renaissoft.com/mailman/listinfo/maia-users
>>>
>>>       
>
>
>   

_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users

Postgres support is not there because I'm using MySQL and it
reports the
bugs in Net_IMAP and Image_Graph but I have patched them.
Other than
that, the board is green.

Brian Carroll

> -----Original Message-----
> From: Janky Jay, III [mailto:jankyjunfs.us]
> Sent: Wednesday, February 13, 2008 10:06 PM
> To: Brian Carroll
> Cc: maia-usersrenaissoft.com
> Subject: Re: Blank page after login
> 
> Hello, Brian.
> 
> 
> Brian Carroll wrote:
> > Heya All,
> >
> > Would you happen to know why I would get a blank
page after the
login?
> > "welcome.php" is blank...
> >
> 
>     When you visit your
>
'http(s)://www.domain.tld/maia-mailguard/configtest.php',
what does it
> say? Is there anything missing? If so, what?
> 
> > I have looked at this page
> > (http
://www.maiamailguard.com/maia/wiki/BlankPage) and made
sure my
> > permissions on 'themes/*/complied' are as
specified. 'Apache" is in
the
> > 'amavis' group (This is CentOS so my www user is
'Apache').
> >
> > I have looked at the Templates setup
> > (http://www.maiamailguard.com/maia/wiki/TemplatePermiss
ions) and
> > verified I have created a 'webfilter.conf' in
/etc/httpd/conf.d/
which
> > looks like (my maia is installed at
/var/www/html/webfilter):
> >
> >
> > Alias /webfilter
"/var/www/html/webfilter"
> >
> > <Directory
"/var/amavis/maia/templates/">
> >     Order allow,deny
> >     Allow from all
> > </Directory>
> >
> >
> > I also have verified that the user 'amavis' has
the correct rights
> > there:
> >
> > drwxr-xr-x 2 amavis amavis 4096 Feb  7 21:57
scripts
> > drwxr-xr-x 2 amavis amavis 4096 Feb  7 21:58
templates
> >
> > and in the 'Templates" dir itself:
> >
> > -rw-r--r-- 1 amavis amavis 2428 Feb  7 21:58
digest.tpl
> > -rw-r--r-- 1 amavis amavis  857 Feb  7 21:58
newuser.tpl
> > -rw-r--r-- 1 amavis amavis  812 Feb  7 21:58
reminder.tpl
> >
> > I do see 4 files like
'%%46^463^463266CC%%login_head.tpl.php' in the
> > theme 'ocean_surf/compiled' directory, but the
other two default
theme
> > dirs are blank. I did try 'chmod 777
themes/*/compiled' to no avail.
> >
> > SELinux and 'Security Level' are disabled and
verified by the
> > 'system-config-securitylevel' command.
> >
> > I have no errors in /var/log/php_errors.
> >
> > I have no errors in /var/log/httpd/error_log.
> >
> > I was seeing:
> >
> > [Wed Feb 13 21:06:25 2008] [error] [client ::1]
Directory index
> > forbidden by Options directive: /var/www/html/
> >
> > But those seem to have gone away since I created
the
> > '/etc/httpd/conf.d/webfilter.conf' file.
> >
> > On the bright side, I did get the login to accept
my credentials and
I
> > thank you very much for that!
> >
> 
>     Ah. Excellent. Glad to see authentication is a go.
> 
> > Regards,
> >
> > Brian Carroll
> >
> >
> 
> Regards,
> Janky Jay, III
_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users