Jakob Hirsch wrote:
> Quoting W B Hacker:
>
>
>>> server_setid = $auth1
>>
>>We would need (at least) two separate variables for the challenge-response process.
>>
>>Our passwords and UID's do not resemble <user>@<domain>
>
>
> Fine, that would make a lousy password anyway :)
World seems to be full of folks using the email address as a UID.
>
>
>>- and are neither the same, nor even the same *format*, for IMAP/POP, smtp, and
>>Webmail.
>
>
> Uh? The strangeness of your setup is well known (I shudderly remember
> the SSL-on-port-587 thing...), but it keeps beating itself...
Nah, that one pays-off bigtime on faster connections alone.
> I cannot think of single reason why somebody would do that (apart from
> keeping the IT support people busy and making oneself indispensable, but
> I'd would never think something like that about you, of course :)
>
Nothing to it, field-support-wise. It lets non-computer-literate staff
issue new, revoke old UID's and passwords, and/or keep a 'role' account active
and transfer it intact when staff are reassigned, leave, join... all w/o
mailadmin's intervention.
Much like locally changing access numbers for a combination lock instead of
calling a locksmith in to pull tumblers, re-key the door, and cut new keys.
> An (expanded) option for sending arbitrary user-ids could be added, but
> as I said, why bother...
>
Agreed. Those NOT using the email address as a UID probably aren't using SASL
either. And I don't mean our contrarian way, but in general.
> I tested the old patch a while ago and it worked fine, but I didn't want
> to make exim depend too much on dovecot, as it was in a beta state and
> the auth daemon could not be run as a separate process (AFAIR), which
> should be done IMO if used by multiple programms.
>
>
? Our Dovecot has run the auth process separately for a very long time.
OTOH, we have always used it with PostgeSQL, so...
Bill
