Delivery to Shared Folders via authenticated SMTP then LMTP
andyjpb at ashurst.eu.org
Tue Apr 21 12:28:12 EDT 2009
Thanks for your reply.
> 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).
<authzid> is exim.
> 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 at ashurst.eu.org> AUTH=<andyjpb at ashurst.eu.org>
Yes... I think that's what I'm looking for.
A review of the logs shows that when I was passing authorisation with
client_send = $authenticated_sender^exim^<PASSWORD>
I was getting
cyrus/lmtp[<PID>]: login: <MTA.HOSTNAME> [<MTA.IP>]
<$authenticated_sender> PLAIN User logged in
instead of the "exim" one above.
Something more sinister is wrong.
I thought that messages were being delivered correctly in non shared
folders scenarios because every test message I sent from external
relays, such as gmail, were being received. However, the logs show
things like this
1 /var/log/exim4/rejectlog:2009-04-21 16:35:21
H=cp-dublin.purplecloud.com (mx01-dublin.purplecloud.com) [184.108.40.206]
F=<andyjpd at btopenworld.com> temporarily rejected RCPT
<andyjpb at ashurst.eu.org>: response to "MAIL FROM:<>" from localhost
[127.0.0.1] was: 430 Authentication required
At first I thought that this was just for illegitimate mail that wasn't
specifying MAIL FROM: properly; I get a lot of spam that is backscatter
However, I eventually noticed legitimate ones such as traffic to this list
2009-04-21 15:10:27 H=mx2.andrew.cmu.edu [220.127.116.11]
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
Your reply went to the list and directly to me: the direct one came
through but the one from mailman got stuck between my smtp and lmtp
servers and was therefore temporarily rejected.
For now, I've gone back to using lmtp in "lmtp -a" mode and it seems to
have fixed things... Hopefully all the temporarily rejected mail will
start to come through in the next few hours.
However, I'm not ready to give up on getting authenticated lmtp and then
shared folder delivery working.
Why do different things happen when running "lmtp -a" compared to "lmtp"
and logging in as an lmtp_admin?
> To do that you probably want to add
> authenticated_sender = $authenticated_id
> to the definition of your lmtp relay.
I'll give that a go just as soon as I've fixed the normal delivery, thanks.
It appeals to my common sense that the two problems are related: Do I
need to pass authenticated_sender = exim to lmtp for all cases except
when I have an SMTPA sender? Do I also need to grant 'p' rights to exim
on users' INBOXes?
I'm not really clear why it is sometimes failing and sometimes
succeeding in the non shared folders case.
> You can check Cyrus is doing what you expect by using openssl s_client
> or gnutls-cli to have a manual LMTP conversation with it:
> <- 220 your.cyrus.box LMTP Cyrus v2.3.13-Sirius-2009:2.3.13-5 ready
> -> lhlo authtest
> <- 250-your.cyrus.box
> <- 250-[..]
> <- 250-AUTH PLAIN LOGIN
> -> auth plain base64.nonsense.or.go.back.to.cram-md5
> <- 235 Authenticated!
> -> mail from:<arbitrary at mail.addr> AUTH=<andyjpb at ashurst.eu.org>
> <- 250 2.1.0 ok
> -> rcpt to:<+shared.test at ashurst.eu.org>
> <- 250 2.1.5 ok
> -> data
> <- 354 go ahead
Yeah. I might try that... Although I told exim to avoid TLS with the
LMTP server for now so that I might debug it and so I might be able to
just telnet to the lmtp port.
Thanks for your help.
andyjpb at ashurst.eu.org
More information about the Info-cyrus