[Dovecot] Dovecot handling of over quota messages

[Andrzej Adam Filip]

Steffen Kaiser <skdovecot at smail.inf.fh-brs.de> wrote:

> On Mon, 26 Jan 2009, Andrzej Adam Filip wrote:
>
>>> Wasn't the socket map also (mainly?) used for verifying if a user
>>> exists? That I have been planning on implementing some day (for last 5
>>> years or so).
>>
>> AFAIR Socket map was originally intended to allow "stable sendmail code"
>> integration of  "multitude" of databases (mysql,oracle,postgress,...).
>
> Which is running pretty well. I'm running my virtuser and Aliases with a 
> socket map server querying (and caching) LDAP and Postgres databases and 
> mangle our myriads of domain aliases.
>
>> It may be used to:
>> 1a) ask mailbox server with virtual domain (e.g. dovecot) which domain it
>>    wants/handles at sendmail daemon startup
>> 1b) reject messages to overquota mailboxes in reply to "RCPT TO:" (4??/5???)
>>    [Cyrus IMAP does not try to detect "this message" will cross quota]
>
> At this point I made no success. The problem I encountered is that with 
> aliases and forwards I don't know the point when to return the failure, 
> meaning "there could a another user resolution step to forward the mail 
> along". E.g. ".forward" files come last, out of reach of the socket map 
> server.

You can use "post aliases/forwards" rule set (rule set localaddr=5).
Make sure sendmail select mailer with F=A (aliasing) and F=5 (use rule set 5).
Be warned sendmail *IGNORES* temp codes (4??) generated in this rule set.

>> 1c) implement aliases
>>    It should allow "per virtual domain" email administrators
>>    implemented in dovecot.
>> 1d) allow users to specify "at 'RCPT TO:'" sieve scripts
>
> ?? Huh, Sieve scripts at RCPT TO phase?

There will be no headers to check, and no body to "redirect" but IMHO 
it makes a perfect sense to allow "end user" *reject*  messages at this
point using "personalized rules".

>> After modification of sendmail source code socket map may be used to
>> pass to sendmail information about virtual users (uid,gid,$HOME).
>
>> It should allow:
>> 2a) supporting .forward files *for virtual users* (e.g. ~/.forward.user)
>
> You mean by to extend the map-scheme to getpwnam() ?

Sendmail supports "mailbox databases" interface with currently
provided getpwnam and LDAP "incarnations".

The best way wild be to code new mbdb taking user data in getpwnam
format from sendmail.cf rule set [ the rule set may call socket map].

>> 2b) making sendmail execute deliver program with uid and gid of virtual
>>    user
>> ---------------------------------------------------------------------
>> Consider also implementing support for (simple) saslauth protocol
>> together with socket map => it will allow sendmail (without dovecot sasl
>> support) to use/check passwords stored by dovecot in SMTP AUTH.
>
> Dunno, but there is already a simple saslauth protocol sendmail can use:
>
> IN  <len>username<len>password<len>service<len>realm
> OUT <len>code
>
> code:
> OK [reason]
> NO [reason]
>
> Googling for it I found a comment about its history:
> http://www.opensource.apple.com/darwinsource/10.3/passwordserver_sasl-14/cyrus_sasl/saslauthd/saslauthd.c
>
> But as you already pointed out, one needs a getpw*(), too.

I was thinking about allowing cyrus sasl used by sendmail to query
dovecot about SMTP AUTH passwords validity using the protocol you 
have mentioned.

-- 
[pl>en: Andrew] Andrzej Adam Filip : anfi at onet.eu
We fight only when there is no other choice.  We prefer the ways of
peaceful contact.
  -- Kirk, "Spectre of the Gun", stardate 4385.3