Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Allowed Sender IPs/Ranges Functionality to MailRelay #7

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

orware
Copy link

@orware orware commented Jan 6, 2021

Hi Doug,

I know we had chatted a little bit about this a number of months back last year, but I finally took some time myself to try and look into the issue further.

The AllowedHosts variable didn't seem like the best place for this since it seems to serve a different purpose (if I understand it correctly, it seems to be for the hostnames that the server would respond to mainly, but wasn't the same as the "List of Allowed Sender IPs / Ranges" functionality I had been looking for).

After spending a bit of time reviewing the code I came up with the solution you can see down below.

Mainly, I'm bringing in an existing ipfilter library, and using that if the new allowed_senders parameter in the JSON file is populated with something other then "*" (if it's not that, then it should be pointing to a .txt file and then each line in that text file will populate the AllowedSendersFilter using that ipfilter Library).

Since AllowedSendersFilter is a global variable, it can be accessed over in the client.go file each time the sendMail() function runs to check the client's remote IP and see if it's in the allowed list of IPs/Ranges.

I've run some tests that confirmed the functionality was working as expected and then brought it over to the server I had been working on a few months back when initially trying out MailRelay and it seems to be behaving the way I need it to.

To summarize, (I didn't change the sample file in the Pull Request but I think it will still work due to the defaults) the JSON file would change to this:

{
    "smtp_server": "smtp.fastmail.com",
    "smtp_port": 465,
    "smtp_starttls": false,
    "smtp_login_auth_type": false,
    "smtp_username": "[email protected]",
    "smtp_password": "secret_app_password",
    "smtp_max_email_size": 83886080,
    "smtp_skip_cert_verify": false,
    "local_listen_port": 2525,
    "local_listen_ip": "0.0.0.0",
    "allowed_hosts": ["*"],
    "allowed_senders": "*",
    "timeout_secs": 30
}

And allowed_senders can be the default "*" option or point to a text file like "allowed_ips.txt" (or whatever you want to name it really, so long as it has a new IP entry on each line).

The allowed_ips.txt file on my end looks something like this (as a few examples, the localhost ones would mainly need to be included for the local testing since it might fail otherwise):

::1
127.0.0.1
192.168.0.0/24
10.2.0.1/16
10.109.1.1/31
192.168.1.24

I did add a CLI test option as well to be able to quickly verify if an IP would be allowed or not and that can be called by using something like this:

./mailrelay -config="C:\mailrelay\mailrelay.json" -checkIP -ip "192.168.0.255"

The way I've used these new capabilities so far has been to create about 5 different instances of MailRelay running on the same server (each on a different port of course), but they are able to share the allowed_ips.txt settings (so that doesn't get repeated in each JSON file) and I'm able to use different Sendgrid API Keys in each case, which helps me to keep our Sendgrid statistics segmented (so I can more easily check Sendgrid and review recent activity details in the future if needed to troubleshoot something for example).

I think that should hopefully help others out that might have a similar need (and this helps us to move away from the Microsoft IIS 6 SMTP Server option and is much easier to configure / get up and running).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant