Alias forwarding: "550 mailbox unavailable", Receiving and sending works fine - email

Hello Folks!
I am in trouble and hope you can help!
I have been using my VPS (ubuntu 14.04) with exim4/dovecot for years now without problems.
One common use is to receive mail from a gmx.de address (to an alias on my domain) and let it be distributed by the alias setting to some web.de addresses and also to addresses on my domain.
The way it should be is: ORIGIN -> ALIAS#MYDOMAIN -> (DEST1, DEST2,...)
Since yesterday, this "alias forwarding" does not work anymore. This is the typical exim log:
2016-05-25 18:12:59 1b5bQZ-0000KU-Kl <= ORIGIN#gmx.de H=mout.gmx.net [212.227.15.18] P=esmtp S=51309 id=ID#mail.gmx.com
2016-05-25 18:12:59 1b5bQZ-0000KU-Kl ** DEST1#web.de <ALIAS#MYDOMAIN.de> R=dnslookup T=remote_smtp: SMTP error from remote mail server after MAIL FROM:<ORIGIN#gmx.de> SIZE=53021: host mx-ha03.web.de [212.227.15.17]: 550-Requested action not taken: mailbox unavailable 550-Reject due to SPF policy. 550-The originating IP of the message is not permitted by the domain owner.
2016-05-25 18:12:59 1b5bQZ-0000KU-Kl ** DEST2#web.de <ALIAS#MYDOMAIN.de> R=dnslookup T=remote_smtp: SMTP error from remote mail server after MAIL FROM:<ORIGIN#gmx.de> SIZE=53021: host mx-ha03.web.de [212.227.15.17]: 550-Requested action not taken: mailbox unavailable 550-Reject due to SPF policy. 550-The originating IP of the message is not permitted by the domain owner.
2016-05-25 18:12:59 1b5bQZ-0000KU-Kl ** DEST3#web.de <ALIAS#MYDOMAIN.de> R=dnslookup T=remote_smtp: SMTP error from remote mail server after MAIL FROM:<ORIGIN#gmx.de> SIZE=53021: host mx-ha03.web.de [212.227.15.17]: 550-Requested action not taken: mailbox unavailable 550-Reject due to SPF policy. 550-The originating IP of the message is not permitted by the domain owner.
2016-05-25 18:13:00 1b5bQZ-0000Kl-Ud <= <> R=1b5bQZ-0000KU-Kl U=Debian-exim P=local S=53469
2016-05-25 18:13:00 1b5bQZ-0000KU-Kl Completed
The same happens if I test it with a web.de address as ORIGIN, whereas a gmail address or one from MYDOMAIN work just fine as ORIGIN.
Important is that it seems to be only a problem of the aliasing. I can send mails from e.g. web.de to ADDRESS#MYDOMAIN and vice versa.
My MX points to the right spot (obviously, because it used to work for a long time now) and I have checked that my IP and DOMAIN are not in the spamhouse of web.de/gmx.de.
Any suggestions are highly welcome!!
Best, Bb

GMX seems to have switched to strict SPF checking just yesterday (2016-05-25), and this breaks e-mail forwarding.
This is a long-standing problem with SPF, I don't know whether GMX realizes that they are rejecting a huge number of legitimate e-mails by this stupid decision.

