Delivery to Shared Folders via authenticated SMTP then LMTP

[Andy Bennett]

Hi,

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).

I do.
<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.

...but anyway.

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) [91.194.74.36] 
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 
from bounces.

However, I eventually noticed legitimate ones 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
-----

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.




Regards,
@ndy

-- 
andyjpb at ashurst.eu.org
http://www.ashurst.eu.org/
http://www.gonumber.com/andyjpb
0x7EBA75FF