Hi, I've managed to get things working now. >> 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? You were right: it was an exim problem. When I switched from preauth'd LMTP to LMTPA I couldn't do callforwards from exim to see if the recipient mailbox existed. This is because exim doesn't bother with the auth during the callforward and was therefore getting the "430 Authentication required" messages. I think it was working when I sent my test mails it because exim can cache the results of a callforward and I was testing from a limited number of accounts. > 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... I agree and that's why I was trying to move to an authenticated lmtp set up. > 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. No, I was talking about the "cyrus/lmtp: login: <host> [<ip>] exim CRAM-MD5 User logged in" messages. > 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. Thanks. As explained above, exim was doing callforwards without authentication and so mail was being deferred at that stage. > You should have lines in syslog (/var/log/maillog) from lmtpd of the form > > cyrus/lmtp[<PID>]: login: <MTA.HOSTNAME> [<MTA.IP>] <authzid> > <SASL.MECH> User logged in > > The authzid there will be the user as whom Exim authorized. But I don't > think that's the problem (see below). > > AB> client_send = $authenticated_sender^exim^<PASSWORD> > > AB> I think that should send the exim authenticated sender along > AB> as the authorisation and exim and <PASSWORD> along as the > AB> authentication. > > It should, but not in the way you want. The SASL authzid isn't what > lmtpd evaluates ACLs against. To do what I think you want (ACLs for > delivery to shared mailboxes by users employing SMTPA), you need Exim to > pass the authenticated user from the SMTP transaction with the MUA into > the _MAIL_ line of the LMTP conversation. You want Exim to say: > > MAIL FROM:<andyjpb@xxxxxxxxxxxxxx> AUTH=<andyjpb@xxxxxxxxxxxxxx> > > To do that you probably want to add > > authenticated_sender = $authenticated_id > > to the definition of your lmtp relay. I'm getting <authzid> = exim even when I'm setting authenticated_sender = $authenicated_id so it looks like it's putting the authentication ID there, not the authorisation id. Anyway, it's now respecting the ACLs of the user that authenticated to SMTP so I'm happy. Setting authenticated_sender = $authenticated_id doesn't seem to do any harm when the SMTP connection is not authenticated so it works for external mail to regular inboxes as well. I've had to ditch the callforwards but I didn't want to blindly accept mail for my domains and then have to bounce undeliverable mail later so I'm now generating lists of INBOXes that I can check against during the "RCPT TO" phase. I'll probably need to turn these into maps if I add another cyrus server so that I know where to route mail for different local parts. Many thanks for all your help. Regards, @ndy -- andyjpb@xxxxxxxxxxxxxx http://www.ashurst.eu.org/ http://www.gonumber.com/andyjpb 0x7EBA75FF ---- 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