As pointed out by Hans-Martin SPF breaks email forwarding as explained here. This is however not at all a stupid decision as it is basically the only thing able to effectively eliminate SPAM.
Fixing this requires that you configure SRS (Sender Rewriting Scheme).
To quote from the postsrsd README:
Imagine your server receives a mail from alice#example.com that is to be forwarded. If example.com uses the Sender Policy Framework to indicate that all legit mails originate from their server, your forwarded mail might be bounced, because you have no permission to send on behalf of example.com. The solution is that you map the address to your own domain, e.g. SRS0+xxxx=yy=example.com=alice#yourdomain.org (forward SRS). If the mail is bounced later and a notification arrives, you can extract the original address from the rewritten one (reverse SRS) and return the notification to the sender. You might notice that the reverse SRS can be abused to turn your server into an open relay. For this reason, xxxx and yy are a cryptographic signature and a time stamp. If the signature does not match, the address is forged and the mail can be discarded.
Setting up postsrsd on Debian 8 (should be very much the same on Ubuntu):
# Dependencies.
sudo apt-get install unzip cmake
# Download and extract source code from GitHub.
cd /tmp
curl -L -o postsrsd.zip https://github.com/roehling/postsrsd/archive/master.zip
unzip postsrsd.zip
# Build and install.
cd postsrsd-master
cmake -DCMAKE_INSTALL_PREFIX=/usr
make
sudo make install
# Start services
sudo systemctl enable postsrsd
sudo service postsrsd start
# Reconfigure Postfix
sudo postconf -e "sender_canonical_maps = tcp:127.0.0.1:10001"
sudo postconf -e "sender_canonical_classes = envelope_sender"
sudo postconf -e "recipient_canonical_maps = tcp:127.0.0.1:10002"
sudo postconf -e "recipient_canonical_classes = envelope_recipient,header_recipient"
sudo postfix reload

It seems GMX switched on strict SPF checking recently which cause forwarding mails to fail. You'll see something like this in the mail.log
to=<mailaddress#gmx.de>, orig_to=<mailaddress#mydomain.com>, relay=mx00.emig.gmx.net[212.227.15.9]:25, delay=0.15, delays=0/0.02/0.12/0.01, dsn=5.0.0, status=bounced (host mx00.emig.gmx.net[212.227.15.9] said: 550-Requested action not taken: mailbox unavailable 550-Reject due to SPF policy. 550-The originating IP of the message is not permitted by the domain owner. 550 For explanation visit http://postmaster.gmx.com/en/error-messages?ip=127.0.0.10&c=spf (in reply to MAIL FROM command))
Like L. Gleim pointed out, SRS and installing postsrsd is the solution.
There is a PPA for Ubuntu available as well, so Ubuntu installation can be accomplished by
sudo add-apt-repository ppa:roehling/latest
sudo apt-get update
sudo apt-get install postsrsd
sudo postconf -e "sender_canonical_maps = tcp:127.0.0.1:10001"
sudo postconf -e "sender_canonical_classes = envelope_sender"
sudo postconf -e "recipient_canonical_maps = tcp:127.0.0.1:10002"
sudo postconf -e "recipient_canonical_classes = envelope_recipient,header_recipient"
sudo postfix reload
This made forwarding mails to GMX possible again for me.

Related

rsync unable to connect error

I am trying to use rsync to upload files to my server alongside Travis and GitHub, I have this line in a deploy.sh script rsync -avhP $f deploy#multicrew.co.uk:/var/www/test/ and whenever I try to upload the $f files I get this error:
ssh: connect to host multicrew.co.uk port 22: Cannot assign requested address
Within my .travis.yml file I have this code
addons:
ssh_known_hosts: multicrew.co.uk
before_install:
- openssl aes-256-cbc -K $encrypted_8c9513462553_key -iv $encrypted_8c9513462553_iv -in deploy/deploy_rsa.enc -out /tmp/deploy_rsa -d
- eval "$(ssh-agent -s)"
- chmod 600 /tmp/deploy_rsa
- ssh-add /tmp/deploy_rsa
- chmod +x deploy/deploy.sh
after_success: "deploy/deploy.sh"
I do not know why rsync cannot assign the requested address, I have an A name record set up within CloudFlare that forwards multicrew.co.uk to my server's IP
The error you are getting looks like it is caused by an outstanding issue with IPv6 on Travis CI.
However because, at the time of writing, your multicrew.co.uk domain is proxied by Cloudflare and Cloudflare only proxies HTTP traffic, the suggested fix of disabling IPv6 will not work.
You'll need to either create a separate non-proxied (grey cloud) hostname to use with SSH/RSYNC, change the rsync command to connect directly to the server IP address or disable Cloudflare proxying for the multiview.co.uk hostname.
Note that adding a non-proxied hostname in DNS will expose your server's IP address. You might want to restrict access on your server to just the Travis CI and Cloudflare IP ranges (e.g. with firewall rules or in the web server configuration).

