On Tue, May 11, 2010 at 04:00, Steffen Kaiser

wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Mon, 10 May 2010, Phil Howard wrote:

user@domain address. The problem is that %d and %Ld are coming up as

...

empty, and %12MLd is giving me the first 12 hex characters of an md5 of an empty content. It's losing the domain name somewhere. It's in the mail headers and in the -a option. So what else is needed?

Do you re-write the "user" attribute in the passdb?

I do whatever this means:

auth default { mechanisms = plain login

#### passdb passwd-file { #### args = username_format=%Ln@%Ld /etc/mailauth/ALL.deny #### deny = yes #### } passdb passwd-file { args = username_format=%Ln /etc/mailauth/%Ld.deny deny = yes } #### passdb passwd-file { #### args = scheme=crypt username_format=%Ln@%Ld /etc/mailauth/ALL.passwd #### } passdb passwd-file { args = scheme=crypt username_format=%Ln /etc/mailauth/%Ld.passwd } #### userdb passwd-file { #### args = username_format=%Ln@%Ld /etc/mailauth/ALL.passwd #### } userdb passwd-file { args = username_format=%Ln /etc/mailauth/%Ld.passwd }

The intention of the above is that these passwd-file format files have only the username part of the full email address being logged in as, and a separate file be there for each domain. So if I login to IMAP as phil@example.com, then I would be authenticated by accessing file "/etc/mailauth/example.com.passwd" and searching for user "phil" in that file.

I would not expect the formatting of what username I search for in these files to cause the %d variable to lose its content.

Hi,

You are stripping the domain part of the username with the username_format specifiers:

passdb passwd-file { args = scheme=crypt username_format=%Ln /etc/mailauth/%Ld.passwd }

userdb passwd-file { args = username_format=%Ln /etc/mailauth/%Ld.passwd }

Try replacing %Ln with %Lu in both these cases.

Chris

Phil Howard wrote:

So what I am wondering, right now, is where the value for %d ... as used in mail_location ... comes from when running in dovecot/deliver. Apparently it is not getting anything through that means. Not know where it gets it from, I don't know where to look to see what is misconfigured.

On Wed, May 12, 2010 at 04:20, Steffen Kaiser

wrote:

actually it looks like, nobody uses passwd-file like you do :)

This aspect can be changed, if needed. If needed, one big file with user@domain in the first colon-separated field would be doable, too.

The doc at http://wiki.dovecot.org/AuthDatabase/PasswdFile would lead to your assumption of operation, that is:

• you auth using user@domain
• look up the user in the domain-specific file without domain
• but you don't overwrite "user", hence, further processing should have the domainin %d

Yes, the user will need to provide the full user@domain they want to login as. Just user alone is insufficient in some cases, and even if user fred is only in one domain today, it might also be in another domain, tomorrow. So all users will need to login with user@domain.

The initial scheme was looking for user by itself in a passwd-file format file identified with domain name. But this can be changed to looking for user@domain (which seems pointless unless it is one big file).

Overwrite?

It looks like my understanding of %n and %u was swapped. But that shouldn't affect %d. I can't imagine that by using %u it would cause %d to be empty (as in "oh, domain is already used, can't use it again").

I'd be using CDB format if it were available. So far, passwd-file is the only plain file format Dovecot supports. Postfix supports CDB and others, but not passwd-file. I wish there was common ground there. That or the Berkeley-DB format.

Yet another "format" I suggested many years ago is not supported anywhere (except in some code I wrote unrelated to email). That "format" is where the key is a file name in a specified directory, and the contents of that file would be the value yielded. It's a wasteful format in filesystems like ext2/3, but in reiserfs it works well as long as tail packing is not disabled.

Could you verify that the domain gets stripped by setting mail_debug,

auth_verbose and auth_debug?

Gonna work on that, today.

This page http://wiki.dovecot.org/VirtualUsers catches my eyes:

"In the above examples users are expected to log in as "user@domain". Their mail is kept in their home directory at /home/<domain>/<username>/Maildir.

The usernames in the passwd and shadow files are expected to contain only the user part, no domain. This is because the path itself already contained %d to specify the domain. If you want the files to contain full user@domainnames, you can use %0.d instead of %d."

This is exactly what you want, IMO.

I believe so. But I'm still not so sure Postfix's idea of "virtual users" is the same. I need to try it both ways. I do know in the past, virtual_* in Postfix was treating all domains as one and didn't work right for what I was doing (didn't involve Dovecot way back then).

These pages also describes your idea:

http://neranjara.org/article/title/How_to_configure_PostFix_and_Dovecot_for_...

• -and-

http://serverfault.com/questions/80590/how-do-i-persuade-dovecot-and-postfix...

They do seem to be using %d in the same kind of way I'm expecting to. I'll look these over to see if any differences in how other parts are configured can make sure %d has the recipient's domain.

Am 14.05.2010 um 17:05 schrieb Phil Howard:

