Page 1 of 1

Debian 7 Email aliases just dont work *BUG*

Posted: Fri Oct 30, 2015 7:17 pm
by jonn
Hello,

When installing a fresh vestacp install on debian 7 after adding a domain and setting up and email account adding several aliases, the domain email account main email will receive mail but all aliases will bounce. Tried two separate installs same problem.

Bounce:

Code: Select all

H=notify1.uk.xxxxxxt.com [1xx.74.xx.185] F=<[email protected]> rejected RCPT <[email protected]>: smtp auth requried
ignore the xxxx mark out of real ips and names. and Yes the server error spelling of required is wrong it was a cut and paste.

The part that is troubling is all permissions are correct, nothing has been altered on the servers, two fresh install tests both fail same smtp auth error.

I have to say this is bug on debian install of vesta.

Never the less, installing of vestacp on Debian 7 should be avoided until this email aliases bug is resolved.

Re: Debian 7 Email aliases just dont work *BUG*

Posted: Thu Nov 05, 2015 8:06 am
by skurudo
jonn wrote:When installing a fresh vestacp install on debian 7 after adding a domain and setting up and email account adding several aliases, the domain email account main email will receive mail but all aliases will bounce. Tried two separate installs same problem.
Can you add this bug - http://bugs.vestacp.com/ ?
jonn wrote:Never the less, installing of vestacp on Debian 7 should be avoided until this email aliases bug is resolved.
Well, not everybody use mail server for incomming mail, and phrase about "Debian 7 ..avoided" overstatement.

Re: Debian 7 Email aliases just dont work *BUG*

Posted: Thu Nov 05, 2015 11:34 pm
by jonn
yes true frustration got the better of me that evening.

I did try centos6 same problem occurred, so I started looking at my other servers exim files to compare and it does have something to do the lines in exim.conf or exim4.conf if on debian.

Code: Select all

 
deny    message       = smtp auth required
           sender_domains = +local_domains
           !authenticated = *
For what ever reason normal mail goes through to/from/from/to with aliases if sending from outlook or squirrel or any other client though mail sent from remote server like a reseller system from an alias to an alias the mail bounces with this message above.
Comment this part and mail goes through.

I found this out from user: kusspaprika.com

Re: Debian 7 Email aliases just dont work *BUG*

Posted: Thu Nov 05, 2015 11:58 pm
by jonn
sorry tried to register on bugs.vestacp though all I get is a little spinner and nothing happens, will try again tomorrow.

Re: Debian 7 Email aliases just dont work *BUG*

Posted: Tue May 10, 2016 9:53 pm
by misak35
jonn wrote:Hello,

When installing a fresh vestacp install on debian 7 after adding a domain and setting up and email account adding several aliases, the domain email account main email will receive mail but all aliases will bounce. Tried two separate installs same problem.

Bounce:

Code: Select all

H=notify1.uk.xxxxxxt.com [1xx.74.xx.185] F=<[email protected]> rejected RCPT <[email protected]>: smtp auth requried
ignore the xxxx mark out of real ips and names. and Yes the server error spelling of required is wrong it was a cut and paste.

The part that is troubling is all permissions are correct, nothing has been altered on the servers, two fresh install tests both fail same smtp auth error.

I have to say this is bug on debian install of vesta.

Never the less, installing of vestacp on Debian 7 should be avoided until this email aliases bug is resolved.

I use CentOs and I have 550 smtp auth requried problem. I try to chown -R exim mail, but nothings changed...

Re: Debian 7 Email aliases just dont work *BUG*

Posted: Wed May 25, 2016 10:02 pm
by jonn
@ misak35

I have been battling with this problem for a long time, the only work around without making the mx server an open relay was to whitelist the ips for any authorization email notices sent from a remote server not controlled by myself, and watch the logs for any suspicious activity from those whitelisted ips.

Re: Debian 7 Email aliases just dont work *BUG*

Posted: Sat Jun 04, 2016 3:13 am
by jonn
Okay so I might have found a way to allow certain ips to relay smtp auth.

This is a trial.

in exim.conf

Find:

Code: Select all

  
  deny    	message       		= smtp auth required
         	sender_domains 	= +local_domains
         	!authenticated 		= *
Replace like this:

Code: Select all

  
  deny    	message       		= smtp auth required
        	hosts         		= !+whitelist
         	sender_domains 	= +local_domains
         !authenticated = *
And add any ips to the whitelist-blocks.conf

------------------------------------------------------------------

This seemed to patch my problem with emails sent from a reseller platform on a remote server not under my control.
The reseller system sends renewal notices using my domain email to my customers in the header and sometimes it sends emails from my domain to my domain for notifications, they all bounce without this patch, by pass auth for the ips in whitelist-blocks.conf with this small addon was the only solution here.

I still have to watch how this works out for the next week. I'm not 100% sure this is a permanent solution, do your own tests and report any bad findings or suggested changes to this thread.

Jonn.

Re: Debian 7 Email aliases just dont work *BUG*

Posted: Sun Sep 18, 2016 7:44 pm
by misak35
Jonn is it working? Im not test this yet...

Re: Debian 7 Email aliases just dont work *BUG*

Posted: Mon Sep 19, 2016 12:35 am
by misak35
jonn wrote:@ misak35

I have been battling with this problem for a long time, the only work around without making the mx server an open relay was to whitelist the ips for any authorization email notices sent from a remote server not controlled by myself, and watch the logs for any suspicious activity from those whitelisted ips.
http://mxtoolbox.com/ reports :

Code: Select all

550 relay not permitted [1094 ms]
and result

Code: Select all

SMTP Connection Time	5.985 seconds - Warning on Connection time
	SMTP Transaction Time	8.750 seconds - Not good! on Transaction Time