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@xxxxxxxxxxxxxx> AUTH=<andyjpb@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx> > temporarily rejected RCPT <andyjpb@xxxxxxxxxxxxxx>: 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/ ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
