Hi,
Anybody had an success in getting Iworx qmail to use a smarthost.
I’ve tired the following with no success:
Updated /var/qmail/control/smtproutes with the correct route to smarthost “domain.com:SMARTHOST:587”
and have restarted all smtp services. The route is listed on the MTA configuration page in SMTP routes correctly. However, emails for the rerouted domain are still being processed and delivered by qmail and not the remote mailserver.
Anyone any suggestions?
Cheers,
Hi Alan
Have you tried on port 25 standard.
I’m wondering if TLS is the failure as I thought it went out on 25 then upgraded.
Many thanks
John
[QUOTE=d2d4j;27116]Hi Alan
Have you tried on port 25 standard.
I’m wondering if TLS is the failure as I thought it went out on 25 then upgraded.
Many thanks
John[/QUOTE]
Hi John,
I haven’t tried it on 25, as the port specified (587) is the incoming port on the remote server, which is the only port that will accept connections (it’s an outbound spam filtering service I’m testing). According to various pieces of qmail documentation, it should work.
Thanks for your input though
cheers,
Alan
Hi Alan
Many thanks, just one other quick thought though, do you have port 587 fully open.
Please can you check from external telnet, as the IW firewall shows as open but infact, is not open.
Many thanks
John
Hi John,
Thanks, I’ve figured it out now. I was being dumb…
What I was trying to achieve isn’t possible with smtproutes. I was trying to send outbound messages FROM a domain to the smarthost for filtering, but of course smtproutes is concerned about the receiving domain, and not the sending domain. Doh!
Hi Alan
Sorry, you were correct in your first posting and your last post is wrong.
Smtp routes is concerned with sending email only
If you give me 5 minutes, I’ll post my test which works lovely, and in port 587.
I hope that helps
Many thanks
John
Hi Alan
Please see below for the results of my test for smarthost, which I used port 587.
I think you may need to authenticate, unless on the smarthost you have been accepted as non authenticated, i.e. no credentials are needed (I know on our enterprise mailers, we can allow this, but for this test, we did IW to IW for smarthost, which needed authentication).
my smarthost code was as follows:
forwardtodomain.url:IW-CP Server 2:587 username password
I hope that helps a little and sorry if it is hard to follow, I was trying to change all live details, whilst keeping it easy to follow.
Many thanks
John
IW-CP Server 1 (1 domain set for smarthost relay to IW-CP Server 2)
2015-02-24 16:08:29.301100500 new msg 3964272015-02-24 16:08:29.301102500 info msg 396427: bytes 2653 from <me@forwardtodomain.url> qp 5668 uid 108 2015-02-24 16:08:29.317041500 starting delivery 1: msg 396427 to remote me@seconddomain.url2015-02-24 16:08:29.317055500 status: local 0/10 remote 1/2552015-02-24 16:08:30.191073500 delivery 1: success: SMARTHOST-IP_accepted_message./Remote_host_said:_250_ok_1424794110_qp_13956/2015-02-24 16:08:30.191172500 status: local 0/10 remote 0/2552015-02-24 16:08:30.191205500 end msg 396427
IW-CP Server 2 (smarthost relay for 1 domain from IW-CP Server 1)
2015-02-24 16:08:30.177985500 info msg 2884375: bytes 3076 from <me@forwardtodomain.url> qp 13966 uid 108 2015-02-24 16:08:30.179418500 starting delivery 4935: msg 2884375 to remote me@seconddomain.url2015-02-24 16:08:30.179420500 status: local 0/10 remote 1/2552015-02-24 16:08:30.250021500 delivery 4935: success: RECEIVING-IP_accepted_message./Remote_host_said:_250_OK/2015-02-24 16:08:30.250023500 status: local 0/10 remote 0/255
Email was confirmed as received
Return-Path: <me@forwardtodomain.url>
Received: from seconddomain.url (ns1.seconddomain.url [IW-CP Server 2]) by mail.RECEIVING-IP with SMTP;
Tue, 24 Feb 2015 16:08:35 +0000
Received: (qmail 13966 invoked by uid 108); 24 Feb 2015 16:08:30 +0000
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on seconddomain.url
X-Spam-Level:
X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,HTML_MESSAGE,
MIME_HTML_MOSTLY autolearn=ham version=3.3.1
Received: from unknown (HELO mail.forwardtodomain.url) (me@seconddomain.url@IW-CP Server 1)
by sentmail.co.uk with ESMTPSA; 24 Feb 2015 16:08:29 +0000
Received: (qmail 5668 invoked by uid 108); 24 Feb 2015 16:08:29 +0000
Received: from unknown (HELO mypc) (192.168.1.74)
by 3sh.co.uk with ESMTPS; 24 Feb 2015 16:08:29 +0000
Reply-To: <me@forwardtodomain.url>
From: <me@forwardtodomain.url>
To: <test@test.test>
Subject: test ol2
Date: Tue, 24 Feb 2015 16:08:25 -0000
Organization:
Message-ID: <045401d0504c$1ec5f210$5c51d630$@co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0455_01D0504C.1EC5F210"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AdBQTBo/LxlB1+XmT56Al6vWBYfLzA==
Content-Language: en-gb
X-Antivirus: avast! (VPS 150223-1, 23/02/2015), Outbound message
X-Antivirus-Status: Clean
X-SmarterMail-TotalSpamWeight: 0 (Authenticated)
X-Antivirus: avast! (VPS 150223-1, 23/02/2015), Inbound message
X-Antivirus-Status: Clean
Hi John,
Thanks for persevering with this.
My understanding of the smtproutes in qmail is that it allows you to reroute outbound emails that are being sent to the specified domain, but it doesn’t let you reroute email originating from a particular domain. For example:
lets say I have the following in smtproutes
gmail.com:anotherserver.com:587 username password
then I send the following email from someone@mydomain.com to someone-else@gmail.com
When my server sees the my email to the @gmail address, because it’s in the smtp routes, it’ll bypass any mx check of gmail.com, and simply relay that to anotherserver.com on port 587.
The above works as designed, I’ve just tried that exact example. It did indeed route the outbound email to the smarthost, which in turn delivered it to the gmail address.
It’s interesting that you have managed to do it as per your example where you rerouted the FROM domain’s emails to the smarthost, as I have tired and it doesn’t work, but I don’t think it should work.
The interworx manual: http://docs.interworx.com/nodeworx/email/index-Configuring-Mail-Transfer-Agent.php also leads me to believe that smtproutes is concerned with where the email is going, rather than where it originated from, as you wouldn’t perform an mx lookup for the sending domain, but only for the recipients domain.
Hi Alan
Many thanks and it may be me that’s misunderstanding but I thought with smtp routes, it just relays if it the sender domain is listed in routes, not the receiving domain and the mx lookup is completed by the smarthost server.
I’m sorry if I’m wrong, I’ll have to reread and think a little more, as it does sound confusing.
Many thanks
John
Yeah, this is dead on. Doesn’t matter if the email originates somewhere else or on your InterWorx server. The email just needs to sent to your server to get delivered. Then like you said it bypasses the MX lookup and forwards it on as specified in the SMTP routes.
The only possible issue is if you have that particular domain accepting email on your server, that takes precedence. I have a unique setup for a domain I host on my server. I actually went in and setup inboxes for accounts, then I disabled the email for this account (or enabled remote delivery depending on if you are glass half full or empty :D). So if for any reason my exchange server goes down, I can enable email on my server and it will accept emails and not forward them on. Then I can disable again and go back to normal.
Hi justec
Excellent, I never thought of using it that way.
I suppose it might be an alternative as well if running in that setup, and your smarthost becomes blacklisted etc… Although, it maybe easier just to change ip addresses
Many thanks
John