Esurig emailig platform deliverability Neolae v6.0
This documet, ad the software it describes, are provided subject to a Licese Agreemet ad may ot be used or copied outside of the provisios of the Licese Agreemet. No part of this publicatio may be reproduced, stored i a retrieval system, or trasmitted, i ay form or by ay meas, electroic, mechaical, photocopyig, recordig or otherwise, without the prior writte permissio of Neolae. The iformatio cotaied i this documet is provided for iformatioal purposes oly ad may be revised without otice. It does ot costitute a commitmet o the part of Neolae. Neolae does ot guaratee the accuracy or the completeess of the iformatio cotaied withi this documet. Refereces to compay ames are iteded to be ficticious ad for illustrative purposes oly ad do ot refer to ay real-world compay. Ay brads cited are the property of their respective owers. Widows is the registered trademark of Microsoft Corporatio i the Uited States ad other coutries. Java, MySQL ad Ope Office are trademarks of Oracle Corporatio i the Uited States ad i other coutries. Liux is the registered trademark of Lius Torvalds i the Uited States ad i other coutries. This product icludes software developed by Apache Software Foudatio (http://www.apache.org/). For ay questios or queries, please sed a message to the followig address: doc@eolae.com. Versio umber : 6845 Neolae 18 rue Roger Simo Barboux, 94110 Arcueil - Frace +33 1 41 98 35 35 www.eolae.com
Table of Cotets Neolae v6.0 - Esurig emailig platform deliverability Chapter 1. Itroductio to deliverability................ 5 Foreword............................. 5 Recommedatios......................... 5 Maagig deliverability i Neolae................... 6 Chapter 2. Fuctioal recommedatios................ 7 Opt-out lik ad form........................ 7 Seder address.......................... 7 Duplicates............................ 8 Startig a ew platform....................... 8 White lists............................. 9 No commercial white lists..................... 9 Commercial whitelists....................... 9 Chapter 3. Techical recommedatios................ 11 Reverse DNS........................... 11 SPF.............................. 12 Cofiguratio of the applicatio................... 12 DNS cofiguratio........................ 12 Feedback loop.......................... 13 List Usubscribe.......................... 13 Presetatio.......................... 13 Istallatio........................... 14 Precedece tag.......................... 15 Presetatio.......................... 15 Istallatio........................... 15 DomaiKeys........................... 15 Itroductio.......................... 15 Overview........................... 16 Istallatio........................... 16 DKIM.............................. 19 Verifyig SMTP error messages.................... 19 MX Rules............................ 19 Verifyig bouce messages..................... 19 IP rotatio............................ 20 Neolae v6.0 - Esurig emailig platform deliverability 3
Neolae Exteral hostig............................. 20 Choice of domais........................... 20 Domai delegatio........................... 20 Choosig seder ad bouce mail addresses................ 21 Other aliases............................. 21 Chapter 4. Domai-specific coditios................... 23 Objet................................. 23 AOL.................................. 24 Feedback loop............................. 24 Whitelistig.............................. 24 Report Card............................. 24 MSN Hotmail.............................. 24 SederID............................... 24 Feedback loop............................. 25 Yahoo................................. 26 Feedback loop............................. 26 Whitelistig.............................. 26 DomaiKeys............................. 27 Gmail................................. 27 Mail.ru, ibox.ru............................. 27 Web.de................................ 27 Comcast................................ 27 Outblaze................................ 28 Usa.et................................ 28 Excite................................. 28 Mailtrust................................ 28 Uited Olie (NetZero, Juo)....................... 28 RoadRuer.............................. 28 EarthLik............................... 28 Cox.................................. 29 Bluetie................................. 29 Chapter 5. Blacklistig databases..................... 31 Objet................................. 31 Spamcop................................ 31 Spamhaus............................... 32 RFC Igorat.............................. 32 SORBS................................ 32 No-more-fu.............................. 32 URIBL................................. 32 ix Maitu................................ 32 Chapter 6. The Deliverability module.................... 33 Objet................................. 33 Techical moitorig........................... 33 Ibox moitorig............................. 34 Ibox rederig............................. 34 Chapter 7. SpamAssassi......................... 37 Presetatio.............................. 37 Istallatio............................... 39 4 Neolae 2013
CHAPTER 1 Itroductio to deliverability Table of Cotets Foreword............................. 5 Recommedatios.......................... 5 Maagig deliverability i Neolae..................... 6 Foreword Deliverability issues geerally result from ati-spam measures implemeted by iteret service providers ad admiistrators of e-mail servers. Such issues rage from IP-address blacklistig, which ca result i reduced throughput, to recipiet-side issues (such as the qualificatio of messages categorized as spam). Recommedatios Usolicited email has certai characteristics that you should avoid as much as possible: A icorrect etwork cofiguratio: Spammers try to coceal their real idetity ad as a cosequece make their servers difficult to idetify. A legitimate etwork cofiguratio that does ot try to hide the idetity of the server is essetial to sedig email i large volumes. Sedig to ivalid addresses: Spammers ofte use address geerators based o lists of frequet ames ad first ames; I additio, they rarely process techical otificatios set back by mail servers. A high rate of ivalid addresses is ofte iterpreted as a sig of spam. Double opt-i mechaisms ad effective hadlig of techical bouce messages make it possible to avoid this. High complait rate: ISPs usually have a promiet meas of reportig a received message as spam. This makes it possible to idetify ureliable sources. By rapidly hoorig opt-out requests, makig regular use of a give list, verifyig coset through a double opt-i system, ad implemetig feedback loops, you ca reduce complait rates. Sedig to hoeypot addresses: ISPs ad other orgaizatios (refer to http:/www.projecthoeypot.org/) make use of mailboxes that do ot correspod to physical persos but are created simply to trick spammers. These so-called "hoey pot" addresses are published o the Web i order to be collected by spambots ad thus catch illegitimate seders. The use of a double opt-i mechaism precludes this sort of address beig added to a list. Whe usig a third-party list, you must be sure of the methods employed by its maitaier. Aggressive vocabulary ad isistet use of images: To a lesser degree, the cotet of certai messages ca lead certai filters to detect it as spam. The use of certai words, the use Neolae v6.0 - Esurig emailig platform deliverability - Itroductio to deliverability 5
Neolae of exclamatio poits i the subject lie ad withi the messages are read as telltale sigs of spam. Spammers are also kow to replace text with images to stop offedig text from beig aalyzed automatically by ati-spam filters. I respose to this, a message (i HTML format) with a high proportio of images, or images as attachmets, may ed up beig blocked.. Maagig deliverability i Neolae Neolae icludes fuctioality to maage the risk of o-deliverability ad to track messages. See sectios The Deliverability module [page 33] ad SpamAssassi [page 37]. 6 Neolae 2013
CHAPTER 2 Fuctioal recommedatios Table of Cotets Opt-out lik ad form......................... 7 Seder address........................... 7 Duplicates............................. 8 Startig a ew platform........................ 8 White lists............................. 9 No commercial white lists...................... 9 Commercial whitelists........................ 9 Opt-out lik ad form By default, whe the message is aalyzed, a typology rule checks whether a opt-out lik has bee icluded ad geerates a warig if it is missig. It is possible to chage this rule so that a error is raised rather tha a simple warig ad stop a delivery from goig out without this lik. You must check that the opt-out lik works correctly before each time you sed: For example, whe sedig the proof, make sure the lik is valid, that the form is o-lie ad that validatig this chages the value of the No loger cotact this recipiet field to Yes. You should make this check systematically because huma error is always possible whe eterig the lik or whe chagig the form. If a problem is detected cocerig usubcriptio after the delivery is started, it is still possible to perform a usubscriptio maually (usig the mass-update fuctio, for example) for those recipiets who click the opt-out lik eve if they were ot able to cofirm their choice. As a geeral rule, do ot try to get i the way of recipiets who wat to opt-out by requirig them to fill out fields such as their email address or ame, for example. The form should have oe validatio butto oly, ad recociliatio should be performed o the ecrypted idetifier oly. Requestig additioal cofirmatio is ot reliable: a user may have two email addresses redirected to the same box. If the recipiet is able to remember the first address oly ad wishes to usubscribe via a message set to the other oe, the form will refuse this because the ecrypted idetifier ad the email address etered will ot match. Seder address Certai ISPs check validity of the seder address (From) before acceptig messages. A badly formed address may result i it beig rejected by the receivig server. You must make sure a correct Neolae v6.0 - Esurig emailig platform deliverability - Fuctioal recommedatios 7
Neolae address is give at the istace level (meu Tools >Advaced >Deploymet wizard...) or i the most frequetly-used scearios. Duplicates Havig duplicate email addresses ca have multiple cosequeces: The same message beig set more tha oce. Eve if Neolae performs a deduplicatio procedure by default before sedig, there is othig to stop the same message beig set by differet actios havig the same cotet whe a target is split. Usubscriptio requests ot hoored. If a recipiet usubscribes after receivig a message, their duplicate profile will still be eligible for future messages. Besides this side-steppig of opt-i procedures, this situatio will likely lead user to cosider the messages as spam ad to trigger a blacklistig procedure at the ISP. You must be especially prudet whe performig operatios o the database: Imports must be meticulously cofigured, i particular whe choosig the recociliatio key. Chaged email addresses ca also be a source of duplicates. I particular, two addresses with differet domais may be routed to the same mailbox, for example i the case of a compay that has chaged ame ad has maitaied the former domai for a certai period of time: joe.doe@amce-co.com ad joe.doe@acme-rebraded.com. Automatic imports, whether they be of lists or from other database are elemets to be take ito accout whe maagig profiles. What happes whe you delete or move a profile i aother partitio? It might be recreated i the iitial partitio by a automatic import, for example, whe a purchase order is placed. The storig of profiles i differet folders ca be implemeted usig views rather tha partitios. I this way, you are sure that the profiles are i the same physical partitio while still eablig the adequate rights to be displayed ad maaged. There are, all the same, cases i which duplicates betwee the differet partitios is ormal. For example, whe sedig for third-parties or differet compay etities, it is logical for the same perso to be a recipiet for differet reasos. It is, however, rarely ormal to fid duplicates withi the same partitio. Startig a ew platform Startig to sed email o a ew platform is a sesitive step because the platform does ot have ay history of use ad o reputatio (whe the sedig IPs have ever bee used for this purpose). ISPs are aturally suspicious of IP addresses that have ever bee used to sed email ad that suddely start to sed large volumes of email traffic. I effect, spammers geerally use "ukow" IP addresses (that is to say addresses that have ever bee blacklisted) to sed the largest possible umber of messages before detectio. You caot expect to reach operatioal speed i terms of output at the very start of the productio phase. Furthermore, you should ot attempt to sed messages at this rate as it might lead the ISPs to block the sedig addresses ad to severely compromise the rest of the start-up phase. Startig a platform ofte happes whe usig a list of addresses for the first time ad which may ot be fully qualified. If you sed to ivalid addresses or to hoeypot addresses this will cotribute to dimiishig the reputatio of the platform. If you have a list of ivalid addresses, it is i your best iterests to import it ito the quaraties table (Campaig Maagemet/Admiistratio/No deliverables Maagemet/No deliverables ad addresses) before sedig for the first times. If, all the same, you wish to requalify the ivalid addresses, it is by far preferable to do this oce the reputatio of the platform is established ad bit by bit i order to "dilute" the use of bad addresses over time. To summarize the priciples to be followed whe startig up: If you have this iformatio, importig ivalid addresses ito the quaraties table, Limitig the throughput rate (techical settig: limitig the umber of mtachilds), Progressively icreasig the volumes set: Do ot target the whole database from the very start, but rather add a extra fractio of the list each time you sed; This should eable you to icrease the volume at each step while reducig the overall rate of ivalid addresses Sed regularly: To a certai extet is is better to sed small shots regularly tha large campaigs sporadically, 8 Neolae 2013
Fuctioal recommedatios Payig close attetio to the delivery reports: high error idicators ca mea a techical settig is badly cofigured. White lists The mai iteret service providers (ISPs) ad Web mail providers maage whitelists from recogized email message seders. No commercial white lists To be accepted by these whitelists, the seder must pass a series of tests based o a techical verificatio (its email server must ot be a ope relay ad have a static IP) of the ifrastructure or its activity (delivery frequecy, volume, umber of complaits). If the seder does ot follow oe of these rules, it may be deleted from the whitelist. I its Neolae Email Deliverability package, Neolae offers a accompayig expert cosultig service for the certificatio process for o commercial whitelists. Commercial whitelists Commercial whitelists are based o a system that allows a seder through ati-spam filters or a icomig bous i the ati-spam. These payig white lists (CPT or o a aual basis) are offered by systems such as Retur Path Seder Score. ISPs are free to use these services ad the umber of ISPs ca vary depedig o the whitelist. A seder ca therefore better trusted after sedig these messages by havig a delivery guaratee. Certai whitelists also offer to ope images ad activate liks. Appearig i a whitelist is a udeiable asset for ay email campaig. I its Neolae Email Deliverability package, Neolae offers a commercial whitelist certificatio service such as CSA ad Retur Path Seder Score. Neolae v6.0 - Esurig emailig platform deliverability - Fuctioal recommedatios 9
Neolae 10 Neolae v6.0 - Esurig emailig platform deliverability
CHAPTER 3 Techical recommedatios Table of Cotets Reverse DNS............................ 11 SPF............................... 12 Cofiguratio of the applicatio.................... 12 DNS cofiguratio......................... 12 Feedback loop........................... 13 List Usubscribe.......................... 13 Presetatio........................... 13 Istallatio........................... 14 Precedece tag........................... 15 Presetatio........................... 15 Istallatio........................... 15 DomaiKeys............................ 15 Itroductio........................... 15 Overview............................ 16 Istallatio........................... 16 DKIM.............................. 19 Verifyig SMTP error messages..................... 19 MX Rules............................. 19 Verifyig bouce messages....................... 19 IP rotatio............................ 20 Exteral hostig.......................... 20 Choice of domais......................... 20 Domai delegatio......................... 20 Choosig seder ad bouce mail addresses............... 21 Other aliases........................... 21 Reverse DNS A tool to verify the cofiguratio of a domai: http://www.dsreport.com/ A importat poit i the etwork cofiguratio is makig sure a correct reverse DNS is defied for each of the IP addresses for outgoig messages. This meas that for a give IP address, there is a reverse DNS record (PTR record) with a matchig DNS (A record) loopig back to the iitial IP address. The choice of the domai for a reverse DNS has a impact whe dealig with certai ISPs. AOL, i particular, oly accepts feedback loops with a address i the same domai as the reverse DNS (see Feedback loop [page 24]). Neolae v6.0 - Esurig emailig platform deliverability - Techical recommedatios 11
Neolae SPF Refer to http://www.opespf.org/. A wizard is available to create SPF records. A tool to verify a SPF record: http://www.kitterma.com/spf/validate.html The SPF (Seder Policy Framework) is a techique that, to a certai extet, eables you to make sure domai ame used i a email is ot forged. Whe a message from a received from a domai, the DNS server of the domai is queried. The respose is a short record (the SPF record) that details which servers are authorized to sed emails from this domai. I the fial RFC 4408 specificatio (http://ew.opespf.org/sv/project/specs/rfc4408.txt), two elemets of the message are used to determie the domai cosidered as the seder: The domai specified by the SMTP "HELO" (or "EHLO") commad ad the domai specified by the address of the "Retur-Path" (or "MAIL FROM") header, which is also the bouce address. Differet cosideratios make it possible to take ito accout oe of these values oly; we recommed makig sure that both sources specify the same domai. Checkig the SPF provides a evaluatio of the validity of the seder's domai: Noe: No evaluatio could be performed Neutral: The domai queried does ot eable evaluatio Pass: The domai is cosidered as authetic Fail: The domai is forged ad the message should be rejected SoftFail: The domai is probably forged but the message should ot be rejected solely o the basis of this result TempError: A temporary error stopped evaluatio. The message ca be rejected o the basis of other iformatio. PermError: The SPF records of the domai are ivalid It is worth otig that records made at the level of the DNS servers ca take up to 48 hours to be take ito accout. This delay depeds o how ofte the DNS caches of the receivig servers are refreshed. Cofiguratio of the applicatio To defie the domai used for the HELO commad, edit the cofiguratio file of the istace (cof/cofig-istace.xml) ad defie a "localdomai" attribute as follows: <servercof> <shared> <dscofig localdomai="modomaie.et"/> </shared> </servercof> The MAIL FROM domai is the domai used i techical bouce messages. This address is defied i the deploymet wizard or via the NmsEmail_DefaultErrorAddr optio. DNS cofiguratio A SPF record ca curretly be defied o a DNS server as a TXT type record (code 16) or a SPF type record (code 99). A SPF record takes the form of a character strig. For example: v=spf1 ip4:12.34.56.78/32 ip4:12.34.56.79/32 ~all defies the 2 IP addresses 12.34.56.78 ad 12.34.56.79 as authorized to sed emails for the domai. ~all meas that ay other address should be iterpreted as a SoftFail. Recommedatios for defiig a SPF record: Add ~all (SoftFail) or -all (Fail) at the ed to reject all servers other tha those defied. Without this, servers will be able to forge this domai (with a Neutral evaluatio). Do ot add ptr (opespf.org recommeds agaist this as costly ad ureliable). 12 Neolae 2013
Techical recommedatios Feedback loop A feedback look works by declarig at the ISP level a give email address for a rage of IP addresses used for sedig messages. The ISP will sed to this mailbox, i a similar way as what is doe for bouce messages, those messages that are reported by recipiets as spam. The platform should be cofigured to block future deliveries to users who have complaied. It is importat to o loger cotact them eve if they did ot use the proper opt-out lik. It is o the basis of these complaits that a ISP will blacklist a IP address. Depedig o the ISP, a complait rate of aroud 0.3% will result i the blacklistig of a IP address. A stadard is curretly beig draw up to defie the format of feedback loop messages: the Abuse Feedback Reportig Format (ARF). See http://www.mipassoc.org/arf/ for further details. Implemetig a feedback loop for a istace requires: A mailbox dedicated to the istace, which may be the bouce mailbox, IP sedig addresses dedicated to the istace. Implemetig a simple feedback loop i Neolae uses the bouce message fuctioality. The feedback loop mailbox is used as a bouce mailbox ad a rule is defied to detect these messages. The email addresses of the recipiets who reported the message as spam will be added to the quaratie list. Create or modify a bouce mail rule, Feedback_loop, i Admiistratio>Campaig Maagemet>No deliverables Maagemet>Mail rule sets with the reaso Refused ad the type Hard. If a mailbox has bee defied specially for the feedback loop, defie the parameters to access it by creatig a ew exteral Bouce Mails accout i Admiistratio>Platform>Exteral accouts. The mechaism is operatioal immediately to process complait otificatios. To make sure this rule is workig correctly, you ca temporarily deactivate the accouts so that they do ot collect these messages ad the check the cotets of the feedback loop mailbox maually. O the server, execute the followig commads: lserver stop imail@istace lserver imail -istace:istace -verbose If you are forced to used oe sigle feedback loop address for multiple istaces, you must: Replicate the messages received o as may mailboxes as there are istaces, Have each mailbox picked up by oe sigle istace, Cofigure the istace so that they process oly those messages that cocer them: the istace iformatio is icluded i the Message-ID header of messages set by Neolae ad is therefore located also i the feedback loop messages. Simply, specify the checkistacename parameter i the istace cofiguratio file (by default, the istace is ot verified ad this may lead certai address to be quaratied icorrectly): <servercof> <imail checkistacename="true"/> </servercof> List Usubscribe Presetatio This techique ivolves addig a header to your emails with the followig format: List-Usubscribe :<http://domai.com/usubscribe.jsp?id=ecryptedid> Neolae v6.0 - Esurig emailig platform deliverability - Techical recommedatios 13
Neolae MSN Live ad Gmail support this method ad a usubscribe butto is available directly i their iterface. This techique lowers complait rates. Istallatio Neolae eables you to add additioal SMTP headers via the delivery wizard. Specify oe of the followig list-usubscribe parameters: 1 List-Usubscribe: <mailto:usubscribe@domai.com> Clickig the usubscribe lik opes the user's default email cliet. 2 List-Usubscribe: <http://domai.com/usubscribe.jsp> Clickig the usubscribe lik redirects the user to your usubscriptio form. Example: 14 Neolae 2013
Techical recommedatios Precedece tag Presetatio Some ISPs ask for mass seders to add a tag to their header which allows them to be idetified. A good example is Gmail where this tag is a pre-requisite. Istallatio Neolae lets you add additioal SMTP headers usig the delivery properties, like the 'list usubscribe' tag. This type of SMTP additio ca also be added to certai domais oly. For example, to oly iclude this SMTP header i Gmail, the fuctio is as follows: <% if (recipiet.domai == 'gmail.com') { %> Precedece: bulk <% } %> DomaiKeys This techology, maily sposored by Yahoo, ca be implemeted i Neolae. Itroductio DomaiKeys is a specificatio usig public key techology to digitally sig a email to prove the origi of the message. Neolae v6.0 - Esurig emailig platform deliverability - Techical recommedatios 15
Neolae Note: The approvig domais curretly Domaikeys are: Yahoo, Gmail. Overview Private ad public key Selectors The domai ower geerates a pair of keys (public/private) that will be used to sig the messages set by the users of this domai. The public key is placed i the DNS of the domai as a TXT type record. The private key is kept o the messagig server that seds emails for this domai. Whe a email is set by the user of the domai, the messagig server uses the private key to sig the message. The sigature is added to the message header before it is set. Whe a siged message is received, the messagig server reads the sigature ad message domai the queries the DNS i order to obtai the public key of the domai. With this public key, the messagig server the checks whether the sigature of the message is valid. Selectors eables a domai to have multiple public keys i the DNS. The admiistrator ca the choose a give key depedig o the type of traffic. If the selector is 'test' ad the domai is 'example.com', the public key will be available from the test._domaikey.example.com TXT-type DNS record. The ame precedig _domaikey is the selector. Neolae uses default as the default selector. Istallatio This sectio describes the required cofiguratio i Neolae to eable DomaiKeys. Prerequisites You must be able to update the DNS records for your domai. Geeratig the keys From a commad prompt, use the followig sytax: $ opessl gersa -out rsa.private 1024 The result is a rsa.private file such as: -----BEGIN RSA PRIVATE KEY----- MIICXQIBAAKBgQCUBBPm/6CGCw3Imbgka0GWIp95KTlE645kZVLp3MWLMox4bQUu 2Jks9+3eg/qk5ITFmxH//LB6efRgroW005E7u18Z4FPWj0rKUuGYQTbMLq7+sB KmSZNiVFcuGCl3O8oA7EPPuf0oK9B84FAwp94cBw5qzSdkvd5bMMCwkfVQIDAQAB AoGAWgo8/SmFweTZhq0UGtwk18Oecr8/pL4tNP6Yy8csHeYge132K6ER5muhszs XQByUC7r/Tf/NxIW+fVQeta0lpRki+SBvQOJyzTfXYf1S9XyyIgbPmVz8sQK2Wr KdzUeM1ueSuL82dPJXvkXaXirpm0rSHSYu0D7878/CGzxaUCQQDFUAXsIq3u+iwl 27kkMPKqAb96fUxmF14huxmoB6oMbblFwAT94IxfoXOR5lwEoHZvklcfk0wiIyk vuv+fj1/akeawap1narz6wtychft+rumai5czyfc9bmacestkvmlb3411ooql5qp m2vaeuuw3i8gmji3uzdj18gtetv6s61kwjballzeku0ogx/3zybqzpqemt3kkts pklzrpnomldkgy0g1+snxjw7mxr//ujozjffet4kp+c+goje2+9/7ceekcqgrb ptz/hj2be3vwmkoeos86hgwzk2obsrhmqzdt5t2sfw4lpt3ddavtdjhsvfpira +zfmtsqpxz41fqzrd8cqqdccfvqumtmasfv5hgqjoplox8a6ivfnmsk7p0gpvt 2iwz49E+Os0q5AhghyOmxsmwLjUOmptLBrWMR/gt2w7Q -----END RSA PRIVATE KEY----- 16 Neolae 2013
Techical recommedatios Note: Neolae supports 512, 768, 1024, 1536 ad 2048-bit keys. To date, a miimum legth key is ot a prerequisite, however, it is geerally accepted that a 512-bit key ca potetially by falsified. The legth of the key ca have a impact o throughput (if CPU is a limitig factor): 512 bit: - 19 % compared to sedig usiged 768 bit: - 37 % 1024 bit: -60 % 1536 bit: -80 % 2048 bit: - 90 % To extract the public key from the private key, use the followig commad: $ opessl rsa -i rsa.private -out rsa.public -pubout -outform PEM The result is a rsa.public file such as: -----BEGIN PUBLIC KEY----- MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCUBBPm/6CGCw3Imbgka0GWIp95 KTlE645kZVLp3MWLMox4bQUu2Jks9+3eg/qk5ITFmxH//LB6efRgroW005E7u18 Z4FPWj0rKUuGYQTbMLq7+sBKmSZNiVFcuGCl3O8oA7EPPuf0oK9B84FAwp94cBw 5qzSdkvd5bMMCwkfVQIDAQAB -----END PUBLIC KEY----- I Widow, you must dowload the OpeSSL library from the followig URL: http://www.opessl.org/related/biaries.html Savig the public key i the DNS Creatig a TXT-type DNS record for selector._domaikey.example.com : Sytax for BIND default._domaikey.example.com. IN TXT "k=rsa; t=y; p=migfma0gcsqgsib3dqebaquaa4gnadcbiqkbgqcubbpm /6CGCw3Imbgka0GWIp95KTlE645kZVLp3MWLMox4bQUu2Jks9+3eg /qk5itfmxh/ /LB6efRgroW005E7u18Z4FPWj0rKUuGYQTbMLq7 +sbkmsznivfcugcl3o8oa7eppuf0ok9b84fawp94cbw5qzsdkvd5bmmcwkfvqidaqab" Sytax for DJBDNS (TINYDNS) 'default._domaikey. example.com:k=rsa;t=y; p=migfma0gcsqgsib3dqebaquaa4gnadcbiqkbgqcubbpm /6CGCw3Imbgka0GWIp95KTlE645kZVLp3MWLMox4bQUu2Jks9+3eg /qk5itfmxh/ /LB6efRgroW005E7u18Z4FPWj0rKUuGYQTbMLq7 +sbkmsznivfcugcl3o8oa7eppuf0ok9b84fawp94cbw5qzsdkvd5bmmcwkfvqidaqab;:86400 The parameters of the record are defied with the sytax parameter=value. The valid parameters are: g= defies the applicability of the key i relatio to the local ame of the seder. g=*: eables all seders i the domai example.com to use the key, g=seder;: eables this key to used for messages set from expediteur@example.com. k = key type. Oly the value rsa is supported. This parameter is optioal. = ote cocerig the key. This ote is iteded for admiistrators ad is ot used by the sigature ad autheticatio processes. This parameter is optioal. p = public key ecoded i Base64. A empty value meas that the key has bee revoked. This parameter is madatory. t = flags defiig attributes. Oe sigle attribute is curretly defied by the specificatio: t=y meas that the domai is usig this key i test phase. The public key ecoded i Base64 correspods to the cotets of the rsa.public file betwee the lies:. ----- BEGIN PUBLIC KEY----- ad -----END PUBLIC KEY----- Neolae v6.0 - Esurig emailig platform deliverability - Techical recommedatios 17
Neolae You must also delete the spaces ad the carriage returs. Savig the private key i Neolae The private key is saved i the form of a optio i the Neolae database. Coect to Neolae as the Admiistrator ad the create a optio: Iteral ame: selector_rsa_private_key_domai Type: Log text Value: The private key ecoded i Base64. I the iteral ame of the optio, the selector part is optioal. As the default selector i Neolae is default, the default_rsa_private_key_example.com ad RSA_PRIVATE_KEY_example.com optios are equivalet. Importat: For the domai value, the period is chaged by Neolae to the uderscore character "_". The private key populated i the optio must be the exact cotets of the rsa.private, icludig ----- BEGIN PRIVATE KEY----- ad -----END PRIVATE KEY-----. Eablig hadlig of DomaiKeys To eable the sigig of messages for a domai, go to the Admiistratio / Campaig maagemet / No deliverables Maagemet / Mail rule sets folder ad the select Domai maagemet from the list. If the domai is already i the list, simply select the DomaiKeys database, else create a ew rule for this domai ad the select the DomaiKeys optio. Importat: Eablig sederid o the domai forces the techical domai to be used to sig the message. Eablig sederid with DomaiKeys may be useful whe maagig multiple seder domais. Testig the cofiguratio The easiest is to create a test mailbox o yahoo.com. If DomaiKeys is correctly cofigured, you should receive a message from Yahoo! usig the address of the seder cofirmig the origi of the message. Further iformatio is give i the full headers: 18 Neolae 2013
Techical recommedatios DKIM DKIM results from a combiatio of the DomaiKeys, Yahoo! ad Cisco Idetified Iteret Mail autheticatio priciples ad is used to check the autheticity of the seder domai ad guaratee the itegrity of the message. DKIM is a improvemet o DomaiKeys, ad will supersede it i the future. Note: Fuctioality available from build 1937 owards. If you have cofigured DomaiKeys for your Neolae istace, you just eed to select dkim i the domai hadlig rules. If ot, follow the same steps (private/public key) as for DomaiKeys. It is ot ecessary to eable both DomaiKeys ad DKIM for the same domai as DKIM is a improved versio of DomaiKeys. The followig domais curretly validate DKIM: aol, gmail. Verifyig SMTP error messages The SMTP errors that are ot checked by a give rule are listed i the Admiistratio/Campaig Maagemet/No deliverables Rules/No deliverables Rules folder. These error messages are by default iterpreted as ureachable soft errors. The most commo errors must be idetified ad a correspodig rule added i Admiistratio/Campaig Maagemet/No deliverables Rules/Mail rule setsl if you wish to correctly qualify the feedback from the SMTP servers. Without this, the platform will perform uecessary retries (case of ukow users) or to wrogly place certai recipiets i quaratie after a give umber of tests. Neolae recovers the ew SMTP error rules, geerated whe sedig emails to every sigle cliet, usig its Deliverability platform. The total umber of errors geerated from these ew rules is accumulated ad allows Neolae to qualify these ew rules whe it reaches a critical umber of errors. These rules are updated daily via a specific workflow. For this, you must ope a https type flow. Aother importat poit: the cliet ca qualify a rule i his istace. However, if this is the qualified i a Neolae deliverability istace, it is the deliverability istace qualificatio that will be take ito accout by default. MX Rules MX rules (Mail exchager) correspods to the commuicatio maagemet rules betwee a sedig server ad a receivig server. Depedig o the material capacities ad the iteral policy, a ISP will accept a predefied umber of coectios ad messages per hour. This variables may be modified automatically by the ISP system depedig o the reputatio of the IP ad sedig domai. Via its deliverability platform, Neolae maages more tha 150 specific rules by the ISP, ad, i additio, oe geeric rule for other domais. This rules are updates via a daily workflow i order to regulalry supply the cliet istace. Note: For more iformatio, refer to the MX rules & Bouces. Verifyig bouce messages As for the SMTP errors, uprocessed bouce mail or bouce mail processed by Igored type rules must be moitored to determie whether ew rules should be added. For this, it is possible to specify a address the platform will forward these messages to. Neolae v6.0 - Esurig emailig platform deliverability - Techical recommedatios 19
Neolae IP rotatio I particular whe startig up a ew platform, we recommed implemetig a system of rotatig the IP addresses used at the hardware level. This cosists of keepig a certai umber of IP address as backup addresses if the IP addresses beig used are blacklisted by a ISP. You ca start reusig the IP addresses you have let 'lie fallow' oce the restrictio is raised, i geerally after a few hours or at worst a few days. You must, however, make sure each IP is used regularly (at least 100 messages over a day per moth) so that it does ot lose its reputatio or get removed from the feedback loops or whitelists. Whe the reputatio of the platform is firmly established, you may cosider usig all the IPs permaetly. Exteral hostig Whe discussig sedig emails, we shall refer to exteral hostig whe the Neolae platform is: Etirely hosted exterally (database, trackig servers ad MTA servers), I mid-sourcig mode: the database ad applicatio server are located withi the local etwork whereas the MTA portio is exteralized. Choice of domais Exteral hostig, for techical reasos, implies almost systematically that the domai used i the techical sedig addresses ad the tracked liks is differet from the mai address of the seder. For example: The advertiser uses the domai domai.com i all commuicatios The hoster caot techically use this domai to receive bouce messages because domai.com is the corporate messagig domai ad is ot iteded for such purposes. The hoster ca techically use domai.com for trackig because it is used by the Web site of the advertiser. The hoster must therefore use a differet domai that we will refer to as a techical domai, for example dml.et. This domai will be used to receive bouce mail ad redirect tracked liks. With this said, we will make two poits: 1 The seder address (From), which is the most commoly displayed address, ca always be give as the address of the advertiser domai.com 2 The tracked liks withi the message will use the techical domai dml.et To date, this way of operatig is permitted, however: If we cosider Hotmail, usig SederId will display the seder as From: dm-bouces@dml.et o behalf of Marketig Domai (marketig@domai.com), which may cofuse the recipiet as to the origi of the message. If the message is supposed to be set by a advertiser recogized by the domai domaie.com, the a email cotaiig liks usig the domai dml.et could be cosidered as a attempt at phishig. I extreme cases, certai ati-spam filters may reject the message as suspicious based o the differece betwee the bouce domai ad the seder domai. It is therefore icreasigly importat that there is o doubt as to the autheticity of the seder based o the techical sedig domai. For this reaso, we recommed usig a techical sedig address that is a sub-domai of the advertiser's domai. I the previous example, we could use l.domai.com, ad i this way a recipiet would have o doubt that the techical seder of the message ad the tracked liks really do come from domai.com. The bouce address as l.domai.com ca be maaged directly by the hoster ad the trackig liks l.domai.com ca poit to their redirectio servers. Domai delegatio If a sub-domai eeds to be set up by the hoster it must be iitiated by the domai ower (the advertiser). It is techically possible for the ower to perform the DNS cofiguratio (MX, A, SPF...) of the sub-domai, however we advise agaist this because the hoster depeds o it for ay modificatio made to the DNS ad this is a potetially dagerous situatio (risk of losig bouce mail, or failure of trackig mechaisms) give the costraits of ruig a email platform. Neolae strogly recommeds delegatig the sub-domai to the hoster. 20 Neolae 2013
Techical recommedatios To delegate the admiistratio of a sub-domai to a third party, the ower of the mai domai must declare NS records for the sub-domai desigatig the DNS servers of the hoster. Note: For more iformatio about domai delegatio, refer to the Domai delegatio documet. Choosig seder ad bouce mail addresses Because the seder address is the most visible address to the recipiet, there should be o doubt as to its idetity ad should be defied usig the domai of the advertiser or at least a sub-domai, for example marketig@domai.com or marketig@l.domai.com. If the SPF record of the advertiser's domai authorizes the IP addresses used by the platform, it is ot ecessary to eable the Seder ID parameter i Neolae for MSN Hotmail domais ad the choice of the address for bouce messages is ot restricted. If the SPF record of the advertiser's domai does ot authorize the IP addresses used by the platform, the Seder ID parameter will have to be used for MSN Hotmail. I this case, the bouce address is give to the recipiet i the message header. You must choose a address that does ot suggest spam, meaig a address that refers to the seder ad does ot appear to be too techical, for example marketigerr@dml.et rather tha dm-bouces405@dml.et. Other aliases Neolae eables you to defie differet aliases for trackig, mirror pages ad web forms ad thus defie a architecture that is appropriate for the availability ad productio costraits you have. To maitai cosistecy betwee these domais, you ca, for example, defie extra sub-domais as show below: Trackig: l.domai.com Mirror pages: m.l.domai.com Web forms: f.l.domai.com Neolae v6.0 - Esurig emailig platform deliverability - Techical recommedatios 21
Neolae 22 Neolae v6.0 - Esurig emailig platform deliverability
CHAPTER 4 Domai-specific coditios Table of Cotets Objet.............................. 23 AOL............................... 24 Feedback loop.......................... 24 Whitelistig........................... 24 Report Card........................... 24 MSN Hotmail............................ 24 SederID............................ 24 Feedback loop.......................... 25 Yahoo.............................. 26 Feedback loop.......................... 26 Whitelistig........................... 26 DomaiKeys........................... 27 Gmail.............................. 27 Mail.ru, ibox.ru.......................... 27 Web.de............................. 27 Comcast............................. 27 Outblaze............................. 28 Usa.et............................. 28 Excite.............................. 28 Mailtrust............................. 28 Uited Olie (NetZero, Juo)..................... 28 RoadRuer............................ 28 EarthLik............................. 28 Cox............................... 29 Bluetie.............................. 29 Objet This sectio describes the specific mechaisms of a represetative selectio of ISPs i the B2C area. Readig the message headers received by the ISPs is ofte a good idicatio of how the messages are cosidered i relatio to spam. Email software ad Webmail services geeral eable you to display the message headers i full (usually, by default, o the seder, date, subject ad recipiet are show). Neolae v6.0 - Esurig emailig platform deliverability - Domai-specific coditios 23
Neolae AOL AOL provides high-volume seders with feedback loop ad whitelistig services. Whitelistig eables messages from certai IP addresses to be delivered without filterig. It is essetial to implemet a feedback loop before requestig whitelistig because whitelistig will oly be accepted if there is low complait rate for the sedig IP addresses, which is ulikely if the feedback loop is ot implemeted. You must the wait for at least 30 days before requestig whitelistig. Feedback loop The followig form eables you to request a feedback loop: http://postmaster.aol.com/fbl/. Oce validated, you will receive a email with a cofirmatio lik at the feedback address. You must make sure, before validatig this form, that the mailbox is workig ad that you ca collect its cotets. After validatig the lik, the service is usually implemeted withi 24 hours. The rule for bouce otificatios from AOL is already implemeted i Neolae Whitelistig Whitelistig requests ca be made from http://postmaster.aol.com/whitelist/idex.html. O request, AOL will moitor outgoig emails ad complait rates over a period of 3 weeks. After such time, a decisio is made ad otificatio set to the cotact address specified i the form. Importat: The whitelistig form goes had i had with a feedback loop request. If both whitelistig ad feedback loop requests are made, the feedback loop messages will be set twice. Report Card O days whe the complait rate exceeds 0.1%, AOL automatically seds a Report Card to the postmaster address of the domai metioig the complait rate ad ecessity of maitaiig a low rate. These messages are set from postmaster@aol.com with a subject such as AOL email cocers for yourdomai.com. This idicator eables you to evaluate the correct fuctioig of the feedback loop ad the opt-i mechaisms. MSN Hotmail Refer to http://postmaster.ms.com/. The site has a form to cotact techical support. Cosult the complait rates for IP addresses: http://postmaster.ms.com/sds/. Usig this service eables you to moitor, o a daily basis ad for each IP address, the complait rates ad the umber of messages received by hoeypot addresses. To use this service, you must be able to receive messages set to oe of the followig email addresses whose domai ame is deduced by reverse DNS ad the RIPE database usig the requested IP addresses: abuse@domai postmaster@domai A message with the cofirmatio data will be set to the oe of these addresses. If you cotact MSN Hotmail support, you will lear that spam filterig is operated by two differet etities. Emails received are first processed by Symatec (cotact Symatec Brightmail, <ivestigatio@review.symatec.com> for ay queries due to filterig at their level) who filters messages based o complait rates ad the umber of messages received at hoeypot addresses. Secodly, MSN Hotmail processes those messages that have bee let through by Symatec. At this level, they are ot aware of the reasos for which messages are blocked at the Symatec level. SederID MSN Hotmail is implemetig a email autheticatio techology called SederID. It is essetially a variat of the SPF recommedatios. 24 Neolae 2013
Domai-specific coditios The DNS cofiguratio required for SederID is more striget tha that required by SPF. I particular, 3 records SPF, MX ad A are checked for the sedig domai. The Microsoft wizard http://www.microsoft.com/mscorp/safety/cotet/techologies/sederid/wizard/default.aspx eables you to verify the DNS cofiguratio of a domai ad offers help i defiig the SPF record. Certai headers are iterestig from this poit of view: X-SID-PRA: Marketig Domai <marketig@domai.com> X-SID-Result: TempError From: Marketig Domai <marketig@domai.com> Retur-Path: dm-bouces@dml.et The X-SID-PRA header is the address of the purported resposible seder (for more iformatio o the PRA, refer to http://www.microsoft.com/mscorp/safety/techologies/sederid/resources.mspx), calculated from other lies i the header as the address most represetative of the idetity of the seder. It is the domais i this address ad the Retur-Path address that are used as the referece for checkig the SPF records. If there are specific costraits for the domais used, usig a proprietary extesio of the SederID techology it is possible to cofigure the SPF records so that they oly apply to the Retur-Path or the PRA. Note: If the seder address (From) does ot match the PRA, Microsoft recommeds displayig both addresses explicitly i the email cliet, which has the effect of showig the bouce address to the fial recipiet. Thus, i Hotmail, is seder is show as follows: From: dm-bouces@dml.et with the ame Marketig Domai (marketig@domaie.com) I order to make sure the bouce address does ot appear i the message header, you must apply the followig recommedatios: 1 Disable SederID i Neolae. 2 Make sure there is a valid SPF for each of the sedig domais 3 Make sure there is a valid public domaikey for each of the sedig domais. The X-SID-Result header gives the SederID evaluatio of the message upo receipt. The values used are the same as defied i the SPF. If the sedig ad the DNS records are correct ad a TempError is evaluated, it may be a problem of a obsolete DNS cache. MSN Hotmail uses a cache mechaism for SederID. To make sure the record is i the cache, simply fill i the olie form at the followig address: https://support.ms.com/eform.aspx?productkey=sederid&page=support_sederid_optios_form_byemail&ct=eformts Note: Whe sederid is selected i Neolae, a Seder header with the bouce mail address is added to the messages. Thus the PRA value matches the bouce mail address. Feedback loop Below is a questioaire for compaies/cliets iterested i this program: 1 Your compay ame, the primary cotact ad a cotact e-mail 2 Does your compay follow stadard CAN-SPAM Act practices? 3 The opt-out lik for each list. Please iclude a fuctioal lik that we ca use for a oe time test. If you require users to have a accout, please provide a accout that we ca access ad close for the purpose of testig. 4 The home page where people sig up for each list. 5 Seder IPs for verificatio. 6 Is the IP address registered uder your compay's ame/domai ame? Or do you have exclusive sedig rights from the IP via your hostig compay (ot shared with ay other seders)? Please provide supportig documetatio. 7 Ca you remove recipiets that complai from these lists? Neolae v6.0 - Esurig emailig platform deliverability - Domai-specific coditios 25
Neolae If the aswers to items 6 ad 7 are "o", Microsoft will be uable to eroll your compay at this time. The aswers to questios 6 ad 7 must be yes i order to use a feedback loop. With Neolae, aswer to questio 7 is yes. You ca request a feedback loop by fillig i the followig form: http://postmaster.live.com/services.aspx#jmrpp The service will retur a so-called Juk E-Mail Reportig Agreemet, which you must complete ad sig digitally. At the same time, you must sed the techical details of the feedback loop required by email: 1 Name of the pricipal compay cotact, 2 Address, 3 Telephoe umber, 4 Email address, 5 The IP addresses used (a maximum of 150, separated with semi-colos), 6 The email address of the feedback loop, 7 The maximum umber of emails to sed per day usig the feedback loop (optioally o limit), 8 The message format: Attached accordig to RFC 822 or the origial messages. For questio umber 8, you must choose format RFC 822. The bouce mail rule for Hotmail is already implemeted i Neolae. Yahoo Refer to http://help.yahoo.com/help/us/mail/defer/ Two items from the header are used to qualify the sedig platform: X-YahooFilteredBulk: 12.34.56.78 Autheticatio-Results: mta244.mail.mud.yahoo.com from=domai.com; domaikeys=eutral (o sig) A X-YahooFilteredBulk header meas that the message was directed to the user's spam folder. The Autheticatio-Results header gives the evaluatio of the seder usig the Domai Keys techology. I the example, domaikeys=eutral (o sig) meas that the sedig platform has ot implemeted this techology. Feedback loop The followig form eables you to request a feedback loop: http://feedbackloop.yahoo.et. Note: 1 The Yahoo feedback loop (FBL) is based o the domai, as opposed to other FBL that are based o the IP. 2 I order to implemet a feedback loop, you must: have a Yahoo FBL accout, use the DomaiKeys or DKIM autheticatio stadard. Whitelistig Without a prior request, Yahoo will cosider messages set from a ukow IP address as spam ad users will receive these messages i the correspod folder of their webmail. A whitelistig request ca be made usig the form at http://help.yahoo.com/l/us/yahoo/mail/postmaster/forms_idex.html. 26 Neolae 2013
Domai-specific coditios Importat: Whe you request whitelistig from Yahoo, it is very importat to correctly uderstad ad scrupulously respod to all the questios. If you do ot do this, Yahoo will probably reject your request ad at the same time recommed that you review your practices before makig a ew request i 6 moths time. Yahoo will the moitor messages set over a period of several days. Durig this time, emails will be received i either the ibox or the spam folder. Yahoo will make a decisio to whitelist the platform based o this. This period usually lasts about 3 weeks. DomaiKeys Whe the domai validated by DomaiKeys is idetical to the seder domai, Yahoo displays a key to tell the user that the seder is legitimate ad tested by DomaiKeys. Gmail Gmail uses SPF ad DKIM. Usig a Gmail accout is also a good way of checkig the SPF is cofigured correctly. If the SPF is cofigured correctly, messages received will iclude the followig i the header: Received-SPF: pass (gmail.com: domai of istace-bouces@modomaie.et desigates 123.45.67.89 as permitted seder) Received-SPF: pass (gmail.com: best guess record for domai of postmaster@mydomai.com desigates 234.56.78.90 as permitted seder) Whe the SPF is ot defied for the domai, this lie will look like the followig: Received-SPF: eutral (gmail.com: 34.56.78.90 is either permitted or deied by domai of bouces@l.mydomai.et) Fially, whe the seder address is forged, the header cotais the followig lie: Received-SPF: softfail (gmail.com: domai of trasitioig usurpe@spammeur.et does ot desigate 98.76.54.32 as permitted seder) Gmail also checks the DomaiKeys sigatures. Mail.ru, ibox.ru Refer to http://wi.mail.ru/cgi-bi/support_bl?ip=ip1.ip2.ip3.ip4 Web.de It is possible to cotact techical support via the o-lie forms available at the followig address: https://www2.kudeservice.web.de/agebote/freemail/klasse/abuse/ Comcast You ca request a feedback loop usig the followig form: http://feedback.comcast.et/ Neolae v6.0 - Esurig emailig platform deliverability - Domai-specific coditios 27
Neolae Outblaze Write to the followig address to request a feedback loop: postmaster@outblaze.com. You must commuicate the followig iformatio: The IP list or rage i questio. The sedig domai used. The pricipal cotact (full ame, email ad telephoe). The feedback loop email accout. Usa.et The followig form eables you to request a feedback loop: http://fbl.usa.et/. Excite The followig form eables you to request a feedback loop: http://feedback.bluetie.com. Mailtrust The followig form eables you to request a feedback loop: http://fbl.mailtrust.com. Uited Olie (NetZero, Juo) The followig form eables you to request a feedback loop: http://www.uitedolie.et/postmaster/whitelisted.html. Whitelistig requests ca be made through the followig page: http://www.uitedolie.et/postmaster/whitelisted.html. Importat: The whilelistig form works with the feedback loop request. RoadRuer The followig form eables you to request a feedback loop: http://feedback.postmaster.rr.com. EarthLik Write to the followig address to request a feedback loop: fblrequest@abuse.earthlik.et. You must commuicate the followig iformatio: The IP list or rage i questio. The sedig domai used. The pricipal cotact (full ame, email ad telephoe). The feedback loop email accout. 28 Neolae 2013
Domai-specific coditios Cox The followig form eables you to request a feedback loop: http://fbl.cox.et. Bluetie The followig form eables you to request a feedback loop: http://feedback.bluetie.com. Neolae v6.0 - Esurig emailig platform deliverability - Domai-specific coditios 29
Neolae 30 Neolae v6.0 - Esurig emailig platform deliverability
CHAPTER 5 Blacklistig databases Table of Cotets Objet.............................. 31 Spamcop............................. 31 Spamhaus............................ 32 RFC Igorat........................... 32 SORBS.............................. 32 No-more-fu............................ 32 URIBL.............................. 32 ix Maitu............................. 32 Objet Several orgaizatios maitai databases of IP addresses ad domais that are reputed to be used by spammers. Cosultig these sites ca be useful to uderstad why certai messages were rejected as spam. It is geerally possible to request the removal of a address erroeously added to these lists. These databases are called RBLs (Real-time Blackhole Lists) ad they are cosulted via a DNS mechaism. There are three types of RBLs: By IP address: lists IP addresses sedig spam or likely to be relayig spam By seder domai: lists seder domais (full domai of the bouce mail address) sedig spam or icorrectly cofigured By web domai: lists the domais (high-level domais as registered with the registrars) foud i the URLs of the liks ad images cotaied i spam cotet. I Neolae, the domai to be take ito cosideratio is geerally the address used for trackig. The followig is a list of the most widely used RBLs. For a more comprehesive list, you ca refer to http://www.declude.com/articles.asp?id=97 or http://www.dsstuff.com/ ("IP Tools" sectio, "Spam Database Lookup" form). Spamcop Refer to http://www.spamcop.et/ Oe of the best kow databases. If you are o this list, it is geerally a bad sig. Neolae v6.0 - Esurig emailig platform deliverability - Blacklistig databases 31
Neolae Spamhaus Refer to http://www.spamhaus.org/ Oe of the best kow databases. If you are o this list, it is geerally a bad sig. RFC Igorat Specialized i the compliace with the RFC recommedatios, this site does ot measure reputatio but rather the techical compliace of a domai. SORBS http://www.l.sorbs.et compiles a list of IP addresses that are reputed to be dyamic IP address (i.e. attributed temporarily to ISP subscribers) or "ope relay" addresses. Certai domais check whether the IP address of a seder is ot listed o this site before acceptig email. Checkig the IP addresses o this site ca prove useful. No-more-fu Refer to http://moested.dk/spam/o-more-fu/ Lists the IPs assiged dyamically by the major ISPs to the geeral public. Newly used IPs are frequetly listed here. Removal is simple ad quick. URIBL Refer to http://www.uribl.com/ This list cotais the domais foud i the URLs withi spams. We will therefore test the domai used for the trackig liks agaist this database. ix Maitu This is a list of IPs ad is widely used i Germay. See http://www.heise.de/ix/ixspam/ 32 Neolae 2013
CHAPTER 6 The Deliverability module Table of Cotets Objet.............................. 33 Techical moitorig......................... 33 Ibox moitorig.......................... 34 Ibox rederig........................... 34 Objet Neolae offers tools to track the deliverability peformace of your platform. These fuctios are part of a dedicated optio, the Deliverability module. Whe this module is cofigured for your Neolae platform, you have access to the followig iformatio: Techical trackig report for day to day deliverability performace (techical moitorig) ISP ibox rederig report, Oveview of message quality (ibox, spam), Techical moitorig The techical moitorig report is available via the Deliveries>Deliverability>Techical moitorig lik i the Neolae home page. It icludes a umber of deliverability quality idicators for your platform (the idicators are updated daily at 9 AM). Neolae v6.0 - Esurig emailig platform deliverability - The Deliverability module 33
Neolae I additio, you are able to receive a daily report by email at a specified address. Please let us kow the requested email address by email. Some techical terms: IP ad RBL domai (Realtime Blackhole List): List of IP addresses of pollutig domais. These lists are maitaied by dedicated orgaizatios (such as SpamHaus, Spamcop...). Neolae curretly processes these lists. These RBLs reflect your reputatio ad ca be queried by the ISPs before acceptig to receive your emails. SPF (Seder Policy Framework): Mechaism eablig you to check whether the email seder is authorized o the sedig domai. SNDS(Smart Network Data Services): A Widows Live Hotmail ati-spam service. (https://postmaster.live.com/sds/faq.aspx) DomaiKeys: service developed by Yahoo ad iteded to certify the idetity of a email seder. Reverse DNS: Neolae checks whether a reverse DNS is give for a IP address ad that this correctly poits back to the IP. SederScore: Database of reputed servers (https://www.sederscore.org/) Ibox moitorig This report is available from the Deliveries>Deliverability>Ibox moitorig sectio of the Neolae home page. It gives a overview of the quality of emails set over a give period of time. A bechmark compariso is also made with the other platforms that have subscribed to the deliverability service. Ibox rederig This report is available for each delivery, i the the Email rederig tab. Note: The umber of rederig reports is limited mothly accordig to your licese agreemet. The couter is reset every 25th day of the moth. 34 Neolae 2013
The Deliverability module Neolae has implemeted a dedicated workflow (Update seed etwork for Ibox Rederig) to eable you to recover the target addresses to use for your proof emails. This workflow is located i the Admiistratio>Productio>Techical workflows ode of the Neolae tree. This workflow creates ad updates the addresses used i the seed etwork. It rus daily at 5 AM. To force it to ru straightway, right click o the scheduler ad select Execute pedig task(s) ow. The cotacts are iserted i a folder amed Ibox Rederig recipiets ad assiged to a group Ibox Rederig recipiets to eable rapid targetig. Simply add this group i your delivery actios to eable the Neolae capture process. The rederig thumbails ca be accessed i the Ibox rederig tab of the delivery a few miutes after sedig the emails. Note: Each sedig is couted off agaist your umber of authorized rederig reports. Use the Update rederig butto to update the list. Neolae v6.0 - Esurig emailig platform deliverability - The Deliverability module 35
Neolae Example of a rederig report: Note: If you have defied specific access rights for your operators, they require read rights for the "Ibox rederig recipiets" ad the associated group. This mode implies usig the msrecipiet table. If ot, you you have to iclude the target addresses i your cotact table. If you use persoalizatio elemets i your emails, the "source" profiles must be specified as a cosequece. 36 Neolae 2013
CHAPTER 7 SpamAssassi Table of Cotets Presetatio............................ 37 Istallatio............................ 39 Presetatio Neolae ca be cofigured to work with SpamAssassi. This makes it possible to score emails to determie whether a message rus the risk of beig cosidered as spam by the ati-spam tools used upo receipt. Before startig a delivery, the Preview tab eables you to evaluate the risks. A warig message give the result of the test as i the followig example: Neolae v6.0 - Esurig emailig platform deliverability - SpamAssassi 37