Re: [Mimedefang] score USER_IN_WHITELIST_TO

2017-11-22 Thread Bill Cole 

On 22 Nov 2017, at 16:39 (-0500), Kris Deugau wrote:
[...]
Right, sorry, I forgot about those kind of cases (even in the man page 
IIRC).  I've always excluded those by just not passing their mail to 
SA - either because of some magic in my MIMEDefang setup, or by 
disabling the call to SA at final delivery to a mailbox.


You can set the score for this the same as any other rule, by adding 
this to sa-mimedefang.cf:


score USER_IN_WHITELIST_TO  -100

Note that this affects *all* whitelist_to entries;  there is no way to 
selectively set a different score for each one.  If you need to do 
that, you probably need to make larger changes in the mail flow for 
those recipients so you can bypass SA entirely, or process it but 
deliver as usual instead of quarantining for those recipients.


Not wanting to seem argumentative for its own sake or turn this into 
, but this is from one of my local config 
files:


# Default is -6 but this is a more useful value
score USER_IN_WHITELIST_TO -3
# Default is -20 but that's too much for most exposed accounts
score USER_IN_MORE_SPAM_TO -10.000
# Default is -100 but "all" really shouldn't extend that far. There are 
limits...

score USER_IN_ALL_SPAM_TO -40.000

Because as 'perldoc  Mail::SpamAssassin::Conf' explains:

   There are three levels of To-whitelisting, "whitelist_to",
   "more_spam_to" and "all_spam_to". Users in the first level may
   still get some spammish mails blocked, but users in "all_spam_to"
   should never get mail blocked.

I use this to both protect role addresses and (in conjunction with 
Postfix config) to provide users with multiple flavors of tagged 
addresses that get different levels of protection from my draconian 
local SA rules and the local DNSBL (not queryable from outside although 
idiots do try) which lists space used by a whole lot of perfectly 
innocent people (literally billions) and more than a few part-time 
miscreants (e.g. SendGrid, MailChimp, etc.)



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID.  You may ignore it.

Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

Re: [Mimedefang] score USER_IN_WHITELIST_TO

2017-11-22 Thread Kris Deugau 

Marcus Schopen wrote:

Am Dienstag, den 21.11.2017, 10:32 -0500 schrieb Bill Cole:

On 20 Nov 2017, at 16:41 (-0500), Kris Deugau wrote:


USER_IN_WHITELIST_TO applies to all mail for a given recipient;  IMO
it's a crude hack to work around cases where whatever is calling SA
can't use the SA userprefs system to just change the threshold
instead.


It is very useful for protecting role aliases (e.g. abuse, postmaster)
that are mapped to targets (e.g. root or an off-system address) that
should not generally be left unprotected.


This is what I want to use it for: postmaster@ and abuse@


Right, sorry, I forgot about those kind of cases (even in the man page 
IIRC).  I've always excluded those by just not passing their mail to SA 
- either because of some magic in my MIMEDefang setup, or by disabling 
the call to SA at final delivery to a mailbox.


You can set the score for this the same as any other rule, by adding 
this to sa-mimedefang.cf:


score USER_IN_WHITELIST_TO  -100

Note that this affects *all* whitelist_to entries;  there is no way to 
selectively set a different score for each one.  If you need to do that, 
you probably need to make larger changes in the mail flow for those 
recipients so you can bypass SA entirely, or process it but deliver as 
usual instead of quarantining for those recipients.


-kgd
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID.  You may ignore it.

Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

Re: [Mimedefang] score USER_IN_WHITELIST_TO

2017-11-22 Thread Marcus Schopen 
Am Dienstag, den 21.11.2017, 10:32 -0500 schrieb Bill Cole:
> On 20 Nov 2017, at 16:41 (-0500), Kris Deugau wrote:
> 
> > USER_IN_WHITELIST_TO applies to all mail for a given recipient;  IMO 
> > it's a crude hack to work around cases where whatever is calling SA 
> > can't use the SA userprefs system to just change the threshold 
> > instead.
> 
> It is very useful for protecting role aliases (e.g. abuse, postmaster) 
> that are mapped to targets (e.g. root or an off-system address) that 
> should not generally be left unprotected.

This is what I want to use it for: postmaster@ and abuse@

Ciao!


___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID.  You may ignore it.

Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

