/dev/rob0 wrote:
On Wed, Dec 09, 2009 at 11:21:56AM -0800, JP wrote:
i'll guess the solution to my problem will be something simple and obvious,
I think so.
and yet you haven't really provided any assistance for the problem at hand except some condescending answers for unrelated things and 'look elsewhere'. surprised you didn't tell me to use qmail.
[snip]
config stuff:
# postconf -n
mail_owner = _postfix
That strange non-default setting might be one of the problems.
it's not strange. it's the os x uid/gid scheme. the purpose of the configuration files is to allow folks to configure things to meet their needs. the socket is readable and writable by both _postfix(postfix) and dovecot so i don't understand how that would cause the problem.
queue_directory = /private/var/spool/postfix
That's equally strange and also a likely part of the problem.
that's not strange either. /var is a symlink to /private/var; i have tried setting postfix:smtpd_sasl_path and the dovecot socket path to the full path of /private/var/spool/postfix, and then to /var/spool/postfix and both resulted in the same behaviour.
smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated reject
This is not suitable for mail exchange, and not needed anyway. This says you reject anything which has not authenticated or is not in mynetworrks.
but it's okay for testing and has no effect on sasl authentication.
smtpd_helo_restrictions = reject_invalid_helo_hostname reject_non_fqdn_helo_hostname
These are good restrictions to use, but they will block some MUA submission. They belong __ | below v
smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks reject_unauth_destination check_policy_service unix:private/policy reject
in here after the two permit_* restrictions.
smtpd_pw_server_security_options = plain, login cram-md5 smtpd_use_pw_server = yes
postconf: warning: smtpd_pw_server_security_options: unknown parameter postconf: warning: smtpd_use_pw_server: unknown parameter
sorry, these were left in by mistake.
This is patched. Talk to Apple for support. The patching could be a part of the problem as well.
yes i imagine it is patched by apple. i don't have an apple support contract which is why is was posting to the list.
smtpd_sasl_path = private/auth
This pathname, as documented, is relative to $queue_directory. See above for your strange non-default setting.
it strikes me as odd that you keep calling the non-default settings 'strange' and 'bizarre'. if everyone in the universe should use the default settings then what's the point of the config files? i'm just sayin. any color i want as long as it's black?
virtual_mailbox_base = /etc/postfix/datastore
This is really bizarre. Sure, files can go anywhere you want, but is there anything wrong with traditional Unix standards? I'm reminded of the famous quote: "Those who don't understand Unix are doomed to reinvent it, poorly."
i understand unix. this is my first foray into postfix and dovecot. the setting is not bizarre. i'm moving all my virtual mail files onto a separate drive, which just happens to be on that pariticular mount point. for testing. and contrary to what you seem to be attempting to get me to believe, just because i'm not doing it your way does not make it strange or bizarre.
# dovecotd -n # 1.1.17apple0.5: /private/etc/dovecot/dovecot.conf Warning: fd limit 256 is lower than what Dovecot can use under full load (more than 456). Either grow the limit or change login_max_processes_count and max_mail_processes settings
Hmmm, that sounds like something you might want to consider.
auth default: verbose: yes debug: yes debug_passwords: yes passdb: driver: passwd-file args: username_format=%n /etc/postfix/datastore/%d-passwd userdb: driver: passwd-file args: username_format=%n /etc/postfix/datastore/%d-passwd socket: type: listen client: path: /var/spool/postfix/private/auth
I see a problem in that path!
see above about the symlinks.
mode: 432 user: postfix group: postfixI see a problem in that user (and maybe group)!
see above re: _postfix and postfix.
it would seem that something's not right between postfix and dovecot.
Perhaps Dovecot should create a socket in the place Postfix needs it, with ownership such that Postfix can use it.
thanks for the vague help and the condescending answers. at least you didn't insult my mom. gotta wonder if this is one of the reasons people don't like open source software.