I am running a shared hosting environment (web + email). Some of the domains being hosted have elected to use third-party spam filtering and some have not.
In order for the spam filtering on these domains to be effective, the server should reject any messages that did not originally go through the spam filter servers. I.e. they did not arrive from specific IP addresses, and don't contain specific headers.
How can I block incoming mail for these specific domains, unless the mail arrives from the spam filtering servers?
I obviously can't add firewall rule(s), because some of our hosted domains don't use the filtering service. Firewall rules blocking port 25 etc would stop their email arriving.
It needs to be a filter based on 1) the email recipient domain name, and 2) a specific list of IP addresses.
For example, if domain is in a list of filtered domains, then check IP address. If IP address is NOT in list of spam filtering servers, reject the message.
Can anyone point me in the right direction?
Thanks!
I'm looking at doing this right now. Does this suggestion help: use postfix restriction classes. Put mail domains that need restricting to your spam filter servers in a separate class, then handle it differently.
See
http://permalink.gmane.org/gmane.mail.postfix.user/148366
and
http://www.postfix.org/RESTRICTION_CLASS_README.html
Related
I have multiple domains pointing at nameservers of a shared hosting platform and manage all the emails of these domains using just one address called hello#domain-a.com as an example.
Because all of these domains work under one business and I don't want to manage multiple accounts, this address also receives all the emails for my other domains domain-b.com and domain-c.com using forwarders.
Sometimes I still need to change the From address, which is why I set up identities in Thunderbird using domain-a.com as the host with hello#domain-b.com and hello#domain-c.com as the From addresses. While doing that, I realized that I didn't need to create these accounts on the mail server and all emails that were sent by either hello#domain-b.com or hello#domain-c.com had a PASS on both SPF and DKIM.
This made me wonder, whether someone else on the same shared hosting platform (whois checkup shows there are more than 600 other domains) could also just use any of my domains to send emails and would get a PASS on both SPF and DKIM, basically making it useless in that specific scenario.
Can anyone on the same shared hosting send emails using my domain with a PASS on both SPF and DKIM?
Why is it possible to use domain-a.com as the host and hello#domain-b.com or hello#domain-c.com as From addresses and still send messages that way? The test messages I have sent using that method don't show domain-a.com but the domain of the From address in their headers. Is this normal behavior? Since I didn't set up any individual accounts for domain-b.com and domain-c.com, I honestly didn't expect this to work.
Thanks in advance.
If someone is on the same shared host as you, they will likely have the same IP address, and so if your SPF includes that IP, they will indeed be allowed to send messages from your domain. The simple solution to that by itself is don't do that – don't put critical content on shared hosting.
The next step is DKIM. DKIM has nothing to do with IP addresses, and sending from a shared host will have no effect, so this is your best defence against this kind of spoofing. A DKIM signature is signed by your private key (which nobody else should be able to access, even on shared hosting – though it is far more at risk there than on your own server). Because they can't see your key, they can't produce DKIM signatures for your domain, and thus messages they try to send from your domain will not contain a valid DKIM signature and they will not be able to get a DKIM pass result.
It could be that your hosting provider is also adding a DKIM signature of their own as an intermediary, though it will match their domain, not yours. You can add your own as well as messages can contain more than one DKIM signature.
To force alignment of From address with the envelope sender (which ends up in a return-path header at the receiver), you need to look at DMARC, specifically the adkim and aspf parameters.
Another approach would be to not send mail through your hosting provider but via some other mail server. This would let you have an SPF record that does not include your hosting provider's IPs. You may find however that you can't do this because low-end hosts tend to block outbound SMTP.
I'm using PHP mail() to send an email from my server to two different accounts, one which is my Gmail account, which SPF passes with, and one to an account hosted by my domain provider, which is then forwarded to my Gmail account. That causes SPF to fail because the originating IP is different.
But, there's no way to tell if the email address you send emails to is the recipient, or forwards them elsewhere. So is there any way to allow SPF to pass through any (unknown) relay?
It's unclear exactly what you mean here. Are you using arbitrary From addresses?
Generally, SPF control over email sources is handled in a few different ways:
Authorise your domain provider's servers to send from your domain (i.e. add them to your SPF record)
Hope that your hosting provider's mail servers support SRS, the Sender Rewriting Scheme, which they should
Allow any IP to be a source of email for your domain by adding +all to your SPF record (clearly a bad idea!)
I'm currently testing some complicated functionality in a web app that involves multiple accounts within the app; each with its own unique email address. I have a few temp gmail accounts that I'm using for this purpose, but keep having to update email addresses in the database to something else for some accounts in order to reuse email addresses. It gets meesy very quickly.
My question is; is there a way I can setup an email server on my VPS (Ubuntu 16.04) that is able to accept all email addresses on a given domain without me having to define each one in advance? Ie; I'd like to be able to make up email addresses as I go; test1#mydomain.com, test2#mydomain.com, etc, and have the server receive AND store any incoming emails to those addresses. Emails include account verifications, notifications, etc, and I need to know what is being sent to each participant at each point in each workflow as I test.
Ideally I'd like some way to view all of these emails on the domain regardless of address. Perhaps setting up an alias using some kind of wildcard so that all incoming email go to a single address that I can configure in my email client on my dev machine.
Consider rewriting envelope recipient x#subdomain.example.net to handler+x#example.net
AFAIR sendmail, postfix and exim support such rewrites. AFAIR all three support passing +detail as parameter to procmail script (to ~handler/.procmailrc as $1).
WARNING: test handling message to multiple special recipients.
Post which specific SMTP/MTA server do you use if you want more hints.
Gmail also supports plussed addresses BUT you get reliable hint about original recipient only for message to single special/plussed recipient.
After a lot of research and messing about with different configurations, I found the best solution for me was PostFix with Dovecot.
I was able to set up virtual mailboxes in PostFix with virtual_mailbox_maps pointing to a file that contained this; #mydomain.com mydomain.com/catchall/
This allows mail to any email address within the domain to go to one mailbox. The mydomain.com/catchall/ is a location on the server where the mailbox is located. By convention, the domain is used in the path. Useful if you are hosting email on multiple domains. Dovecot supports variables in the config which allows you to point it to the correct mailbox.
I also found that the PostFix main.cf file must have mydestination = localhost for this configuration to work.
the following posts helped me getting this up and running;
https://www.digitalocean.com/community/tutorials/how-to-set-up-a-postfix-e-mail-server-with-dovecot
https://www.digitalocean.com/community/tutorials/how-to-install-and-setup-postfix-on-ubuntu-14-04
Need to implement the email validation to find if the email really exists. After some search found that the this is not possible due to the spam control techniques used (e.g. grey listing).
So moved with MX and A attribute check (as we are not allowed to send confirmation mails directly):
DirContext ictx = new InitialDirContext();
Attributes attrs = ictx.getAttributes("gmail.com",
new String[] {"MX"});
I am getting the results but not sure how the dns lookup works here (the complete background of the request and response i.e how the request is forwarded to the mail exchange server and also which port is used for the contacting the Mail Exchange server)
This will immensely help in moving into the production env without any doubts about the network behavior as we are having strick firewall restrictions.
Production Env : Weblogic Server on Solaris OS.
Similar dicussion is at Email validation MX Lookup but it doesnt have enough detail
It sounds like you're confusing two different techniques:
1) Perform a DNS lookup to ensure that an MX record exists for the domain. This will eliminate all email addresses at fake (i.e., not registered) domains. Note however that having an MX record is not a requirement for legitimate mail reception. In the absence of an MX record, the mail software will simply use the A record for the base domain.
2) Make a TCP connection to the recipient mail server to see if anything is listening. This is always port 25. You don't have to send a test message, you can just connect to the port and then immediately disconnect. A successful connection implies a valid email address. (Or at least, a valid domain, which is as much as you can verify.)
When developing an application that sends out notification email messages, what are the best practices for
not getting flagged as a spammer by your hosting company. (Cover any of:)
best technique for not flooding a mail server
best mail server products, if you were to set up your own
sending messages as if from a specific user but still clearly from your application (to ensure complaints, etc come back to you) without breaking good email etiquette
any other lessons learned
not getting flagged as spam by the receiver's client? (Cover any of:)
configuring and using sender-id, domain-keys, SPF, reverse-dns, etc to make sure your emails are properly identified
best SMTP header techniques to avoid getting flagged as spam when sending emails for users (for example, using Sender and From headers together)
any other lessons learned
An additional requirement: this application would be sending a single message to a single recipient based upon an event. So, techniques for sending the same messages to multiple recipients will not apply.
best technique for not flooding a mail server
not a lot you can do about this beyond checking with your mail server admin (if it's a shared hosting account / not in your control). but if the requirement is one email to a single recipient per event, that shouldn't be too much of an issue. the things that tend to clog mail systems are emails with hundreds (or more) of recipients.
if you have events firing off all the time, perhaps consider consolidating them and having an email sent that summarizes them periodically.
sending messages as if from a specific user but still clearly from your application (to ensure complaints, etc come back to you) without breaking good email etiquette
you can accomplish this by using the "Reply-To" header, which will then have clients use that address instead of the From address when an email message is being composed.
you should also set the "Return-Path" header of any email, as email without this will often get filtered off.
ex.
From: me#me.com
Return-Path: me#me.com
Reply-To: auto#myapp.com
configuring and using sender-id, domain-keys, SPF, reverse-dns, etc to make sure your emails are properly identified
this is all highly dependent on how much ownership you have of your mail and DNS servers. spf/sender-id etc... are all DNS issues, so you would need to have access to DNS.
in your example this could present quite the problem. as you are setting mail to be from a specific user, that user would have to have SPF (for example) set in their DNS to allow your mail server as a valid sender. you can imagine how messy (if not outright impossible) this would get with a number of users with various domain names.
as for reverse DNS and the like, it really depends. most client ISP's, etc... will just check to see that reverse DNS is set. (ie, 1.2.3.4 resolves to host.here.domain.com, even if host.here.domain.com doesn't resolve back to 1.2.3.4). this is due to the amount of shared hosting out there (where mail servers will often report themselves as the client's domain name, and not the real mail server).
there are a few stringent networks that require matching reverse DNS, but this requires that you have control over the mail server if it doesn't match in the first place.
if you can be a bit more specific i may be able to provide a bit more advice, but generally, for people who need to send application mail, and don't have a pile of control over their environment, i'd suggest the following:
make sure to set a "Return-Path"
it's nice to add your app and abuse info as well in headers ie: "X-Mailer" and "X-Abuse-To" (these are custom headers, for informational purposes only really)
make sure reverse DNS is set for the IP address of your outgoing mail server
first a quick correction to the previous
return-path: is a header added by recieving system based on the envelope-sender of the incomming message
for spf to work the return-path/envelope-sender needs to be yourapp#yourdomain.com
and ensure the spf record for yourdomain.com {or if per-user spf} for yourapp#yourdomain.com allows mails to originate on the server that hosts the app/sends the email
this envelope-sender is the address that will recieve all bounces/errors
now sender-id is different entirely it checks the return-path/envelope-sender
and the
from: address {stored inside the message}
if sending
from: hisname yourapp#yourdomain.com
reply-to: hisname hisaddres#hisdomain.com
this will be a non-issue
if sending
from: hisname hisaddres#hisdomain.com
it will be and you must add a
Resent-From: hisname yourapp#yourdomain.com
as this specifies to ignore the from: for sender-id checks use this instead as it has been sent by you on his behalf
now for the other bits that are worthwhile
ip's mentioned are your mailservers
a have your ip's ptr point to a name that also resolves to the same ip
FQDNS
b have your server helo/ehlo with whatever.domain.com where domain.com is the same as the domain of the name in step A {not the same name for resons below}
c have that helo/ehlo servername also resolve to the ip of your server
d add the following spf record to that helo/ehlo name "v=spf1 a -all"
{meaning allow helo/ehlo with this name from ip's this name points to only}
e add the following sender-id lines to the helo/ehlo name {purely for completeness
"spf2.0/mfrom,pra -all" {ie there are no users#this-domain}
f add the following spf to the FQDNS-name and any other hostnames for your server
"v=spf1 -all" {ie no machines will ever helo/ehlo as this name and no users#this-domain}
{as the fqdns name can be determined by bots/infections its better to never allow this name to be used in helo/ehlo greetings directly it is enough that it be from the same domain as the helo/ehlo identity to prove the validity of both}