I am using a small business 2003 server with Microsoft exchange 2003!! Both of them are fully updated to their newest versions!! However I am having a problem!! When I am trying to send an email from a PC in our domain (using outlook) to a specific external server it doesn't reach and I am getting this error message:
Your message did not reach some or all of the intended recipients.
Subject: test
Sent: 2/6/2015 10:17
The following recipients cannot be reached:
info#kekdei.gr on 2/6/2015 10:16
The recipient could not be processed because it would violate the security policy in force <ipa237.225.tellas.gr #5.7.0smtp;550 5.7.0 550 Your server IP address
[my address] does not have a valid reverse DNS entry [ipa237.225.tellas.gr].
I tried to send an email to that address using Hotmail and it reached the destination!!! any ideas?
Related
I'm using SendGrid to deliver emails and the recent test I conducted from my server, using their API, ended up having SpamAssassin flagging my email. Here is the result:
pts rule name description
---- ---------------------- --------------------------------------------------
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information.
[URIs: sendgrid.net]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 T_SPF_HELO_TEMPERROR SPF: test of HELO record failed (temperror)
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
0.0 HTML_MESSAGE BODY: HTML included in message
2.0 HTTPS_HTTP_MISMATCH BODY: No description available.
1.1 KAM_REALLYHUGEIMGSRC RAW: Spam with image tags with ridiculously huge
http urls
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's
domain
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid
2.6 RDNS_DYNAMIC Delivered to internal network by host with
dynamic-looking rDNS
2.0 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr 1)
X-Spam-Flag: YES
The webhosting company I'm using just came back to me saying that they fixed the problem by disabling SpamAssassin from my server. I might need a better solution.
So the main question I have is: who should I contact to get the following lines fixed? My webhost, Sendgrid or someone else?
2.6 RDNS_DYNAMIC Delivered to internal network by host with dynamic-looking rDNS
2.0 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr 1)
HELO_DYNAMIC_IPADDR indicates that the sending server connected to the receiving server and announced itself with an IP address rather than a Fully Qualified Domain Name (FQDN), and RDNS_DYNAMIC indicates that the Reverse DNS check on that IP address resolves to something that resembles the FQDN of a dynamically issued IP address.
To rectify this you would need to get the rDNS of your sending IP to resolve to a plausible FQDN, and in turn use that FQDN in the HELO / EHLO handshake. Both of these relate to the MX phase of your message exchange, and would be caused by the sending server, but maybe your sender doesn't want to announce themselves overtly to avoid other more direct SPAM rules from being applied to their perceived sender reputation ?
I would have expected SendGrid to send on your behalf using your domain name during the HELO handshake, and consequently require their sending IP ranges to be included in any SPF records for your domain.
Historically it used to be misconfigured Exchange Servers that announced the IP address during the HELO handshake, because unwitting admins entered an IP address in the FQDN field of their Send Connectors.
We have two exchange servers internally which are being served by Zen Load Balancer on 10.101.1.105 / 106.
When mail arrives, half of it gets blocked because of failed SPF checks.
The headers in the email:
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (10.101.1.105) by
EXCH02.prfm.co.uk (10.101.7.102) with Microsoft SMTP Server id
15.0.1210.3 via Frontend Transport; Wed, 4 Jan 2017 09:20:48 +0000
The SPF in the headers
authentication-results: spf=none (sender IP is )
smtp.mailfrom=madeup#madeup.madeup;
Sender IP is blank, I haven't removed that for security.
When I check the MX record for madeup.madeup, I get the SPF record
v=spf1 include:spf.protection.outlook.com -all
And the MX record
madeup-madeup.mail.protection.outlook.com
Is there a way to get ZLB to preserve the original IP address so it doesn't get blocked by SPF?
You can try to make Exchange aware of the internal SMTP Servers (your loadbalancer via):
Set-TransportConfig -InternalSMTPServers IP
or for multiple IPs:
Set-TransportConfig -InternalSMTPServers #{Add="ip address1","ip address2"...}
For more info's see here:
The InternalSMTPServers parameter specifies a list of internal SMTP
server IP addresses or IP address ranges that should be ignored by
Sender ID and connection filtering
For security purposes we want to include the source computers public IP address in the header of any e-mails sent. I can easily find it and pop it in the body of the e-mail, but we sort of want some evidence that the e-mail itself originated from the same IP address.
I'm sending some system information via postfix mail command in terminal in OS X and at the moment I'm using Turbo SMTP as the SMTP server to do it.
Is there a way for me to do it from terminal or is it all down to the SMTP server if that data is sent in the header?
If so, might it be better to run my own SMTP server on a linux server which does send the public IP?
At the moment the header just includes the SMTP servers IP and my receiving e-mail servers IP.
I need some assistance with these type of scanners, there seem to be many of them on the web but I can't seem to find specific details of what they are meant to achieve.
I understand that they are communicating on the SMTP port, but I am not certain of what type of information they are trying to get.
The reason I ask this is because I am currently investigating a SMTP VRFY Scanner. I have made the scanner to connect to a windows xp system but it states
Waiting for SMTP banner
220 testing221 Microsoft ESMTP MAIL Service, Version: 6.0.2600.2180 ready at Sun, 27 Sep 2015 19:04:44 +0100
testing221 corresponds to the domain on the SMTP virtual server, on the xp system.
The SMTP VRFY command is intended to allow a sender to verify the correctness of an email address without actually sending an email.
This feature was abused by spammers very early on. As a result, most SMTP servers are configured to ignore the command.
They are effectively useless for the public internet these days. You will find very few, if any, domains configured to support the command.
I am getting the error "Server response: 451 451 Temporary local problem - please try later" when sending password reminder emails via Laravel and Mailgun. I am running Laravel on VirtualBox.
I set up VirtualBox using Vagrant, would this have made a difference?
If I change the SMTP settings to my own host it works absolutely fine. Is there an issue with using Mailgun on a Virtual machine?
Update
I can send to Gmail addresses without any problems, however, they apparently are neither being blocked or allowed.
This is the error I get:
Failed: support#mydomain.com → me#anotherdomain.com Server response: 550 550
Verification failed for <bounce+ad0324.1a1312-me=anotherdomain.com#mydomain.com>
No Such User Here Sender verify failed
The error "451 Temporary local problem" comes from the actual mail server you are connecting to.
Typically, 451 errors are due to the receiving server rejecting your email. This can happen for a number of reasons but most likely is due to the recipients server being overloaded with messages. It can also mean that the recipients server has grey-listed the IP, and therefore delays the message until it can verify that the sending server is not trying to send spam. The receiving server may be offline as well.
Since this error message is so vague, you'll need to get more information from the recipient. I'd suggest waiting a few hours and try to send the email again.
It doesn't have to do with your Laravel installation or running with Virtualbox, further more because you tested with other SMTP settings.