I am having an issue, that I require a stable public SMTP endpoint (mySmtpPublicNode). This endpoint should relay/route the emails to the corresponding mailservers, which regularly change (myInternalSmtpServerXY)
SMTP-client <--> mySmtpPublicNode <--> myInternalSmtpServer01
^
+------> myInternalSmtpServer02
|
+------> myInternalSmtpServer03
|
+------> ....
|
+------> myInternalSmtpServer99
The myInternalSmtpServer[01-99] are all having their own TLD mail-domains. I require that my mySmtpPublicNode can accept all mail from all myInternalSmtpServer[01-99] and also has a "sticky" handling of the underlying domains to the corresponding myInternalSmtpServer[01-99] server.
My restrictions:
I can only define stable DNS records for the myInternalSmtpServer[01-99] hosts
I cannot define stable IP addresses
myInternalSmtpServer[01-99] are mostly postfix or sendmail
mail-domains may change from myInternalSmtpServer[01] to e.g. myInternalSmtpServer[22] during the day
all the above nodes, except the client, are in a controlled environment and I have full (root) access to the servers.
How to solve this with Linux (or docker)?
How to create a mapping these mail domain examples on the mySmtpPublicNode?
mail-domain
internal SMTP Server
example.com
myInternalSmtpServer01
mysuperduper.com
myInternalSmtpServer03
...
myInternalSmtpServer[01-99]
How to automatically update the mapping?
the mail-domains may change from myInternalSmtpServerXY to myInternalSmtpServerAB depending on IO, CPU or Disk requirements
so the mapping can change during a day, if the mail domain gets migrated
Related
I'm using Amazon SES to send emails from ec2 instance to the app users, I've sent emails using the sandbox ses account. I want to move out of sandbox, I'm little bit confused after gone through the documents,
https://docs.aws.amazon.com/ses/latest/DeveloperGuide/request-production-access.html
https://aws.amazon.com/premiumsupport/knowledge-center/ec2-port-25-throttle/
I've sent the support mail to raise the daily limits,(I don't need to send much emails, only forgot password emails + welcome).
Should I need to open port 25 on the ec2 instance? Should I need to
create DNS A record?.
Thanks in advance.
No, you do not need to open any ports in AWS security group.
1) You need to send request to raise your AWS SES sending limits
Sandbox limit is 1/sec, 200/day is very low, and 1/sec very easy to exceed without exceeding 200/day and if your app does not support retries = no email.
2) As far as you send email from ec2 instance - this means you are connecting to another email server.
Your ec2 instance -> SES (25 port)
Email servers listen on standard ports, 25 is most common smtp port to connect to send emails. Because it is most common - it presumably gets more spam, third-party services may block ip because of spam - and that's why amazon throttles traffic that is send to 25 port.
So, you also need to remove 25 port throttle for your ec2 instance by filing a request.
For this you also need valid domain name associated with your ec2 instance - dns A record. I.e. mydomain.domain.com pointing to your ec2 elasctic ip 22.22.22.22. This is also to ensure you are a valid sender, not spam.
So, if emails are from #mydomain.domain.com domain - any mail server can tell email origin.
Things to consider:
Your ec2 instance has elastic ip (or you can add one).
you have your own domain name registered with some domain registrar, i.e. myowndomain.domain.com
You can buy your own domain name from Route 53, other domain registrars
Most registrars provide integrated DNS management (at least basic)
you need to add dns A record pointing to your ec2 elastic ip
To send email using SES, you need to verify sending domains or individual email address. verifying the domain is convenient because it will be a hazzle setting up each individual email address.
in regards to DNS record, yes you will need to add few dns entries to confirm your ownership.
in regards to opening port 22, you don't need to open port 22. But you will need to have outgoing ports 465 or 587 enabled because thats the ports used for SSL.
Yes, port 25 has throttling issues, you don't have that issue, if you use SSL to send out emails.
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
I wonder if there is any possibility to receive and set original ip address in exim ? I have an NGINX proxy where I used "proxy_pass" and "proxy_set_header X-Forwarded-For" in order to get the REAL ip address within apache runtime, there is any posibility to do it aswell for exim ?
I need the "client" real ip address in order to check for spamlists, spf records and so on, I know that I could install exim on the proxy server and configure it with everything needed to do these checks and relay to master exim server but configuration often changes and it would be easier to maintain everything from one place.
Thank you !
Doing SRS in exim will allow you to do the header rewrites.
I have a ruby server based on TCPSocket (non-HTTP).
I have 2 different domains, both pointing with an A-Record to my servers IP Address (the same one). So, there are clients connecting to one of those domains.
Is it possible to tell which domain a client was connecting to?
I saw that this is possible in other protocols, but I'm not sure if this is based on manually added headers or really extracted from the basic tcp/ip connection. E.g. in PHP there is $_SERVER["HTTP_HOST"] which shows to which domain a client was connecting.
At the TCP socket level, the only things that are known are the source and destination IP addresses (and ports) of the connection. How the IP address was resolved via DNS is not possible to know at this layer. Even though HTTP works on top of TCP, HTTP servers have to look at the HTTP headers from the client to know which domain they are making a request to. (That's how the HTTP_HOST value gets filled in.)
One possible solution is to configure your server to have an additional IP address. This can be by assigning an additional IP address to the NIC or adding an additional NIC. Then have each domain use a different IP address. Otherwise, this is not possible and you may want to consider your application protocol on top of TCP to convey this information.