Koozali.org formerly Contribs.org

Contribs.org Forums => SME Server 9.x => Topic started by: Drifting on July 29, 2018, 08:42:20 AM

Title: Reply to an alias causes the server to deny relaying?
Post by: Drifting on July 29, 2018, 08:42:20 AM
Hi all.

Odd problem has reared its head since telling the server to stop double bounces. (Re Wiki)

Customer has an email of fred@fred.co.uk on the sme, customer has a crm product that sends email directly to the ISP's smarthost (so does the main SME mail server) However the sending email address from the CRM is fred.smith@fred.co.uk.
Fine so far, email getting delivered fine to a recipient.
Now the problem, when the recipient replies to the fred@fred.co.uk it is sent and received fine, however with they try to reply to the one sent from the CRM SME says relaying denied, and bounces it? The alias is right for the fred.smith as well as the fred? Confused why this should be happening?

Suggestions??

Paul.
Title: Re: Reply to an alias causes the server to deny relaying?
Post by: Drifting on August 01, 2018, 01:07:59 PM
Anyone any idea on this? we are getting an enormous amount of email rejected as relaying denied from the SME box. This has only happened since stopping the server doing the double bounces, as we were bombarded with those.

Paul.
Title: Re: Reply to an alias causes the server to deny relaying?
Post by: mmccarn on August 01, 2018, 02:53:33 PM
I couldn't figure out from your original post what the current situation is ("sending address is fred.smith@fred.co.uk" / "replies to the fred@fred.co.uk")

/var/log/qpsmtpd/current should tell you what is actually happening when the "relaying denied" event occurs.

Here's a log extract from my system for a spam email denied by "relaying denied":
Code: [Select]
# grep "relaying denied" /var/log/qpsmtpd/current
@400000005b579c250d30ee24 15219 (deny) logging::logterse: ` 217.79.184.109 mail.bigcitylife.co.ua mail.bigcitylife.co.ua <yclyzfc@bigcitylife.co.ua> check_goodrcptto 901 relaying denied alerts-acu@obfuscated.us msg denied before queued
@400000005b579c250d39b824 15219 550 relaying denied alerts-acu@obfuscated.us

The second field in these log entries is the "connection ID"; you can review an entire email conversation from the sender's first connection until the email is dispositioned by searching qpsmtpd/current for the connection ID:
Code: [Select]
# the command below gets the connection ID of the latest "relaying denied" instance
# then searches for that in /var/log/qpsmtpd/current
# and converts the TAI timestamp to a human-readable date and time
#
grep $(grep "relaying denied" /var/log/qpsmtpd/current |awk '{print $2}' |tail -1) /var/log/qpsmtpd/current |tai64nlocal
Quote from: command output on my system
2018-07-24 17:37:25.252967500 15219 Accepted connection 0/40 from 217.79.184.109 / mail.bigcitylife.co.ua
2018-07-24 17:37:25.256029500 15219 Connection from mail.bigcitylife.co.ua [217.79.184.109]
2018-07-24 17:37:27.221461500 15219 (connect) earlytalker: pass, not spontaneous
2018-07-24 17:37:27.226854500 15219 (connect) relay: skip, no match
2018-07-24 17:37:28.909732500 15219 (connect) dnsbl: pass
2018-07-24 17:37:28.913638500 15219 220 office.obfuscated.us ESMTP
2018-07-24 17:37:29.002447500 15219 dispatching EHLO mail.bigcitylife.co.ua
2018-07-24 17:37:29.061317500 15219 (ehlo) helo: pass
2018-07-24 17:37:29.065886500 15219 250-obfuscated.us Hi mail.bigcitylife.co.ua [217.79.184.109]
2018-07-24 17:37:29.065993500 15219 250-PIPELINING
2018-07-24 17:37:29.066198500 15219 250-8BITMIME
2018-07-24 17:37:29.066493500 15219 250-SIZE 15000000
2018-07-24 17:37:29.066715500 15219 250-STARTTLS
2018-07-24 17:37:29.066932500 15219 250 AUTH PLAIN LOGIN
2018-07-24 17:37:29.156888500 15219 dispatching MAIL FROM:<yclyzfc@bigcitylife.co.ua> SIZE=996964
2018-07-24 17:37:29.171571500 15219 (mail) greylisting: pass: timed out (grey)
2018-07-24 17:37:29.586200500 15219 (mail) resolvable_fromhost: pass, bigcitylife.co.ua has MX at mail.bigcitylife.co.ua
2018-07-24 17:37:30.955534500 15219 (mail) rhsbl: pass
2018-07-24 17:37:31.200611500 15219 (mail) sender_permitted_from: karma 1 (1)
2018-07-24 17:37:31.201068500 15219 (mail) sender_permitted_from: pass, bigcitylife.co.ua: 217.79.184.109 is authorized to use 'yclyzfc@bigcitylife.co.ua' in 'mfrom' identity (mechanism 'a/24' matched)
2018-07-24 17:37:31.201896500 15219 (mail) naughty: pass
2018-07-24 17:37:31.204829500 15219 250 <yclyzfc@bigcitylife.co.ua>, sender OK - how exciting to get mail from you!
2018-07-24 17:37:31.206408500 15219 dispatching RCPT TO:<alerts-acu@obfuscated.us>
2018-07-24 17:37:31.213701500 15219 (rcpt) badrcptto: pass
2018-07-24 17:37:31.214387500 15219 (rcpt) check_goodrcptto: stripping '-' extensions
2018-07-24 17:37:31.219739500 15219 (rcpt) check_goodrcptto: recipient alerts-acu@obfuscated.us denied
2018-07-24 17:37:31.221310500 15219 (deny) logging::logterse: ` 217.79.184.109   mail.bigcitylife.co.ua   mail.bigcitylife.co.ua   <yclyzfc@bigcitylife.co.ua>      check_goodrcptto   901   relaying denied alerts-acu@obfuscated.us   msg denied before queued
2018-07-24 17:37:31.221886500 15219 550 relaying denied alerts-acu@obfuscated.us
2018-07-24 17:37:31.223336500 15219 dispatching DATA
2018-07-24 17:37:31.225608500 15219 503 RCPT first
2018-07-24 17:37:31.444889500 15219 dispatching RSET
2018-07-24 17:37:31.445731500 15219 250 OK
2018-07-24 17:37:31.447113500 15219 dispatching QUIT
2018-07-24 17:37:31.448504500 15219 221 obfuscated.us closing connection. Have a wonderful day.
2018-07-24 17:37:31.448871500 15219 click, disconnecting
2018-07-24 17:37:32.230242500 2444 cleaning up after 15219


