Delivery to Shared Folders via authenticated SMTP then LMTP

[Duncan Gibb]

Andy Bennett wrote:

DG> To do what I think you want (ACLs for delivery to shared
DG> mailboxes by users employing SMTPA), you need Exim to pass
DG> the authenticated user from the SMTP transaction with the
DG> MUA into the _MAIL_ line of the LMTP conversation.

DG>  MAIL FROM:<andyjpb at ashurst.eu.org> AUTH=<andyjpb at ashurst.eu.org>

AB> Something more sinister is wrong.

AB> I thought that messages were being delivered correctly in
AB> non shared folders scenarios because every test message I
AB> sent from external relays, such as gmail, were being received.

AB> However, I eventually noticed [rejections of] legitimate ones
AB> such as traffic to this list

> 2009-04-21 15:10:27 H=mx2.andrew.cmu.edu [128.2.11.36] 
> F=<info-cyrus-bounces+andyjpb=ashurst.eu.org at lists.andrew.cmu.edu> 
> temporarily rejected RCPT <andyjpb at ashurst.eu.org>: response to "MAIL 
> FROM:<>" from localhost [127.0.0.1] was: 430 Authentication require

AB> Your reply went to the list and directly to me: the direct one
AB> came through but the one from mailman got stuck between my smtp
AB> and lmtp servers and was therefore temporarily rejected.

That sounds like an Exim problem, and hence might be better discussed on
an Exim list.  I've not seem what you've done with your shared mailbox
delivery rules, but is it possible the + characters in mailman
envelope-from addresses are confusing it?


AB> For now, I've gone back to using lmtp in "lmtp -a" mode and it
AB> seems to have fixed things... Hopefully all the temporarily
AB> rejected mail will start to come through in the next few hours.

IMHO "lmtpd -a" is the work of the devil ;-)  Not to be used unless the
MTAs and the front-end Cyruses are on a secure network segment, you
really really trust your MTAs and don't have auto-* enabled...


AB> Why do different things happen when running "lmtp -a" compared
AB> to "lmtp" and logging in as an lmtp_admin?

The only difference between "lmtpd" and "lmtpd -a" should be that the
latter fakes a SASL external auth for the default lmtp admin, "postman".

When you say "logging in", I presume you're talking about an IMAP
session.  IMAP and LMTP necessarily present different views of the
mailbox namespace: in the IMAP case the view you get is the authzid's
view; in the LMTP case the view of the namespace we're interested in is
normally the recipient's view.

The same goes for ACLs.  In the IMAP case the relevant ACLs are those
which apply for the authzid, and being an lmtp_admin (rather than an
(imap(s)_)admin) doesn't grant any special rights in this case.  In the
LMTP case, the there are multiple cases to consider:

For delivery to a user, the ACLs outside of the user's private IMAP
space (INBOX and children) which need to be considered are those for the
user, since they control where a sieve script may put mail exactly as
the ACLs in the IMAP case control what the MUA may do.  For delivery to
a shared folder, you have the case where you use a postuser - in which
case the ACLs for the postuser apply - and the the case where you use an
authenticated sender, in which case you can create ACLs by sender...

You're doing the last of these, which is the most complex.


AB> Do I need to pass authenticated_sender = exim to lmtp for all
AB> cases except when I have an SMTPA sender?

I don't think so.  If the SMTP transaction is not authenticated, Exim
should not add the "AUTH=" cause to the MAIL line, and should pass an
empty authzid when it does its LMTP AUTH.


AB> Do I also need to grant 'p' rights to exim on users' INBOXes?

That right is implicit in being able to do lmtp at all - or, if you
prefer, it's the receiving user's ACL which counts here.


AB> I'm not really clear why it is sometimes failing and sometimes
AB> succeeding in the non shared folders case.

I think you need to find some examples of working and not working, and
log exactly what Exim is saying to lmtpd.  Then you can figure out
whether Exim's correct and lmtpd is broken, or lmtpd is doing the Right
Thing in response to something weird coming in from Exim.


Cheers


Duncan

-- 
Duncan Gibb - Technical Director
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk/ || t: +44 870 608 0063
Debian Cyrus Team - https://alioth.debian.org/projects/pkg-cyrus-imapd/