Virtual Users And Domains With Postfix, Courier And MySQL

[triak]

Hi,
We just got our mail server up and running following the howto on this site.
There are still some issues we have to solve. If someone of u mailgurus could help us :=)

What about special mail accounts like root, postmaster, hostmaster etc.?
We tried to make a account for postmaster to mysql database and postfix complains about:
TROUBLE in check_mail: creating_partsdir FAILED: DBD::mysql::st execut
e failed: Lost connection to MySQL server during query at (eval 38) line 238, <GEN14> line 180.
This happens allso with hostmaster@abc.com mail account.

postmaster is defined in /etc/aliases by default in debian installation.
How should we forward theese system accounts to someone that reads them?

What about the 10MB quota limit? If I put a bigger limit to the mysql database,
the server still complains about quota exeeding. How can we make this limit bigger?

[falko]

Is abc.com a domain that you use for virtual hosting with Postfix, i.e., do you use it for virtual email addresses?

What about the 10MB quota limit? If I put a bigger limit to the mysql database,
the server still complains about quota exeeding. How can we make this limit bigger?

Never heard of such a problem.
You just have to increase the quota in the database...

[triak]

Hi
Yes, abc.com is the domain name for virtual hosting and it's allso the domain for our three servers. But we solved the problem by creating theese mail accounts on the mysql server and making a forward to real users who should read root/postmaster/etc mail and it seems to be working quite well.

The quota is another case. No matter how big I set the value in the database we get:
postfix/smtpd[22197]: NOQUEUE: reject: MAIL from aaa.bbb.org[xxx.xxx.xxx.xxx]: 552 Message size exceeds fixed limit; proto=ESMTP helo=<aaa.bbb.org>
... and the server disconnects. I tried to put bigger quota on both sending and recieving users (the sending one really should not matter?) both on the same server.
tia: Johannes

[falko]

Originally Posted by triak

Hi
Yes, abc.com is the domain name for virtual hosting and it's allso the domain for our three servers. But we solved the problem by creating theese mail accounts on the mysql server and making a forward to real users who should read root/postmaster/etc mail and it seems to be working quite well.

You shouldn't use a domain for virtual hosting that is also in the mydestination line in /etc/postfix/main.cf.

Originally Posted by triak

The quota is another case. No matter how big I set the value in the database we get:
postfix/smtpd[22197]: NOQUEUE: reject: MAIL from aaa.bbb.org[xxx.xxx.xxx.xxx]: 552 Message size exceeds fixed limit; proto=ESMTP helo=<aaa.bbb.org>
... and the server disconnects. I tried to put bigger quota on both sending and recieving users (the sending one really should not matter?) both on the same server.
tia: Johannes

What's the value of message_size_limit in /etc/postfix/main.cf? I guess this causes the problems.

[triak]

Hi,

"You shouldn't use a domain for virtual hosting that is also in the mydestination line in /etc/postfix/main.cf"

We are going to host multiple virtual domains, 10+ or something.
abc.com is one of them. The mailsystem seems to be working ok even if the real dns name for the mailsystem is mail.abc.com. Is this a security risk?
We still need to have many accounts on abc.com, that dont have
normal shell access.

About quota:

"What's the value of message_size_limit in /etc/postfix/main.cf? I guess this causes the problems."

Currently working is:
postconf |grep size
mailbox_size_limit = 0
message_size_limit = 0

If i user 104857600 (100MB) as message_size limit. We get following errors in the log:

postfix/virtual[6801]: fatal: main.cf configuration error: virtual_mailbox_limit is smaller than message_size_limit

Any idea's? We would like to have 100MB quota for every virtual mail user.

[falko]

The problem is that you're mixing up real system users and virtual users.
If abc.com wasn't in the mydestination line, then you wouldn't have any problems.