On Wed, May 12, 2010 at 04:20, Steffen Kaiser

...

wrote:

...

Could you verify that the domain gets stripped by setting mail_debug, auth_verbose and auth_debug?

Where would I see the results of this?

In whatever logging facility you set up. It will simply raise verbosity.

Thomas

Am 14.05.2010 um 19:25 schrieb Phil Howard:

Nothing new is showing up when I test sending some mail through (which does get delivered to that path constructed with an empty string for %).

Which version are you now testing on? Recent posts were set around the beta. Is this for the 2.x beta or this rather old build you're showing here?

Regards Thomas

Am 14.05.2010 um 19:51 schrieb Phil Howard:

It is the version packaged in Ubuntu 9.10 …

This one is ancient. Also it has configuration syntax changes compared to the latest production release. Anyway the debug parameters should work, given they are in the right conf file...

Am 14.05.2010 um 20:03 schrieb Phil Howard:

I've been thinking that as soon as I get this working, I will plan a transition over to a newer server with Slackware instead of Ubuntu. Slackware is easier about letting you run packages you build from source.

Probably OT, but did you consider using Stephan Bosch's builds for that?

http://xi.rename-it.nl/debian/pool/testing-auto/dovecot-1.2/

On Fri, 2010-05-14 at 14:03 -0400, Phil Howard wrote:

On Fri, May 14, 2010 at 14:00, Thomas Leuxner tlx@leuxner.net wrote:

...

Am 14.05.2010 um 19:51 schrieb Phil Howard:

...

It is the version packaged in Ubuntu 9.10 …

This one is ancient. Also it has configuration syntax changes compared to the latest production release. Anyway the debug parameters should work, given they are in the right conf file...

I've been thinking that as soon as I get this working, I will plan a transition over to a newer server with Slackware instead of Ubuntu. Slackware is easier about letting you run packages you build from source.

Indeed it is, and hassle free.

Add in your auth,conf configuration:

auth_default_realm = [your domain]

2010/5/14 Phil Howard ttiphil@gmail.com

On Mon, May 10, 2010 at 15:21, Phil Howard ttiphil@gmail.com wrote:

...

I have this in dovecot-postfix.conf:

mail_location =

maildir:/home/mail/dnamesum=%12MLd/dname=%Ld/unamesum=%12MLn/uname=%Ln/mail

...

Yes, it is excessive, but that's just for testing. The pattern I really want is less clear for debugging. In postfix/main.cf I have:

mailbox_command = /usr/lib/dovecot/deliver -c /etc/dovecot/dovecot-postfix.conf -a "${RECIPIENT}"

I verified through strace that -a "${RECIPIENT}" is in fact getting a

full

...

user@domain address. The problem is that %d and %Ld are coming up as empty, and %12MLd is giving me the first 12 hex characters of an md5 of an empty content. It's losing the domain name somewhere. It's in the mail headers and in the -a option. So what else is needed?

There was a typo in an earlier config item:

auth_username_format = %Ln@Ld

Maybe that was what someone was screaming at me about when I looked at username_format. I didn't see this until I was trying to figure out why the passwd file wasn't being read. I ran strace, and saw that it was trying to access a file with "ld" in it. Even then it took a while because the domain had been reformed as "Ld" and subsequently lower cased later.

I found this while trying out a subset of a couple suggested configurations with some virtual_* settings in Postfix, and using dovecot/deliver via transport.

I will now clean up the mess and hope I don't break it doing that. Then slam it with email and see what happens next.

On 2010-05-14 3:52 PM, Phil Howard wrote:

On Fri, May 14, 2010 at 15:51, Alex Baule alexwbaule@gmail.com wrote:

...

Add in your auth,conf configuration:

auth_default_realm = [your domain]

Which domain goes there? I have many.

Whichever one you want to be the 'default' if the user neglects to add a domain to their client username field.

--

Best regards,

Charles

On 2010-05-17 9:34 AM, Phil Howard wrote:

On Sat, May 15, 2010 at 10:10, Charles Marcus wrote:

...

On 2010-05-14 3:52 PM, Phil Howard wrote:

...

On Fri, May 14, 2010 at 15:51, Alex Baule alexwbaule@gmail.com wrote:

...

auth_default_realm = [your domain]

...

...

Which domain goes there? I have many.

...

Whichever one you want to be the 'default' if the user neglects to add a domain to their client username field.

I don't want a default. I want them to get an authentication failure.

So... remove the setting...?

--

Best regards,

Charles

On 2010-05-14 3:37 PM, Phil Howard wrote:

There was a typo in an earlier config item:

auth_username_format = %Ln@Ld

I looked back in this thread and don't see any post where you provided output of dovecot -n...

For future reference, I think this would have been easily seen in the beginning had you done so. One of the things it will do is tell you when there is a syntax error and make typos more evident...

--

Best regards,

Charles