[Dovecot] SASL plain authentication failed; unable to lookup user record

[JP]

/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: postfix
> 
> I 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.