Hi Joe,

Here is the procmail.log:

procmail: [[26836]] Sun Feb 4 03:07:15 2007
procmail: Assigning "LOGABSTRACT=all"
procmail: Assigning "LOG=Mail is to server.indecta "
Mail is to server.indecta procmail: Executing "/etc/webmin/virtual-server/lookup-domain.pl,server.indecta"
procmail: Assigning "VIRTUALMIN="
procmail: [[26836]] Sun Feb 4 03:07:20 2007
procmail: Executing "/usr/bin/test,115395789926162,!=,"
procmail: [[26836]] Sun Feb 4 03:07:20 2007
procmail: Match on "/usr/bin/test 115395789926162 != "
procmail: Assigning "INCLUDERC=/etc/webmin/virtual-server/procmail/115395789926162"
procmail: Assigning "DROPPRIVS=yes"
procmail: Assuming identity of the recipient, VERBOSE=off
LibClamAV Error: Wrote 0 instead of 512 (/tmp/clamav-71fee4ca0470b156/main.db).
cli_untgz: Disk quota exceeded
LibClamAV Error: cli_cvdload(): Can't unpack CVD file.
LibClamAV Error: Can't load /var/lib/clamav/main.cvd: CVD extraction failure
ERROR: CVD extraction failure
From root@server.indecta.se Sun Feb 4 03:07:15 2007
Subject: test
Folder: /etc/webmin/virtual-server/clam-wrapper.pl /usr/bin/clamscan 566
From root@server.indecta.se Sun Feb 4 03:07:15 2007
Subject: test
Folder: /home/indecta/homes/server/Maildir/new/1170554842.26836_0.se 693

What does "cli_untgz: Disk quota exceeded" mean???

[[root@server ~]]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/hda2 73G 5.4G 64G 8% /
/dev/hda1 99M 14M 81M 14% /boot
/dev/shm 252M 0 252M 0% /dev/shm

Hey Leif,

So, it looks like there are potentially two problems here.

The first is that your user doesn't have enough free space within his quota to handle virus scanning. Procmail, when performing all checks and such, becomes the recipient user. Thus, the quotas that apply to your user apply to all processing, as well.

There's supposed to be a check in place to prevent spam and AV filtering from happening if there is less than 5MB of free quota space for the user...but maybe the requirements for scanning have grown.

First step is to increase the quota of the user, and/or the domain of the user (both the domain and the user must have sufficient free space for scanning to succeed), and test again.

Hmmm...

Not proud of it, but I have for example one domain with the total domain quota of 250Mb and I think they have 28 mail accounts of 25Mb each, must be something wrong with my calculator ;-)

I'll look over all domains and do another test after "fixing" the quotas. (I often check the quota usage and I can't recall no one been over their total domain quota soo far.)

I'll set all domain quotas higher than the total user quota and try again.

Thanks,
Leif

Hey Leif,

You're not alone. A lot of folks have been bitten by the "users add up to fill domain" quota issue. It's a tricky one, and we need better tools for spotting this kind of trouble. ;-)

But, there could be other issues...We'll have to see once the quotas are big enough to contain all of the users in the domain.

Hi Joe,

Now all quotas are correct. And I think I got it right:
All user quotas + Server administrator's quota = Total server quota

I don't think this was the problem though, as I said earlier no quotas was near their limits.
This error:
-----------
LibClamAV Error: Wrote 0 instead of 512 (/tmp/clamav-0801f38e76bc7a23/main.db).
cli_untgz: Disk quota exceeded
LibClamAV Error: cli_cvdload(): Can't unpack CVD file.
LibClamAV Error: Can't load /var/lib/clamav/main.cvd: CVD extraction failure
ERROR: CVD extraction failure
-----------
seems to hapend only when sending to root, when send to my account this error don't occur. But there is another error message instead:
procmail: Program failure (1) of "/etc/webmin/virtual-server/clam-wrapper.pl"

When sending the Eicar test virus to root it gets delivered normally and when sending to my account the mail gets droped. To be shure I changed the virus delivery from "Throw away" to "Write to file" and tested again, The Eicar file got delivered to the "virus file" as it should.

I have now removed the MIME header check temporary to see if the infected attachments has gone away or if they start to drop in again.

Is this error ok, or should something be done?
procmail: Program failure (1) of "/etc/webmin/virtual-server/clam-wrapper.pl"

Regards,
Leif

Hi Joe,

Sorry for being stubborb...
Regarding the authentication when sending mails and using the own server as the outgoing SMTP.

I tried on our old server to send a mail FROM a fake account to an account on the server, with no success.
And yes every one (not using the server as outgoing SMTP) can send mails TO all accounts on the server
If I do the same on our new server the mail gets delivered.

I configured a mail account for the old server with all settings correct, entered the right username but WRONG pwd. With these settings i'm not able to send any mails FROM/WITH our server, neither to accounts outside the server or localy on the server.
This is the way I want our new server to handle the outgoing mail. I now DO KNOW it's working.

On our new server you can put in what ever you like in your mail client information as long as you enter either the server IP or mail.some-domain-on-the-server.tld in the SMTP field. You can now send mails to all users on our server, with our server as the outgoing SMTP in your mail client.

How do I configure our new server to handle the outgoing SMTP the same way that the old server does??? and I now know it can be configured to work that way! :-)

Regards,
Leif

Hey Leif,

Being stubborn is fine. I make a habit of it, myself. And despite appearances to the contrary I don't know everything about system administration, though I try. ;-)

BUT, I'd have to see more details about the old server. It could be rejecting based on all sorts of things, but it can't possibly be rejecting for failure to authenticate (because none of the sending SMTP servers on the internet are going to authenticate--it just isn't happening that way). I guarantee that if your old server accepts mail from the outside world (e.g. if I can send mail to it from Virtualmin.com or gmail or whatever), I can also connect directly from here and send mail directly to it for users on that server, and those messages will be delivered. I'm absolutely certain of it...it isn't possible to require SMTP authentication and receive mail from outside servers.

There is no facility in the SMTP protocol that is being widely used (OK, there is SPF, but you probably can't quite safely block on this yet...it's something to consider in spamassassin rules, however) to do otherwise. Your mail server must relay (without authentication) for any mail from the outside world to local users in order to receive mail for your users.

So, let's look at the maillog for that old server and see why the mails are being rejected when you try to hook up your mail client to it--we can add a similar rule to your new server and block that small subset of spammy situations. (Send along the relevant section of the old mail server config, as well. That'll help us analyze what's happening and why.)

See, I'm stubborn, too. And I'm happy to chat with an equally stubborn sort. ;-)

Hi,

hehe... yes stubborn is good!
So i'm going to send you a mail with some info, and hopefully you will try sending a mail to a local user on that doman.

What do you make of my post #16

Regards,
Leif

Hi,

Just for the record...

Regardin #17 and #18
I was wrong and Joe was right... as always! :-)

Regards,
Leif