Re: [Mimedefang] Error with mimedefang + clamd

2017-11-22 Thread Bill Cole 

On 22 Nov 2017, at 10:11 (-0500), Info @ brainwash wrote:


/var/spool/MIMEDefang/ directory has rights 0766 and belongs to user
defang:defang (it is been reset to these values every time the 
mimedefang

service restarts or the server reboots).


Dianne has already given the proper solution but this begs for a general 
warning...


Setting the world-writable bit on any file or on a directory without 
also setting the sticky bit is a risky action. You should NEVER leave a 
file or directory world-writable. Also on directories, it is generally 
not useful to set read bits without also setting the execute (i.e. 
search, for directories) bits.


From what I found when Googling this error, the issue is that 
MIMEDefang cannot create the work directory thus Clam cannot find the 
file to scan.


It's usually best to read the man pages that are written by the author 
of a program before searching for random answers on the web who may not 
understand their problem, may not be getting an error message for the 
same reason you are, and may be using a version (or platform variant) 
that is unlike yours. This looks to me like a wrong answer but it really 
does not matter because the fix is simple and clearly documented in the 
mimedefang man page.


I tried to make the directory 0777 and even change the users using 
chown, to no effect.


Reiterating the above: don't set the world-writable bit anywhere except 
on shared directories with the sticky bit set (e.g. /tmp and /var/tmp 
use mode 1777) and (sometimes) sockets and devices. It's not a safe 
solution to any problem and usually isn't even helpful as a 
troubleshooting tool.


MIMEDefang by design creates and destroys many files and directories for 
short lives, so for safety it needs to manage permissions itself very 
carefully and tightly. It cannot rely on sysadmins creating safe working 
ownership and permission constructs because it is a known fact that many 
sysadmins never actually read documentation. It is conceivable that MD 
could have been written to be entirely ignorant of security issues and 
rely on sysadmins to use whatever mix of standard ownership & 
permissions, BSD setgid semantics, and ACLs is available and necessary 
to allow everything MD does to work safely. I believe that if that were 
the case, MD would have a reputation of being hard to make work and 
grossly insecure. It's better this way.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID.  You may ignore it.

Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

Re: [Mimedefang] Error with mimedefang + clamd

2017-11-22 Thread Dianne Skoll 
Hi,

You should either add the ClamAV user to the "defang" group and
use the "-G" option to have mimedefang create group-accessible files, or
simply run clamd as the "defang" user directly.

Regards,

Dianne.

> Clam has been unable to scan for e-mails when received by MIMEDefang,
> producing the following error in the log:
> 
> WARNING: lstat() failed on: /var/spool/MIMEDefang/mdefang-UB1us0i/Work
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID.  You may ignore it.

Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

[Mimedefang] Error with mimedefang + clamd

2017-11-22 Thread Info @ brainwash 
Hello,

I have installed MIMEDefang 2.8.3 from the EPEL repository on a Centos
7-4.1708.el7.centos.x86_64 VM. I have also installed CLAMAV as clamd (daemon
- v0.99.2/24063) under user clamscan and I have also configured
clamav-milter to integrate it with Postfix. All of them run successfully.

I then configured MIMEDefang to scan mails using clamd and not only perform
Spam check via SpamAssassin. MIMEDefang runs under the user defang. User
degang is a member of the clamscan group and vice versa. The
/var/spool/MIMEDefang/ directory has rights 0766 and belongs to user
defang:defang (it is been reset to these values every time the mimedefang
service restarts or the server reboots).

Clam has been unable to scan for e-mails when received by MIMEDefang,
producing the following error in the log:

WARNING: lstat() failed on: /var/spool/MIMEDefang/mdefang-UB1us0i/Work

. and within maillog:

Clamd returned error: lstat() failed: Permission denied
Problem running virus scanner: code=999, category=swerr, action=tempfail
filter:  tempfail=1
Tempfailing because filter instructed us to

From what I found when Googling this error, the issue is that MIMEDefang
cannot create the work directory thus Clam cannot find the file to scan. I
tried to make the directory 0777 and even change the users using chown, to
no effect.

Can anyone help with this error as MIMEDefang cannot work with clam? Running
clam as user defang is not an option unfortunately due to admin
restrictions.

Thank you






___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID.  You may ignore it.

Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang