Hi folks,
We have our SME7.6 server-gateway configured to delegate email to our internal exchange server. It does this very well and acts as a first line virus/spam filter so our exchange servers AV/spam system sees very little rubbish.
We also have the trac and svn contribs on our SME box, again they work as expected for our internal projects.
Now to the problem : We recently started a new project and needed to allow the customer access to SVN and trac. We created a user account for the customer on our SME box with 'email delivery' set to forward to their own email address and enabled the SVN and trac for external access. All works as expected except, notification emails from trac do not get to the customer.
I think I have tracked down why and am asking for some help in fixing it.....
The reason is down to the qpsmtpd 'check_smtp_forward' plugin. Because we have email delegated to our internal exchange server the SME box is using the 'check_smtp_forward' plugin to verify email addresses before accepting email for delivery. When trac tries to send an email to the customer, initially it uses the address 'thecustomer@mydomain.co.uk' (I assume the forwarding would take place later once the email has been accepted) and because the customer does not have an account on our exchange server (only the SME server), when the 'check_smtp_forward' plugin asks our exchange server if it would accept the mail it says no, and the email is dropped.
I can see this happening in /var/log/qpsmtpd/current:
@400000005126275828a87474 26990 Accepted connection 0/40 from 127.0.0.1 / localhost
@400000005126275828aa9b3c 26990 Connection from localhost [127.0.0.1]
@400000005126275828d091fc 26990 tls plugin (init): ciphers: HIGH:!SSLv2
@40000000512627582937c3f4 26990 220 myserver.mydomain.co.uk ESMTP
@400000005126275829d45dcc 26990 dispatching ehlo myserver.mydomain.co.uk
@400000005126275829e84b5c 26990 250-mydomain.co.uk Hi localhost [127.0.0.1]
@400000005126275829e8ff0c 26990 250-PIPELINING
@400000005126275829e9937c 26990 250-8BITMIME
@400000005126275829ea2bd4 26990 250-SIZE 26214400
@400000005126275829eabc5c 26990 250 STARTTLS
@400000005126275829fdac04 26990 dispatching mail FROM:<trac@mydomain.co.uk> size=2410
@40000000512627582a00ad8c 26990 full from_parameter: FROM:<trac@mydomain.co.uk> size=2410
@40000000512627582a0f76b4 26990 getting mail from <trac@mydomain.co.uk>
@40000000512627582a1070b4 26990 250 <trac@mydomain.co.uk>, sender OK - how exciting to get mail from you!
@40000000512627582a15e33c 26990 dispatching rcpt TO:<thecustomer@mydomain.co.uk>
@40000000512627582a9008c4 26990 logging::logterse plugin (deny): ` 127.0.0.1 localhost myserver.mydomain.co.uk <trac@mydomain.co.uk> check_smtp_forward 901 Unable to queue message (5.1.1 User unknown) msg $
@40000000512627582a91a2ec 26990 550 Unable to queue message (5.1.1 User unknown)
@40000000512627582a94ac44 26990 dispatching rset
@40000000512627582a96948c 26990 250 OK
I don't think this is a problem with the trac contrib, but more with the way SME and contribs interact when using delegated email.
Once possibility would be to create a user account for the customer on our exchange server but this would cause problems elsewhere so I would like to avoid this.
I think one solution would be to modify the 'check_smtp_forward' plugin to check if the user exists in the SME servers user list first before checking the exchange server. Possibly even more strict would be to check IF (the user exists on the SME server AND has mail redirection set to a non-local domain) THEN accept the email ELSE check the Exchange server.
I have looked at the code in /usr/share/qpsmtpd/plugins/check_smtp_forward but not being a perl programmer it is a bit beyond me.
Any thoughts?
Regards, Mark Leman
P.S I am happy to raise this as a bug in the bug tracker if this problem is considered generic enough to deserve it.