orangehrm test email not send

I have installed OrangeHrm 3.3.3 on Ubuntu 14.04 Server and now trying to configure SMTP Email.
The credentials and settings are correct. I am using same in SuiteCRM installed on CentOS 7.
The message I get
Settings Saved. Test email not sent.
I remember doing this on CentOS:
chcon -R -t httpd_sys_content_rw_t /var/www/html
setsebool httpd_can_network_connect=on
setsebool httpd_can_sendmail=on
setsebool httpd_unified=on
Is there some similar settings for Apache on Ubuntu where I can allow sendmail on the server?
I would highly appreciate your input.
Thanks in advance.
/AAN

installing MailHog on Linux virtual box to capture outgoing emails

I wanted to ease the development by installing MailHog on my centos linux development environment in my virtual box. The php mail() function doesn't report any issues (that is, it returns TRUE) but the outgoing mails did not appear in MailHog. How should I set it up correctly?
Follow these steps:
Download the appropriate MailHog version from https://github.com/mailhog/MailHog/releases. I use MailHog_linux_amd64 in this example but you may need a different version. I assume you use your home directory to store your files. In the likely case you don't do this, please, make the required modifications accordingly.
If your VM uses ip filtering then you should allow the communication through port 8025 with adding a line to the iptable config and restarting it:
vim /etc/sysconfig/iptables
-A INPUT -m state --state NEW -m tcp -p tcp --dport 8025 -j ACCEPT
service iptables restart
Launch MailHog with the following command:
./MailHog_linux_amd64 -hostname=mylocal.vbox:8025
where mylocal.vbox is the domain name how the host sees the VM. Now you should see some lines detailing which IP addresses and ports it uses.
Download mhsendmail from here: https://github.com/mailhog/mhsendmail/releases.
Change it to be executable (adjust the path of the file accordingly):
chmod 777 /home/you/mhsendmail_linux_amd641
Change your php.ini to use mhsendmail instead of sendmail:
vim /etc/php.ini
sendmail_path = "/home/you/mhsendmail_linux_amd64"
service httpd restart
View the MailHog web interface from your host computer (use the host name we used above): http://mylocal.vbox:8025/. The webmail interface of MailHog should appear.
Test mail sending from the command line of the VM with this oneliner:
php -r "\$from = \$to = 'your.emailaddress#gmail.com'; \$x = mail(\$to, 'subject'.time(), 'Hello World', 'From: '. \$from); var_dump(\$x);"
It should display true and the web interface of the MailHog should display the new email.
Have fun, send as many emails via the mail() function of php as you want.
Some more ideas:
If you want to override the default IP address and port settings then you should use the following syntax:
./MailHog_linux_amd64 -ui-bind-addr=192.168.56.104:8026 -api-bind-addr=192.168.56.104:8026 -hostname=mylocal.vbox:8026 -smtp-bind-addr=192.168.56.104:8025
In this case you will have to escape the settings in php.ini this way:
sendmail_path = "/home/you/mhsendmail_linux_amd64 --smtp-addr=""192.168.56.104:8025"""

Mac OS X 10.10 Yosemite Postfix SASL authentication failed

