Topic: Problem with email w/Delegate mail servers, check_smtp_forward and Trac contrib

[markleman]

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:

Code: [Select]

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

[markleman]

The plot thickens....

I had a dig in  /usr/share/qpsmtpd/plugins/check_smtp_forward and learnt a bit of perl and added a horrible kludge modification to test the point.

Code: [Select]

......
sub hook_rcpt {
  my ($self, $transaction, $recipient) = @_;
  my $host = lc $recipient->host;

  my $server = $self->{_smtp_host}{$host} or return (DECLINED);
  my $port;

# start of kludge
  if ( $recipient eq "<customer\@mydomain.co.uk>" )
   {
      $self->log(LOGINFO, "Exception to qpsmptd check_smtp_forward for recipient $recipient");
      return DECLINED;      # on the kludged white list so accept email
   }
#end of kludge

  ($server, $port) = split(/:/, $server);
  $port ||= 25;
........

So now SME accepts the email from the trac contrib to customer@mydomain.co.uk and SME then tries to deliver it. But because email has been delegated to the internal exchange box, it would appear that SME is not looking up the forwarding address and just sending it to the exchange server which is correctly rejecting it. Looking in /var/log/qmail/current I can see the failed attempts to send mail to customer@mydomain.co.uk.

So it looks like I may out of luck here, the problem I have identified may not be easily solvable. If a contrib sends emails on a SME server with a delegated email server and wants to send email to an external address then it will not arrive.

Regards, Mark Leman

[axessit]

I'm no expert here, but a couple of things to possibly try. Bear in mind email sending is different from email receiving.
1) Do normal admin messages from the SME server go to the Exchange system (eg ClamAV alerts) or do they just sit in the SME server ? Can you log into the SME webmail as admin user, and send an email outside your domain, like a hotmail/gmail account ? This would prove the email delivery is not just limited to the contrib, but is more the email sending side (delegating email reception is the job of the Exchange server).
2) Check your email smtp settings - do they go to the internal Exchange server or can you set them to the ISP. the Exchange server has it's own SMTP settings that will dictate how that sends email - have you got the email Proxy enabled in SME ?

You might want to configure your exhange to allow relaying from just your SME host.

[Knuddi]

The problem is that the redirect is not done by qpsmtpd but qmail afterwards and this is not (as far as I know) done when server is in delegate mode.

[CharlieBrady]

The problem is that the redirect is not done by qpsmtpd but qmail afterwards and this is not (as far as I know) done when server is in delegate mode.

Correct. You could do recipient rewriting in qpsmtpd via a custom plugin.