Is "fred.co.uk" configured as a local domain on the SME?  (If not, the SME will consider this email as needing to be "forwarded", and will deny it unless the inbound connection is authenticated):
Code: [Select]
db domains show fred.co.uk
Is "fred.smith" actually configured as a Pseudonym on your system? You can check the status at the command prompt using
Code: [Select]
db accounts show fred.smith
(There is no pseudonym on my SME server for "michael.mccarn", for example...)

Is DNS configured as you expect -- both internally and externally? (or... is the "relaying denied" message coming form your SME server or from the external smarthost?):
Code: [Select]
#internal DNS:
nslookup -type=mx fred.co.uk

# external DNS
nslookup -type=mx fred.co.uk 8.8.8.8
Title: Re: Reply to an alias causes the server to deny relaying?
Post by: Drifting on August 02, 2018, 11:43:10 AM
Wow what a fantastic response.

I only used fred to protect the innocent ;-) Or dumb (me)

Perhaps I did not explain very well. fred@fred.co.uk is local, and it is hosted on the SME as the main domain fred.co.uk
there is a Pseudonym fred.smith which goes to user@fred.co.uk

There is a CRM that sends out email directly to the ISP smarthost (Who allows relaying if you are on one of their IP's)
This was setup by the company who supplied and support it.

If I email directly from an external email address, fred or fred.smith works. And so do replies playing email tennis.
However when the CRM sends and email, with the sender as fred.smith@fred.co.uk the email arrives, but when the recipient tries to reply they get bounced?

Did that make any more sense?

Will work my way through what you have suggested and get back to you. Thank you so much for taking the time to give such a through reply.

Best wishes Paul
Title: Re: Reply to an alias causes the server to deny relaying?
Post by: mmccarn on August 02, 2018, 02:46:16 PM
There is a CRM that sends out email directly to the ISP smarthost (Who allows relaying if you are on one of their IP's)
This was setup by the company who supplied and support it.

If I email directly from an external email address, fred or fred.smith works. And so do replies playing email tennis.
However when the CRM sends and email, with the sender as fred.smith@fred.co.uk the email arrives, but when the recipient tries to reply they get bounced?

That sounds like either the "From" or "Reply-To" address specified by the CRM is not what you think it is...

If everything is configured correctly, the qpsmtpd log should tell you what's going on.

Or look at the source for one of the CRM-generated emails to see what it says for "From" and "Reply-To".  "From" is what you SEE in your email client, but "Reply-To", if present, is where replies get sent by all modern email clients.  If your CRM is using a coded "Reply-To" like the example I found below in my Inbox, you'll need to figure out how to get those replies accepted by your mail server.

Quote from: sample email showing different "From" and "Reply-To" headers
Return-Path: <bounce-vmvfrhgkgrnmvfmnyympjbkfrzqgkjqqdjmrrygvjcvmkvgp@email.dandb.com>
Delivered-To: MMCCARN@office.obfuscated.us
Received: (qmail 12207 invoked by alias); 30 Nov 2016 18:33:11 -0000
Delivered-To: alias-localdelivery-MMCCARN@obfuscated.US
Received: (qmail 12204 invoked by uid 453); 30 Nov 2016 18:33:11 -0000
X-Spam-Level: *
X-Spam-Status: No, hits=-0.2 required=4.0
        tests=AWL,BAYES_50,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,MIME_QP_LONG_LINE,NUMERIC_HTTP_ADDR,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS
X-Spam-Check-By: obfuscated.us
Received: from mail5.email.dandb.com (HELO mail5.email.dandb.com) (96.46.132.141)
    by obfuscated.us (qpsmtpd/0.84) with (AES256-SHA encrypted) ESMTPS; Wed, 30 Nov 2016 13:33:08 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=class; d=email.dandb.com;
 h=From:Reply-To:To:Message-ID:Subject:MIME-Version:Content-Type:list-unsubscribe:Date; i=email@email.dandb.com;
 bh=t6F6B/8DyMoXdTeUmoR6ZIYT1Pw=;
 b=A/aPmWwZKyKhftkIXKSfPYobYVCm+RbHQ+pU7jAXAvDxN8ixwwqFra8TTIVZaU0IMBFIye5tlCwl
   NEm9hgP8YPVwSxUrzPbwh41jFR2VNk/kMHGj834unC6lprQbeFXY4w2wdAD4ISUcgR4Vbz530rmg
   5FhKtaPtZsplcJ/+3zc=
DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=class; d=email.dandb.com;
 b=qXpk1aDdofmdQ5fwC/RWsNeKhwZU6djoveH+cZX6IsNzB8u593WZ2mU49DySBjGuv0NVxmZldmcz
   uXtSvH48mlKxFf0TmC5lc7WlssOLDoa2hE5CFQ/igSURb24MbdF+M2QyNfEHWdnKRwaqnA+PpC6m
   u+Y99/6Y4tDsgUudwWM=;
Received: by mail5.email.dandb.com id h7sdmc282akb for <MMCCARN@obfuscated.US>; Wed, 30 Nov 2016 12:31:00 -0600 (envelope-from <bounce-vmvfrhgkgrnmvfmnyympjbkfrzqgkjqqd
From: Dun & Bradstreet <email@email.dandb.com>
Reply-To: Dun & Bradstreet <r-1056460-8218-99837D410CA647AAB78009627E284263@email.dandb.com>
To: "Business Executive" <MMCCARN@obfuscated.US>
Message-ID: <1299929928.6459238.1480530659983.JavaMail.root@email.dandb.com>
Subject: obfuscated, inc, let us help you get better email results
MIME-Version: 1.0
Content-Type: multipart/alternative;
        boundary="----=_Part_6459237_1229248184.1480530659982"
X-DANDB: pymhfycdhjhdvbhqhbljjdqhcfc vvdjctyhfkrlycrrwcdffvlqcgqdyqljbhfmlylfbdqhd hldhljydvl
X-rpcampaign: jjidhdebm00000082180000002902
list-unsubscribe: <mailto:unsub-1056460-8218-99837D410CA647AAB78009627E284263@email.dandb.com>
Date: Wed, 30 Nov 2016 12:31:00 -0600
X-Virus-Checked: Checked by ClamAV on obfuscated.us