Here is how I set up LISTSERV for best deliverability with HDMail (I get 99.6%!) and to get around the current operational difficulties with very large messages, which I am told are being worked on. I regret that I cannot give exact step-by-step instructions as I have done all this over a period of time and using different software versions than the ones in use today, I also cannot cut and paste from actual configurations because my setup is more complex than most customers need. This stuff is complicated enough as it stands, unfortunately deliverability is no simple science. It could take an hour or two to set up, but over time you will save this by not having quite as many deliverability complaints.
The first thing to do is to assign a second IP address to HDMail, which I will call the "clean" IP address as this is the one that will get you the 99.6% rating (YMMV). The one you have today is probably pretty clean, but I will call it the "dirty" address anyway. Before using the new address, double-check that it is not in any blacklists and did not just get recycled from another mail server ;-) You probably should assign a different hostname to that address, rather than multi-host.
Before you even bind the new IP address to the Linux server running HDMail, go to "Configuration...Delivery...Outbound...Virtual Routing" in the HDMail interface and edit the default route to bind to the dirty IP address only. You will only want the new IP address used when you say so explicitly, never by default. Now make Linux listen to the new address, restart HDMail, go back to the same place in the menu and create a new virtual server group called NORMAL, bound to the clean IP address. As someone decided that virtual server group names should be case-sensitive, I strongly recommend repeating the process two more times with 'normal' and 'Normal' or an innocent typo can throw the whole scheme away. Double-check that all variants of 'normal' bind to the clean address and that the default is still the dirty address and nothing else. I don't remember if you then have to restart HDMail.
Next, in LISTSERV, configure three delivery pools, which I will call:
- L for postings to mailing lists (normally 99%+ spam-free).
- B for bulky messages posted to mailing lists (also spam-free but currently HDMail doesn't like them).
- And I let LISTSERV send administrative messages (which could be auto-responses to spam) with the default pool, which is called '-'.
So:
DEFAULT_LIST_POOL=L -
DEFAULT_DIST_POOL=L
SMTP_FORWARD_1=10*[HDMail];POOL=L
SMTP_FORWARD_2=2*[HDMail];POOL=-
SMTP_FORWARD_3=2*[another MTA];POOL=B
As usual, adjust the number of SMTP workers to your mileage. You may not need that many, just avoid going below 2.
Ok, now I want all messages in pool L to use the clean IP address, which means they must be tagged to the virtual server group created above, which can be done with:
SMTP_POOL_VSG=L:Normal
This feature is not in 15.0 Gold but I am pretty sure it is in the level set. If not, it is in 15.5. If you cannot enable it now, no big deal, you just will not be using the clean IP address yet, but you will be ready for it when you upgrade LISTSERV. If you make a typo in this keyword, your mail will appear to be lost but it will just be stuck in the HDMail spool until you define a virtual server group in HDMail with the exact spelling and case that you used here, restart, and wait 10 min or so. This is a bug that happens to be useful because you immediately see the problem. In the coming version, messages tagged to undefined groups will be delivered with the default group, in this case the dirty IP address. Mail will get through but your deliverability will not be as high as it should.
If you don't want to mess with this virtual server group stuff, you can also point pool '-' to any generic public MTA you might have for the whole organization and where there is no deliverability requirement. Personally, I prefer to keep all the mail I generate on the server I bought for that traffic.
The last thing to do is to assign bulky messages to the B pool. An easy way to do that is "Pool= B" in the corresponding lists, if these messages are inherently tied to specific lists. You can also enter header matching rules in HDMail if you are up for that, but personally I think too much of that is an incident waiting to happen as you keep staring at rule #51 and do not see that rule #43 also applied. If you have HPO, the best method is probably:
DIST_RULESET=IF &SIZE > 1024 THEN POOL B
This is a very powerful but complex feature that you need when you manage a large farm of LISTSERV servers and need fine-grained control over your load, dynamic pool reassignment to let one urgent special message out, etc. But you can just use the above to redirect any message over 1M to your B pool without opening the manual to learn the finer details of DIST_RULESET. You may need a lower value than 1M, in fact you could start with 256 and see where that takes you.
Eric
|
