I just started off working with hMailServer 5.6.4 . I require a local database list storing email address in whitelist, greylist and the blacklist.
Whitelist - Email that are uninterrupted
Blacklist - Email that are automatically discarded
Greylist - Email is to be stored temporarily until a check is made
As i was looking through the database tables that were created, i did not see any "hm_blacklist" table. I did research online but did not get a clear answer if there is a blacklist or not.
Would anybody kindly advice me if hMailServer has blacklist table or not, or is it under a different name or we have to do some modification to include the table or something? Thank You.
(More on Blacklist... My intention is to store the sender's email address in the blacklist. This list would be used in future when filter email being received by the same user.)
Check the hmailserver rules,
You can create a rule like SPAM redirection when you find a keyword in the body or header.
You can apply such a rule in an account or in all existing accounts.
Better update such feature in the admin panel and not in the database to avoid caching issues.
Related
I'm currently running a SAAS application and mails are being sent from our application using Mailjet.
Some of the larger customers have been asking to allow the emails to be sent from their domain (e.g. info#largehotel.com) instead of our system (notifications#saasapp.com).
Are there any initial pointers I will need to look at? I'm guessing they will need to add our SPF records to their SPF records too and that they will need add a DKIM key that we generate for them to add to their records too? Then do some validation on them on the DNS level and mark them as validated?
I have some understanding to have customers run their own domain against our SAAS domain but a bit lost on the sending from their email domain requirement.
First, for the record, my SaaS platform does this (vía option 2b). It’s an e-commerce marketplace and I need the receipts to be sent from the email address of the product seller, not from me (the marketplace)
You have two(ish) options
Send email through your client’s mail servers (instead of mailjet)
Verify the client’s domain on your Mailjet (or similar email) service
option 1
With option 1, you’ll need to ask your client’s IT team to setup a username and password for you to access their SMTP server. This is essentially just like them creating an email account for you to use. This may seem like the easiest path available for you, but there are potential pitfalls and disadvantages:
Doing this, you will lose the mail open/click/bounce tracking functionality you get with mailjet; because you’ll be using the company’s SMTP server instead.
If you’re sending out as a fairly common email address (eg info#your-client.com) the client may already have that account active on their mail servers. That would allow them to receive replies into the existing infrastructure but make them wary of the security issues with sharing a password to their mail server with you.
You might find that they don’t even have the ability to give you a username and password. Modern mail services don’t allow for SMTP access (which is what your web app will need); and security conscious companies require 2 factor authentication on mail accounts (which your web app can’t answer)
Option 2
For this, you will need to ask their IT team to configure some DNS records to prove to mailjet, and to the email recipient, that you’re allowed to send on behalf of your client.
You did this for your own domain when you first setup mailjet. See https://app.mailjet.com/support/how-to-add-a-sender-address,96.htm for what this involves, but it’s a case of asking the client to configure a DNS record.
That tells mailjet that you’re allowed to send on behalf of that domain; but you’ll also want the client to adjust their SPF and DKIM records so as the recipient of the emails knows to trust Mailjet’s servers with emails sent from your client’s domain name. Normally, recipients only trust email sent from your client’s mail server (which you have as option 1) and distrust email sent from SAAS providers.
You will (or should) have done this on mailjet for your own domain already as well. https://app.mailjet.com/docs/spf-dkim-guide
So for this, you’ll need your client to setup 3 DNS records.
If you go this way, you could setup a separate Mailjet account which they and you have access to. That way they ca see their dashboard directly and feel a sense of ownership and security around it. But you won’t be able to markup the price of it 😜
Conclusion
How important is the tracking? If you can’t lose that you need to go with option 2.
How technically savvy is the client? Are they going to be able to have those DNS records changed? Are they going to be (rightly) security conscious around giving you an account on their main mail sever.
Option 2 would be my preference. You might need to hold their hand through the DNS setup so get it configured on Mailjet (And ask about SPF in here to make sure you get it right) so you can provide them with clear instructions of the specific 3 DNS records to create/update.
Whatever approach you take make sure you’re talking to the right people at your clients side soon. Their marketing team may be keen to do this with you, but if their IT feels left out of the conversation they will be difficult to get on board when you need them to make the changes. Us IT folk can be grumpy and obstinate 😀
your web app
This is going to need some adjustment. You probably already store your Mailjet credentials in a file or environment variables; these might need to move these to a dB table so you can relate credentials with specific accounts. But we’d need more info on the web app to be able to speak more to that side of the challenge.
option 2b
just as a note instead of a real suggestion. Be aware that some email service provers allow the sending verification part to be done by sending an email to someone on that domain (eg admin#yourclient.com) and then allowing sending vía the API if the recipient clicks on the approve link on that email. But, even with that setup you still need the client to configure SPF and DKIM on their DNS, so the extra one record isn’t a big ask. AWS’s SES allows for this. This works for me; but I have different requirements around deliver ability, and a large number of non-tech users (as opposed to your one or two big clients)
you can ask your client to generate programmatic(app key/password) user for email need to use for example info#largehotel.com and some other info like (host:gmail, protocol: smtp,...) all basic info needed then in your saas retrieve all this info to create object with client info that you stored before to send email for the target (from developer prospective non network engineering )
The SPF is the most important think to do. In most cases you have to be very careful about the IP reputation, but since you are using Mailjet it's up to them to manage this part.
Be attentive to the overall quality of the email, text/image ratio... Also offers a text body version of the content and dont forget the unsubscribe link. Since you already send emails with your service, I guess it's points are already correct.
I am learning how to configure postfix. I would like to setup a mail relay to only forward emails for specific recipients email addresses and block, or even better redirect to the block addresses to generic account for investigation.
The relay will be used in a development environment and I want to ensure that production emails addresses are not accidentally used in development or testing. As a specific example I would like to create a list of emails address recipients that mail is permitted to be forwarded to eg:
dev#example.com
test#example.com
Block any other address that the relay is asked to forward for example.com. Ideally I would like to forward all blocked to an account check#example.com to investigate.
Could some one point me to the section of the postfix configuration file I should look into?
Thanks
Densha
You'll have to do a couple parts to the setup.
Part 1 is your allowed list. What emails are allowed to be sent out. If this list will change frequently you'll want to look into using an external lookup like mysql for this. If you use flat files in the postfix configuration directory then you'll have to restart postfix for each change. With mysql it will perform a new lookup each time, no restart. Postfixadmin is a tool that may help in this case.
For your 2nd problem of redirecting all mail to another account for investigation see this other solution.
https://serverfault.com/questions/144325/how-to-redirect-all-postfix-emails-to-one-external-email-address
Given there is a "FAILTO=''" option for cfmail, triggering an email to be sent to that email if the email didn't get delivered...
Is there a way to somehow assign an ID or tracking # to an email, store it in a database with that ID... then update the status of that email if it fails?
I'd like to track bouncebacks... preferably WITHOUT sending the FAILTO to a POP3 or IMAP and then checking it with cfimap...
Is there any alternate way of handling this?
Maybe an event gateway that is triggered upon email failure?
UPDATE: I've decided to take a different approach, utilizing the sendgrid API.
I'm hoping that lends me with a few more tools than CF offers.
The short answer to your question is unfortunately no.
A longer version with a possible solution:
The failTo email address populates the return-path in the email header, this then 'should' be used by mail servers for bounce backs (however see - http://www.bennadel.com/blog/1899-GMail-Seems-To-Ignore-The-Return-Path-Header-Defined-By-The-CFMail-FailTo-Attribute.htm for an example where it doesn't)
So you are going to need to monitor an Imap or pop account to see your mails, however you can set up an event gateway to monitor this, with detailed instructions here - http://www.alagad.com/documentation/imapGateway/ImapWatcher%20Gateway%20Documentation.pdf
What you're left with is needing to identify which mail matches which bounceback, when I've done something similar in the past I used unique id's for the failTo email addresses at a domain I owned. If you set that up and then use your listener cfc to look for the id in the return-path.
So your sending code would work along the lines of:
Generate unique id
Send mail
Add row to database with unique id
Your listener.cfc would then need to inspect the email returned and if it finds the unique id update the row with whatever information that you're after.
Hope that that at least helps even if you'll need to set up some other bits.
You could use a directly watcher on the undelivr folder to log the failed emails, only really a solution if its own server and not a shared server though.
As far as I know once it leave the spool and is off to your SMTP server CF assume it's been sent correctly.
The email will trickle down the chain of SMTP servers/relays and if anything happen the only instruction they have is to bounce it back to the from address or failto address if present. CF isn't listening at this point so it can't respond.
We use an external tool called Glock email processor to handle exceptions. It's not free, but works pretty well. You can find it here: http://www.glocksoft.com/email-processor/
You need to configure it to check the failto address and from there you can take many actions. I got it setup as a three strikes system.
Email address bounce, I increment a counter in my email table, at 3 I deactivate that email from the system.
Nothing you can't do yourself with cfpop though.
I've had a good search on Google but can't find the answer sorry...
We're an Australian company who use a .com address as our primary contact point. Unfortunately sometimes people email to foo#ourdomain.com.au and so the email bounces.
I know I can manually create entries to forward the .com.au addresses to their .com equivalent, but it's not a particularly viable solution longer term.
Is there a way to automatically do that mapping at a server level? We have root access so I can set up whatever is required in that regard.
To re-iterate, everytime someone sends an email to:
foo#ourdomain.com.au
it needs to forward to
foo#ourdomain.com
and I'd prefer to automate the mapping as email addresses are added / removed quite regularly.
We are also using PLESK if that makes a difference.
Thanks...
Sounds to me like you don't need to forward at all. Just set the MX record for ourdomain.com.au to be the same as the MX record for ourdomain.com. Then configure the mail server to accept mail for both domains. The only case in which this isn't viable is if there are actually legitimate .com.au addresses that need to be handled by a separate mail server.
I've noticed that the domain
contoso.com
is often used in documentation when a sample is needed. I always figured this was a dummy domain, used like the telephone prefix "555" to route spam into some kind of telecommunicative void (although contoso.com appears to be a real site).
Is there a domain I can safely use when I have to, say, test a registration form 20 times with a unique email address and I don't care what happens to the message, yet I don't want it going to a real person?
You can use example.com. According to the Wikipedia article:
example.com, example.net, and example.org are second-level domain names reserved by the Internet Engineering Task Force through RFC 2606, Section 3,1 for use in documentation and examples. They are not available for registration.
By implementing the reservation, the Internet Assigned Numbers Authority (IANA) made available domains to use in manuals and sample software configurations. Thus, documentation writers can be sure to select a domain name without creating naming conflicts if end-users try to use the sample configurations or examples verbatim.
When an address such as "yourusername#example.com" is used to demonstrate the sign-up process on a website, it indicates to the user they should fill in an actual e-mail address at which they receive mail. "example.com" is used in a generic and vendor-neutral manner.
These domain names resolve to a server managed by ICANN.
I started using whatever#example.com for this purpose, but then I began getting responses back from my outgoing email server saying delivery to that address had been delayed. I don't know about the OP, but I want something that I can send to and completely forget about it.
Now I'm changing over to whatever#mailinator.com -- I know that it gets delivered to their catchall (so I'm not getting any junk back about delivery errors), and if I like, I can even go check at http://mailinator.com/ to see if the email went through as planned. (But it's not clogging up my inbox if I don't care about it.)
http://www.faqs.org/rfcs/rfc2606.html has all the standard reserved names. Notably, example.com and the like started resolving a few years ago. Before that they were truly reserved names, not even found in DNS. But they are still useful "fake" domains.
A simple way of testing email delivery is to use Gmail with the "plus" rule. We use this when registering our shared email account with some services that use unique email addresses as the username. This enables us to use a single inbox for all of the incoming registrations and filter the messages to all go to the same folder.
http://fieldguide.gizmodo.com/how-to-use-the-infinite-number-of-email-addresses-gmail-1609458192
One trick you may or may not have picked up about Gmail is that you
can add in periods anywhere in the front part of your address and it
makes no difference whatsoever: john.smith#gmail.com works just the
same as johnsmith#gmail.com. What's more, you can add a plus sign and
any word before the # sign (e.g. johnsmith+hello#gmail.com) and
messages will still reach you. If these tweaks make no difference,
then why use them? One major reason: filters.
how about example.com?
It is a valid domain, but reserved by RFC to be used for documentation.
Contoso.com is a dummy domain that can be used for testing.
It's used by Microsoft as an example whenever they need an example company or domain. They're the ones who registered it, and they use it frequently in their examples, so I doubt they care if you use it for testing. They likely ignore anything that goes it seeing as how its posted all over the web and a likely target for spam.
Frankly, I utilize an email address from my own testing email server for this because part of the testing is to ensure that the form information actually gets to the email address, and since checking it is outside of my normal work-flow, that means I have to actively do so.
We are using .local domains for that.
For testing purposes I like to have e-mail addresses that really do not exist and cannot be registered. Even access by IANA like for example.com is a no-go for security reasons. Accidently sent e-mails to max.mustermann#example.com maybe be delivered to servers controlled by IANA. This maybe an privacy issue for Max Mustermann and so on ...
Do not treat me wrong: This is just for additional security minimizing the risks whereever possible.
guerillamail.com for example is blocked by several blacklists (like http://www.block-disposable-email.com). So maybe it's better to use contoso.com.
you could configure your in house MTA to discard all example.com/net/org emails. you can be sure that no one would expect them to be delivered. and that would save your server from using resources and wasting bandwidth.
If it's email you want to test, why not use a disposable email address, such as GuerrilaMail? You can send an email to anyone#guerrillamail.com, or set your own user name, for a limited amount of time.BTW, Contoso is a Microsoft dummy site they've been using to demo .Net technologies for a couple of years now.