I followed the step described in the link below to setup my mac to send out email.
http://www.anujgakhar.com/2011/12/09/using-macosx-lion-command-line-mail-with-gmail-as-smtp/
It was working fine on my Mac OS X 10.9. But after I upgraded to OS X 10.10. The mail.log showed the following error. What is the problem?
Oct 19 00:28:22 paullam-macbook-pro.local postfix/smtp[30383]: 6B47B8AD4E8: SASL authentication failed; cannot authenticate to server smtp.gmail.com[74.125.68.109]: generic failure
Oct 19 00:28:24 paullam-macbook-pro.local postfix/smtp[30383]: 6B47B8AD4E8: to=<zzpaul#gmail.com>, relay=smtp.gmail.com[74.125.68.108]:587, delay=3.4, delays=0.01/0/3.4/0, dsn=4.7.0, status=deferred (SASL authentication failed; cannot authenticate to server smtp.gmail.com[74.125.68.108]: generic failure)
I had the same problem. A Google search turned up this link: http://hkitago.com/2014/09/yosemiteのpostfix設定/
It turned out I was missing the following line in /etc/postfix/main.cf:
smtp_sasl_mechanism_filter = plain
I added both snippets as suggested, but still no luck. Then I found this article:
http://www.developerfiles.com/how-to-send-smtp-mails-with-postfix-mac-os-x-10-8/
and ran the following steps from it:
Step 2. Create the sasl_passwd file
We need to create the sasl_passwd file with the SMTP credentials
sudo vi /etc/postfix/sasl_passwd
Write the following content exactly (don't put in your user address and password) and save:
smtp.gmail.com:587 your_address#gmail.com:password
Create the Postfix lookup table from the sasl_passwd file.
sudo postmap /etc/postfix/sasl_passwd
This will create the file sasl_passwd.db
Step 3. Restart Postfix
To apply all new changes we have to restart Postfix:
sudo postfix reload
And still no luck. But then I noticed that relayhost in /etc/postfix/main.cf
was commented out with brackets like so:
relayhost = [smtp.gmail.com]:587
I changed this line to:
relayhost = smtp.gmail.com:587
reloaded postfix with:
sudo postfix reload
and postfix started sending email. Hooray!
It turned out I needed another piece to get this to work.
sudo vi /System/Library/LaunchDaemons/org.postfix.master.plist
and right after this:
<dict>
add this:
<key>RunAtLoad</key>
<true/>
I can now send emails with Postfix on Yosemite!
Answer by #Josh is working just fine (can lot leave comments on the answer), but using login as a filter would also work just fine. Not sure what the difference is, though.
As stated by the documentation page

Sending mail through terminal using msmtp works fine, but doesn't work with php mail()

Recently I installed msmtp on my ubuntu 12.04 server that is running the kubuntu desktop. The install of msmtp worked fine, and I can even send mail through the terminal using gmail's smtp server.
My problem is that although sending mail works through the terminal, it still doesn't work with php mail. I have tried using the php mail() function, but I never receive any email.
I have checked the apache error logs (/var/log/apache2/error.log), but they are empty.
Does anyone know how to fix this? If any further information is needed, just say so :)
Also when executing the php script, no errors appear.
The code below echos Mail Sent, but I never recieve an email:
<?
if(mail( 'noreply.njmedia#gmail.com', 'Test mail from localhost', 'Working Fine.'))
{
echo 'Mail sent';
}
else
{
echo 'Error. Please check error log.';
}
?>
For me the cause was incorrect file ownership & permissions on the msmtp config file.
When I tried to run the PHP mail-sending script from the CLI as root, it worked. However switching user to www-data and trying to run the script again (also on CLI) failed with the following messages:
msmtp: /etc/msmtprc: contains secrets and therefore must be owned by you
msmtp: /etc/msmtprc: contains secrets and therefore must have no more than user read/write permissions
Triggering the PHP script by a HTTP request to Apache (or Nginx etc) would have the same results (since msmtp would be invoked by the www-data user).
Assuming your msmtp config file is at /etc/msmtprc, these commands would fix those issues:
chown www-data:www-data /etc/msmtprc
chmod 600 /etc/msmtprc
Before making these changes please consider if these new permissions are appropriate for your circumstances (eg. are there security implications?).
The php mail module calls a system command called sendmail for sending emails. sendmail is implemented by various mail servers, e.g. postfix or exim. As I see, msmtp doesn't provide a sendmail binary. Please check, if you can execute sendmail via command line. If not, try to install postfix.
update:
I see, that msmtp-mta does provide an sendmail binary too. You can try this, if you don't want postfix.