domain appended to 553 errors

[boxyball]

When a user misspells an email address, it bounces back with the local domain appended to the email address.
It only does this from roundcube, not from a mail client like Thunderbird.
For example, if I send to blah@blahblahblah.com ... the 553 rejection comes back as blah@blahblahblah.com.mydomain.com
How can I fix so that it only shows the original address without the append?

Thanks in advance.

[JohnDoh]

i dont think thats normal. is your roundcube configured to send messages via smtp or php? also check the address set in your identity.

[boxyball]

My identity is name <names@mydomain.com>

Where would I check to see if I am using smtp or php to send?

[JohnDoh]

that is defined in your roundcube config

[boxyball]

I figured that.  It was the first place I looked but I could not find a setting that fits what you describe.
Would you happen to know the name of the setting?

[JohnDoh]

the config option is smtp_server but I was just rereading your original post and I might have been pointing you in the wrong direction.

is it your address (as in the sender) that gets altered or the recipients address? if its the recipients address then I could be your smtp server that's changing it rather than roundcube.

if you are using an smtp server to send messages from roundcube, rather than php mail() then you can enable smtp_debug in your roundcube config and it will log the conversation between roundcube and your server when the message is sent. then you can check that log to see if the addresses are correct there. if they are, then you know its being changed later by the smtp server.

[boxyball]

It is the recipient address that is being altered.
I am not using a separate smtp server to send.
My setting looks like this in defaults.inc.php:
$config['smtp_server'] = '';

[JohnDoh]

and its not set in config.inc.php?

if smtp_server is left blank then PHP mail() is used. I suggest that you change your config to use an smtp server instead and see if the problem persists.

Also support for PHP mail() is being dropped in Roundcube 1.3.

[boxyball]

roundcube is running on the mail server, so which do you recommend?
$config['smtp_server'] = 'localhost';
or
$config['smtp_server'] = 'smtp.domain.com';

[JohnDoh]

personally i'd use localhost

[boxyball]

I changed my config to ...
$config['smtp_server'] = 'localhost';
... and restarted apache and the problem remains.

I sent to blah@blahblah.blah and got the following error:

Reporting-MTA: dns; mydomain.com
Received-From-MTA: DNS; localhost
Arrival-Date: Mon, 20 Feb 2017 11:38:14 -0600

Final-Recipient: RFC822; blah@blahblah.blah.mydomain.com
Action: failed
Status: 5.3.5
Diagnostic-Code: SMTP; 553 5.3.5 system config error
Last-Attempt-Date: Mon, 20 Feb 2017 11:38:15 -0600

This error does not occur if a bad email address is used in a client like Thunderbird ... it only happens with roundcube.
You can test by sending to an invalid domain.

[JohnDoh]

it seems more like an smtp server issue to me than roundcube - unless you are running some roundcube plugin that's changing the recipient address.

like I suggested before if you enable smtp_debug in your roundcube config then a log of the conversation with the smtp server will be written in the roundcube logs folder and there you will see for sure if it was roundcube sending getting it wrong and if its not then it must be the smtp server.

you I understand that the same thing does not happen from thunderbird but I think that still does not rule the smtp server completely as it might handle messages that are sent locally and remotely differently.

[boxyball]

I turned on logging.
Below are the contents.
Everything looks pretty normal.

[20-Feb-2017 16:34:38 -0600]: <viu6c26n> Recv: 220 mydomain.com ESMTP Sendmail 8.15.2/8.15.2; Mon, 20 Feb 2017 16:34:38 -0600
[20-Feb-2017 16:34:38 -0600]: <viu6c26n> Send: EHLO mydomain.com
[20-Feb-2017 16:34:38 -0600]: <viu6c26n> Recv: 250-mydomain.com Hello localhost [127.0.0.1], pleased to meet you
[20-Feb-2017 16:34:38 -0600]: <viu6c26n> Recv: 250-ENHANCEDSTATUSCODES
[20-Feb-2017 16:34:38 -0600]: <viu6c26n> Recv: 250-PIPELINING
[20-Feb-2017 16:34:38 -0600]: <viu6c26n> Recv: 250-8BITMIME
[20-Feb-2017 16:34:38 -0600]: <viu6c26n> Recv: 250-SIZE
[20-Feb-2017 16:34:38 -0600]: <viu6c26n> Recv: 250-AUTH GSSAPI
[20-Feb-2017 16:34:38 -0600]: <viu6c26n> Recv: 250-STARTTLS
[20-Feb-2017 16:34:38 -0600]: <viu6c26n> Recv: 250-DELIVERBY
[20-Feb-2017 16:34:38 -0600]: <viu6c26n> Recv: 250 HELP
[20-Feb-2017 16:34:38 -0600]: <viu6c26n> Send: MAIL FROM:<myaddress@mydomain.com>
[20-Feb-2017 16:34:38 -0600]: <viu6c26n> Recv: 250 2.1.0 <myaddress@mydomain.com>... Sender ok
[20-Feb-2017 16:34:38 -0600]: <viu6c26n> Send: RCPT TO:<blah@blahblah.blah>
[20-Feb-2017 16:34:38 -0600]: <viu6c26n> Recv: 250 2.1.5 <blah@blahblah.blah>... Recipient ok
[20-Feb-2017 16:34:38 -0600]: <viu6c26n> Send: DATA
[20-Feb-2017 16:34:38 -0600]: <viu6c26n> Recv: 354 Enter mail, end with "." on a line by itself
[20-Feb-2017 16:34:38 -0600]: <viu6c26n> Send: MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Mon, 20 Feb 2017 16:34:38 -0600
From: myaddress <myaddress@mydomain.com>
To: Blah <blah@blahblah.blah>
Subject: test
Message-ID: <52ce981621113b0c4cfd765f3b78eef0@mydomain.com>
X-Sender: myaddress@mydomain.com
User-Agent: Roundcube Webmail/1.1.4

test

[20-Feb-2017 16:34:38 -0600]: <viu6c26n> Send: .
[20-Feb-2017 16:34:38 -0600]: <viu6c26n> Recv: 250 2.0.0 v1KMYcT2000981 Message accepted for delivery
[20-Feb-2017 16:34:39 -0600]: <viu6c26n> Send: QUIT
[20-Feb-2017 16:34:39 -0600]: <viu6c26n> Recv: 221 2.0.0 mydomain.com closing connection

[JohnDoh]

seems like the same issue as here http://unix.stackexchange.com/questions/63552/why-is-sendmail-appending-my-hostname-to-unknown-destination-domain

[boxyball]

That solved the problem!  Thanks!

I removed the wildcard from my DNS record and that solved the problem.

Sorry to bother you about this one.  Since the problem only affected roundcube and not clients, I thought it was a roundcube configuration issue.