Postfix provides the ability to apply filters during the SMTP session. When an email arrives at your mail server the following steps are usually run through:
- CLIENT: Incoming TCP connection on port 25
-
HELO
The sending mail server tells you its name. -
MAIL FROM
The sender's name and email address of the email -
RCPT TO
The recipient the mail is intended for -
DATA
In this phase of the SMTP session the actual email is transmitted -
QUIT
End of SMTP session
With the appropriate settings of SMTPd restrictions you can control what checks Postfix will run when an email is received. Those restrictions are defined in the /etc/postfix/main.cf configuration file and are called smtpd_..._restrictions. You can for example restrict certain IP addresses to even open an SMTP (TCP/25) connection to your mail server during the "client" phase. Or you can filter what recipients are allowed during the "rcpt to" phase. According to the above list of phases these restrictions apply:
- smtpd_client_restrictions (default: empty)
- smtpd_helo_restrictions (default: empty)
- smtpd_sender_restrictions (default: empty)
- smtpd_recipient_restrictions (default: permit_mynetworks, reject_unauth_destination)
- smtpd_data_restrictions (default: empty)
So by default Postfix only applies checks during the "RCPT TO" phase to check if the email is either coming from your local network (the sending server's IP address is part of the "mynetworks" setting) or if the recipient has a valid account on your mail server. Otherwise the email would get rejected. It is important that you understand that the restrictions are checked in the respective phase. So it's pointless to apply checks on the sender's email address (MAIL FROM) in the HELO phase because that information is not yet known at that phase. Many mail server administrators just put all the checks into the smtpd_recipient_restrictions. The following sections give you some advice on how to configure your restrictions properly.
Realtime blacklists (RBL)
The most important technique nowaways to fight spammers are IP blacklists. There exist dozens of these lists that you can use freely. The operators of such lists have different policies regarding who is getting blacklisted. But most of them have spam probes on the internet that spammers fall for. The technique of spam traps means that otherwise unused email addresses are put on a web site in a hidden place or use them on mailing lists. Spammers then automatically spider (=scan) the internet for email addresses and then send their spam to the found addresses. If such a trap account gets email then that information is used by the operators of an IP blacklist to build a list of server that send spam. It is potentially dangerous to use IP blacklists though because you might block email from a legit server if that server was inadvertently blacklisted. My favorite blacklist "SORBS" for example has let me down several times by blacklistting entire internet providers for a period of hours or even days. So it's a good idea to check their policies and see if you agree with it. In the end the risk is yours. Once you reject an email you cannot get it back. But I still strongly recommend you use blacklists or you will literaly drown in spam.
IP blacklists are specified by a domain name like "bl.spamcop.net". To check if a certain IP address is listed in that zone you need to check if an entry for the reversed IP address exists in that zone. Assume that a mail server with the IP address 217.217.34.231 wants to send you an email. If you told Postfix to use the "bl.spamcop.net" blacklist then Postfix will reverse this IP address and check the DNS entry of 231.34.217.217.bl.spamcop.net. I just did that and got a result:
$> host 231.34.217.217.bl.spamcop.net
231.34.217.217.bl.spamcop.net has address 127.0.0.2
The fact that a result (127.0.0.2) was found means that the IP is blacklisted and that I should not accept emails from it. Postfix will then tell the sender that it triggered a blacklist and cancels the connection. The result returned almost always is 127.0.0.x where the X stands for the reason of the blacklisting. You will have to read the policy of the respective blacklist to see the reason. Let's take another IP address that is not blacklisted - for example 85.214.93.191:
$> host 191.93.214.85.bl.spamcop.net
Host 191.93.214.85.bl.spamcop.net not found: 3(NXDOMAIN)
I did not get a result. So the IP is not blacklisted and I should accept email from it.
There are a few major blacklists that you should check out:
-
SORBS (dnsbl.sorbs.net)
SORBS is very efficient but every few months tends to blacklist even large ISPs accidentally. I currently do not use it as I had too many user complaints. -
SpamCop (bl.spamcop.net)
Pretty reliable. On a sample day it blocked 29 mails on my server. -
SpamHaus (zen.spamhaus.org)
Also pretty reliable. On a sample day it blocked 147 mails on my server. -
UCEprotect (dnsbl-1.uceprotect.net)
Careful - the Class-2 and Class-3 lists are too strict and block even legit senders. On a sample day it blocked 33 mails on my server.
If you used these blacklists then the restrictions in your /etc/postfix/main.cf would be these:
smtpd_recipient_restrictions =
permit_mynetworks
reject_rbl_client dnsbl.sorbs.net
reject_rbl_client bl.spamcop.net
reject_rbl_client zen.spamhaus.org
reject_rbl_client dnsbl-1.uceprotect.net
reject_unauth_destination
(Note: You can also list the restrictions all in one line and seperated by commas. But I prefer the way to use multiple lines and indent the subsequent lines. It makes the main.cf file more readable.)
With these restrictions in place Postfix will run each of these checks after the "RCP TO" phase during the SMTP dialog.
- Is the sending IP address in your network range?
- Is it blacklisted by SORBS?
- Is it blacklisted by SpamHaus?
- Is it blacklisted by UCEprotect?
- Is your mail server responsible for the recipient's domain? Or is the sender using SMTP authentication for relaying?
Further restrictions to consider
Postfix offers quite a lot of checks you can use in your smtpd_…_restrictions. Just to name a few that I use on my mail servers:
-
reject_unknown_client_hostname
Runs a two-way DNS check of the IP address and hostname of the sending server. This can be potentially dangerous and reject legit email from misconfigured mail servers but nowadays every decent mail server is supposed to take care of their DNS settings. -
reject_unknown_sender_domain
Checks if the domain used in the sender's email address actually exists. This runs a check for an MX and A record of the sending domain. -
reject_unauth_pipelining
Some spam bots just try to deliver emails as fast as possible. But formally the sending server must wait for the recipient server's response in each SMTP step. If the recipient server allows pipelining then fast sending is allowed. This setting drops the connection if pipelining is attempted before it was offered by the destination server.
Further settings can be found in the Postfix documentation.
Are you blacklisted?
Of course you want to send out emails through your mail server. So you need to make sure that your server IP address is not blacklisted either. I suggest you check your server's IP address through one of the blacklist test services:
(These services also give you an idea what other blacklists are available.)
If you are listed on any of these lists then you will want to get off the lists. How you do that depends on each blacklist's policy. Some don't even support manual removal from these lists. If your ISP assigned you a dynamic IP address then you are in a so called "dialup IP range" and are most likely blacklisted and it's pointless to get off the list - read here for a solution. A lot of spam is coming from dynamic IP addresses. Either spammers send email from their ISP account. Or the large amount of virus-infested Windows PCs in the world is forwarding spam. So dynamic IP addresses are frowned upon by mail server administrators.
Source spoof prevention
The above section on IP blacklists helped you fight spam by rejecting it. Now let's add another security measure to prevent source address spoofing. Spoofing means that someone fakes information. And the source address is the email address that appears to be the sender of an email. So it means that somebody pretends to be someone else by faking the email address of the sender. Maybe you haven't given it much thought but basically everyone can send an email and pretend to be someone else. Perhaps you are even using multiple sender addresses yourself. What prevents someone from pretending he is you? There are two common options:
- SPF (Sender Policy Framework): Using SPF anyone can find out if an email was sent from an IP address (=mail server) that is allowed to act as a mail server for that sender domain. Technically with SPF you create a DNS entry for your domain and list the valid IP addresses there that are allowed to send email on your domain's behalf.
- DKIM (DomainKeys Identified Mail): DKIM uses a private/public key pair to sign all outgoing emails automatically. By making your domain's public key available through DNS every mail server on the internet can check if the signature is valid for your domain and nobody spoofed the email. Although SPF is more widespread than DKIM it has a major design flaw because it fails when you forward email (as the sending IP address changes and may not be a valid address listed in the SPF entry any more).
Setting your own SPF entry
The content of the SPF entry follows a certain syntax. To make things easy you can use the service at OpenSPF to set up your SPF entry. Enter your domain name there and fill out the fields. The web site will tell you how your SPF entry will have to look like. Add this to your DNS zone and you will both help others to fight spam as well as help yourself to prevent that anyone is sending unwanted emails on your behalf. Formerly a TXT resource record in the DNS zone was used but nowadays there is a distict SPF record type used for that purpose.
Checking other SPF entries
Many domains already have SPF entries. So you are encouraged to use that information for your own spam and phishing protection. Read the next section on greylisting to learn how to use the "tumgreyspf" service to use both the power of SPF and greylisting.
Forwarding breaks SPF
SPF has a major design flaw. It fails if someone forwards email to another server. Then the forwarding server is not listed in the SPF entry and the destination mail server will (correctly) reject the email. Less technically-savy users will not understand this limitation. So many mail administrators just take the SPF checks into account when looking for spam but they don't ultimately reject the email. It's up to you. SPF reliably fights spoofing and phishing for major domains like PayPal, eBay, Amazon or other large organisations that are often a target of phishers. In some cases it will just be overly careful.
Checking DKIM signatures of incoming email
DKIM was invented for a similar reason as SPF. It provides email authentication - to allow a receiving mail server to check that the email is authentic for a given sender domain. SPF just tells which IP are allowed to send email for a sender domain. But DKIM is working way more reliably because it adds a cryptographic signature to every outgoing email. To verify if an email is authentic a mail server can use the email's signature and match it with the sender domain's public key that can be obtained by DNS. Sounds too complicated? Actually it's pretty simple if you understand the basics of public-key cryptography. Have you ever used PGP? Then you know that you had to create a keypair consisting of a private key you can use to sign emails and a public key that you can give others to encrypt emails for you or check your signatures. DKIM uses exactly that technique. The sending mail server has a keypair for each domain. When it sends out an email it will use the private key for the sender domain, take the email that is to be sent out and sign it with a cryptographic signature. That signature is added to the email (as an additional mail header) and the receiving mail server can take the email and the signature from the mail header and the public key of the sender domain to determine whether the signature was valid.
Adding automatic verification of other domains' DKIM signatures is pretty easy. Just install the DKIM filter software:
apt-get install dkim-filter
Actually this software is called a "milter". Milters are "mail filters" that were introduced as additional pieces of software for the ancient Sendmail mail server software. Milters speak a certain protocol that mail server can use to communicate with it and Postfix fortunately knows how to use milters, too. Right after the installation the "dkim-filter" process is already started and running in the background. But as Postfix is running in a chroot jail in /var/spool/postfix it cannot use the DKIM filter's communication socket at its default location in /var/run/dkim-filter/dkim-filter.sock. You can fix the permissions and make DKIM run a socket in /var/spool/postfix instead but I prefer to rather run dkim-filter as a TCP service rather than a socket. Edit your /etc/default/dkim-filter file that contains its default settings and add
SOCKET="inet:54321@localhost"
to it. Restart the dkim-filter process:
/etc/init.d/dkim-filter restart
Now dkim-filter is listening to TCP port 54321 on the localhost interface. To make Postfix use this milter run these commands to add the appropriate milter definitions to your /etc/postfix/main.cf file:
postconf -e smtpd_milters=inet:127.0.0.1:54321
postconf -e non_smtpd_milters=inet:127.0.0.1:54321
Now Postfix will run all emails (both incoming and outgoing) through your DKIM filter and check DKIM signatures (if found) on incoming emails. It will not sign outgoing emails though - this is covered in the next section.
A side note: you can decide what should happen if there is a problem with the DKIM filter. By default Postfix will temporarily reject emails until you fixed the issue. It's up to you. But I prefer to just accept emails if there is a milter problem. So I set:
postconf -e milter_default_action=accept
For more information on milters please consult the Postfix documentation on milters.
Setting up DKIM for sending emails
The actual idea of DKIM is to make a domain's mail server sign outgoing emails automatically. To do that you need to create a cryptographic keypair first. Fortunately you do not have to buy a certificate because publishing the key in your DNS zone is enough. The tool you need is "dkim-genkey" and it requires the bit-length of the key and the domain name. You can optionally use a selector to use multiple keys. By default the selector is called "default". I suggest you use the domain name as your selector which will name your key files correctly automatically.
It's best to create a seperate directory to store the keys. I keep mine in /etc/postfix/dkim:
mkdir /etc/postfix/dkim
cd /etc/postfix/dkim
Then create the keypair there:
dkim-genkey -b 1024 -d example.org -s example.org
In your current directory you will now find two files.
- "example.org.private" is the private key that the DKIM milter will use to sign all outgoing emails
- "example.org.txt" is the public key that you are supposed to add to your domain's DNS zone
The configuration file for the DKIM milter is /etc/dkim-filter.conf. Edit that file. The only change you need is to add a line for the key list file like:
KeyList /etc/dkim-keys.conf
Create a new file /etc/dkim-keys.conf that you just pointed to. Its contents define which key is used for which sender address. Or to be specific the syntax is:
sender-pattern:signing-domain:keypath
as pointed out in the "man dkim-filter.conf" man page. So if your domain were example.org you would write:
*@example.org:example.org:/etc/postfix/dkim/example.org
Add one line per (sender) domain that you wish to sign outgoing emails for.
Caveat: dkim-filter adds ".private" to the keypath you specify. So the above line is correct. Do not specify /etc/postfix/dkim/example.org.private or signing will fail.
Restart your DKIM milter:
/etc/init.d/dkim-filter restart
Now outgoing emails should get a DKIM signature automatically. Send an email to another mail server and check the headers of the email. You should see a header like this:
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=example.org; s=example.org t=1307571770; bh=OtZOIOSkkhL1t+kR5KOE6HvvjUjLkDE+70agcKmcjJg=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=RlxE9IRiOJrOzM4JbJFIp/YmK4XBRJFti79rL0vzGkppAC1AJi2CdtwGFT/sTovt/iKikrdyQ7M7JhdlC9u3bh8rrvhLA53HZCmu6WvHvv059ysdpjUhrktEqZFrFpgds2wqCkzF4ar/ly3TzYZmoZJO+C8j2uU5L3cKzESfGw4=
The meaning of each parameter can be found on the Wikipedia page. or in the less human-friendly format definition in the RFC 4871.
However the recipient cannot tell if this is a correct signature because they don't have the public key to verify this signature with. Edit your DNS zone for your domain and just add the TXT record that "dkim-genkey" created for you in /etc/postfix/dkim/example.org.txt. On my test server it looked like this:
example.org._domainkey IN TXT "v=DKIM1; g=*; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDKPFhCADCGcxDchGHFqvSoQYuW0epBT0gJuCwDMkX0uPejeeMdBNDcaGo8AyZdXJTFKqGK5kao2OvpDsH6XeKMBjPt/CnyBm4PNwlwNrkJTBc15xjD6Swmlk457+Ioz/tbpBA3b3RnC8NsqiknLQ3JxDkE7fXfji7Uds5+swWwJQIDAQAB" ; ----- DKIM example.org for example.org
Verify that your DNS zone for your domain really contains the right entry by querying for a TXT record with your domain name and the selector you used:
dig +short example.org._domainkey.example.org txt
And it should return your public key:
"v=DKIM1\; g=*\; k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDKPFhCADCGcxDchGHFqvSoQYuW0epBT0gJuCwDMkX0uPejeeMdBNDcaGo8AyZdXJTFKqGK5kao2OvpDsH6XeKMBjPt/CnyBm4PNwlwNrkJTBc15xjD6Swmlk457+Ioz/tbpBA3b3RnC8NsqiknLQ3JxDkE7fXfji7Uds5+swWwJQIDAQAB"
Now all outgoing emails for …@example.org will get a DKIM signature added automatically and recipients can verify them. Any mail server relying on DKIM signature checks can now check whether emails from your domain are legit.
I assume that you have set up the DKIM milter in Postfix as described in the previous section. Setting "smtpd_milters" and "non_smtpd_milters" in your /etc/postfix/main.cf will now do both the verification of DKIM signatures as well as the signing.
Greylisting
Another way to help you reduce the amount of spam you receive is using greylisting. Whitelisting means that a certain kind of email is always accepted (delivery status 2.x.x). Blacklisting is the opposite and always blocks certain emails (delivery status 5.x.x). Greylisting is something in between and temporarily refuses to accept the email for a couple of minutes. The idea is to tell virus infested computers trying to spam you from actual mail servers. Viruses (or rather: spam worms) just try to deliver a spam email once. But real mail servers have a queue of outgoing emails and upon a temporary error they will try to re-deliver the email. If the sending mail server has never sent us an email then greylisting will send back a temporary error code (delivery status 4.x.x) which signals the sending server to try delivering the email again in a few minutes. Your server will take a note of the IP address of the sending server and after a set period (a common value is 10 minutes) the blockade is lifted and upon the next delivery attempt the email will be accepted. Also the greylisting service will take a note in its cache and further delivery attempts will be allowed instantly.
The obvious drawback is that emails are often delayed by several minutes - especially if you just start using greylisting and the cache of trusted sending servers is empty. It is your decision whether your users will accept that. In my personal experience greylisting is not as effective nowadays as it has been in the beginning. It appears like malware now just tries to deliver spam emails several times. But it's one measure to maybe block some spam emails.
There are several ways to implement greylisting. The way I do it is using the "tumgreyspf" software. Start by installing it:
apt-get install tumgreyspf
To make Postfix use tumgreyspf you have to define a service for it in the /etc/postfix/master.cf:
tumgreyspf unix - n n - - spawn
user=tumgreyspf argv=/usr/bin/tumgreyspf
You also need to add it to your smtpd_recipient_restrictions of your /etc/postfix/main.cf file. Example:
smtpd_recipient_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_rbl_client bl.spamcop.net
check_policy_service unix:private/tumgreyspf
reject_unauth_destination
These are example restrictions. Do not just copy/paste it. The example is just meant to show you a good place to add the policy check in your smtpd_recipient_restrictions.
Finally restart Postfix:
postfix reload
To customize the behavior of tumgreyspf you can alter the files in /etc/tumgreyspf.
(This procedure is also documented in the /usr/share/doc/tumgreyspf/README.Debian file.)
Final relay test
Do you remember what I said earlier about relaying? You must not become an open relay or else you would be considered a supporter of spammers and be blacklisted. There is a pretty simple way to run a couple of checks. Log into your mail server and run:
telnet relay-test.mail-abuse.org
Wait a few seconds. The remote service will connect back to your server and run a few sanity checks. If after running through all the check you see
System appeared to reject relay attempts
Connection closed by foreign host.
then you configured your mail server safely. Well done.
65 Comments
Editing DNS
Submitted by Anonymous (not verified) on
"Edit your DNS zone for your domain and just add the TXT record that "dkim-genkey" created for you"
Are you saying edit the DNS server Zone record itself?
For example, my DNS MX records are held on the registrars DNS servers (I don't have my own yet), and therefore, I have limited editing rights on those servers. Am I understanding this correctly please?
Yes, you will need to add
Submitted by Christoph Haas on
Yes, you will need to add that TXT record to the DNS zone. Speak to your ISP if you can add such a record. Or take this as a reason to run the DNS service yourself. :)
Thank you Christoph.
Submitted by Anonymous (not verified) on
I've sort of touched on these kind of problems before and have always been inhibited by not having full control over the DNS records.
If I'm honest, I've shied away from creating my own DNS server - a bit scared I suppose of messing things up. But I have done a lot of reading and research in the past and I think you're right. It's time to bite the bullet and create my own DNS server and stop all this nonsense of others having control.
One further question if I may. My understanding from what you've written in your tutorial, is the generated key is tied to the domain for which it is created. Presumably then, if you're running multiple domains from a single server, each domain will not only have it's own DNS record, but it's own key as well. Is that correct please?
Thanks once again for you taking the time to reply to me. It's most appreciated.
You're welcome. :) One
Submitted by Christoph Haas on
You're welcome. :)
Yes, that's correct. When a mail server received a DKIM-signed email it will query the respective resource record from your DNS zone. So you need to create one keypair for each domain (subdomains are a special case) and configure it in your DKIM milter as well as add it to each domain's DNS zone. It does not matter whether the domains are run from the same server or from different servers.
Do you really have to create
Submitted by Anonymous (not verified) on
Do you really have to create separate key pairs? It is understood that the dns records of each domain involved must contain a valid key, but couldn't you just use the same key for all records? Or is the domain name somewhere encoded in the key data itself?
I haven't done that yet. For
Submitted by Christoph Haas on
I haven't done that yet. For security reasons and the sake of moving domains across servers it's probably still better to create seperate key pairs. But it's worth a try.
An example of zone (and tips)
Submitted by Anonymous (not verified) on
After dkim-filter is installed, as Chris said, you need to add the key to your bind zone.
After that, your domain zone looks like:
---
$ORIGIN .
$TTL 3600 ; 1 hour
domain.org IN SOA dns.domain.org. domain.domain.org. (
2005050207 ; serial
86400 ; refresh (1 day)
1800 ; retry (30 minutes)
604800 ; expire (7 days)
3600 ; minimum (1 hour)
)
$TTL 86400 ; 1 day
NS dns.domain.org.
NS dns2.domain.org.
A 89.12.211.2
MX 10 mail.domain.org.
domain.org._domainkey.domain.org. IN TXT "v=DKIM1; g=*; k=rsa; p=MIGfMA0GCSqGSIb3fdjkf04GNADCBiQKBgQCzeXk/125Saow+z1X3jL0X4EqA1fdjkjdlfdfjdlfkjdlfjdlfjdfkjdlYfhdhfdl8AmfdfjdlfjdljjfdlJJrT2lMNf2pAGOleqyO6AzlOZ9fdjlfdjlfdkjfdljfdkjdòlmsòdksòDEspWewIDAQAB" ; ----- DKIM domain.org for domain.org
$ORIGIN domain.org.
@ IN TXT "v=spf1 a mx ip4:89.12.211.2 mx:mail.domain.org -all"
dns A 89.12.211.2
dns2 A 89.12.211.4
ftp A 89.12.211.2
mail A 89.12.211.2
www A 89.12.211.2
---
tips:
Please take a look at the beginnig of the line that contain the key.
As you can see, after domain.org._domainkey I 've added .domain.org. (the original TLD name with final dot). This is because, if you don't add this, dig command fails or better, it returns empty. It obviously depends from zone configuration, but I suggest to add it.
Sir/Mam?
Submitted by Anonymous (not verified) on
That is such a valuable post for me, as today I decided to create my own DNS server. Hopefully over the weekend, I'll get one up and running.
I can see me referring back to this over and over again. So thank you for taking the time to explain to me.
I notice in the last block, you have written:
@ IN TXT "v=spf1 a mx ip4:89.12.211.2 mx:mail.domain.org -all"
Am I to assume the "v=spf1 a" is the "SPF" part of the record?
In other words, are you saying use both DKIM and SPF to fight spam, rather than, one or the other?
My worry is, that certain sites I host have contact forms, the content of which has to be forwarded to the clients email address of choice. Christop's tutorial suggests SPF will break forwarding (that's part of it's job after all). So I thought DKIM would be a better option. Or am I completely misunderstanding the concept?
DKIM and SPF do not directly
Submitted by Christoph Haas on
DKIM and SPF do not directly fight spam. SPF helps others determine which mail servers should be trusted for your domain. And DKIM helps others determine whether the email was legit for your domain. Both are merely measures to prevent spoofing and phishing and help you maintain your reputation. If you want to keep the incoming amount of spam low than using realtime-blacklists (RBL) is a more directly visible way to help you.
And, yes, SPF is problematic with email forwarding. If you are sure that forwarding will not happen - feel free to use SPF. If you host emails for a bunch of nerds who do - you know what - with their emails. Then better don't.
Thank's for that correction.
Submitted by Anonymous (not verified) on
Poor choice of language on my part :-(
On my mailserver, I use them
Submitted by Anonymous (not verified) on
On my mailserver, I use them both for years and have never had problems..
Success - sort of!
Submitted by Anonymous (not verified) on
To cut a very long story short, I now have a DNS master server operational and although I understand it's slightly off subject (though related), I'd appreciate any help anyone can offer on this.
The way my registrars offer the option to run your own DNS server, is for you to create a sub-domain using an ns prefix like this:
ns1.domain.com
This sub-domain automatically generates a glue record, that glues your ip address to that sub-domain. You then use the sub-domain to point to your own DNS server. The registrars also offer a secondary name server to back up your master server.
Subsequent testing during my learning process, revealed a difference in the information provided by my master server and the secondary; specifically, my master doesn't have the secondary configured in the zone files. There are two reasons for this; first I didn't know at the time this service was available and second (most importantly) I'm struggling to understand how I can set up the second name server in my zone files. Here's the reason.
The reverse lookup zone file uses the last octet of the domains ip address as an identifier - like this for example:
12 IN PTR ns1.domain.com
The problem is, my registrars secondary server is on a completely different subnet and therefore I can't understand how I would configure that within the reverse zone file. It's all very well when you have two name servers on the same subnet, but how do you cope with this please? Or do you simply not configure a reverse lookup for the secondary?
Any help would be great - thank you all.
DNS: your reverse zone is never used
Submitted by Anonymous (not verified) on
Let me clarify this.
Unless parent DNS reverse zone NS server delegate you a subnet of IP's (IANA/RIPE/...) which you own then your server will never be questioned for reverse zone records.
Assuming you have a VPS, or some server housing/... you will have there either in control panel from your serverHosting company ability to edit reverse record. If not send a support ticket.
As far as your own domain goes, you have configured previously that your domain name servers are that and this.... and therefore you delegated it.
Noone delegated subnet of 255ip's or 16ip's to you now did they?
Thank you very much.
Submitted by Anonymous (not verified) on
That's a great help - so reverse DNS isn't needed in this instance.
And no! Unfortunately, everything I do has to be routed through a single address. I don't have the luxury of a batch, which would make things a whole lot easier.
DKIM und SPF mit united-domains.de
Submitted by Anonymous (not verified) on
Ich habe united-domains als Domainhoster. Deren TXT-Record kann 255 Zeichen schlucken, was 2 Probleme hervorruft:
a) SPF + DKIM ist zu lang (>255)
b) DKIM schlägt fehl weil die _domainkey Policy nicht erstellt werden kann
Aber es gibt eine Lösung...
a) in der Domain (example.org) nur SPF Eintrag hinterlegen
b) Subdomain "example.org._domainkey.example.org" erstellen
c) in der Subdomain den DKIM Eintrag hinterlegen
Dann klappt auch endlich die DKIM-Verification - ich hab schon graue Haare deswegen bekommen.
MfG, Steffen Ille
dkim-filter test
Submitted by Anonymous (not verified) on
After all configuration / installation of dkim-filter, send an e-mail to gmail (or yahoo?) .
Login into your gmail account, open the email, and click on "show details"
You should see two new voices: (after 'Subject')
- from : (you should see your domain name)
- signed by: (you should see your domain name)
If yes, dkim-filter works fine.
If no, there is some problem.
That's all :-)
What also works is installing
Submitted by Christoph Haas on
What also works is installing the "libmail-dkim-perl" package which contains a "dkimproxy-verify" command. Just send the email anywhere and pipe it (especially the headers) into the dkimproxy-verify command. It will tell you if the signature is correct.
Maybe I should create a web service to help checking DKIM signatures. :)
SPF records
Submitted by Anonymous (not verified) on
So how should my SPF record look like if my mail server is sending mail from mail.example.org (which is 1.2.3.4) from user@example.org (when just example.org is also 1.2.3.4)? (I'm thinking about v=spf1 a mx -all). MX is mail.example.org. And should I add my SPF record to example.org or to mail.example.org?
The OpenSPF web page I
Submitted by Christoph Haas on
The OpenSPF web page I mentioned has a good tool to help create your SPF entry. In your case a "v=spf1 mx -all" will do. Althoush OpenSPF will probably recommend that you use "v=spf1 mx ~all" to make it a soft fail instead of a hard fail. But in my opinion if you set up SPF you should know what you are doing and then a soft fail does not make sense.
The SPF record is meant for the the mail domain. So if you use user@example.com then the domain is "example.com" and the zone for "example.com" needs the SPF or TXT entry.
Some useful tips: - SORBS
Submitted by Anonymous (not verified) on
Some useful tips:
- SORBS is currently blacklisting gmail, do not use it.
- You need TCP access to your DNS server for DKIM:
https://bugs.launchpad.net/ubuntu/+source/dkim-milter/+bug/387171
Otherwise you will get:
Jun 12 17:14:35 mail postfix/smtpd[24626]: connect from mail-wy0-f181.google.com[74.125.82.181]
Jun 12 17:14:42 mail dkim-filter[24654]: can't configure DKIM library; continuing
Jun 12 17:14:42 mail dkim-filter[24654]: Sendmail DKIM Filter v2.8.2 starting (args: -b v -x /etc/dkim-filter.conf -u dkim-filter -P /var/run/dkim-filter/dkim-filter.pid -p inet:54321@localhost)
Jun 12 17:14:43 mail postfix/smtpd[24626]: 57A3934B2: client=mail-wy0-f181.google.com[74.125.82.181]
Jun 12 17:14:43 mail postfix/cleanup[24666]: 57A3934B2: message-id=<4DF4D75E.3080706@gmail.com>
Jun 12 17:14:43 mail postfix/cleanup[24666]: warning: milter inet:127.0.0.1:54321: can't read SMFIC_EOH reply packet header: Success
Jun 12 17:14:43 mail postfix/cleanup[24666]: 57A3934B2: milter-reject: END-OF-MESSAGE from mail-wy0-f181.google.com[74.125.82.181]: 4.7.1 Service unavailable - try again later; from=<darkbasic4@gmail.com> to=<nospam> proto=ESMTP helo=<mail-wy0-f181.google.com>
Jun 12 17:14:43 mail postfix/smtpd[24626]: disconnect from mail-wy0-f181.google.com[74.125.82.181]
Problems with dkim-filter, just use opendkim
Submitted by Anonymous (not verified) on
Hi,
I had problems running dkim-filter. And those problems I couldn't solve.
Exemple errors I've got:
dkim-filter[14604]: can't configure DKIM library; continuing
postfix/smtpd[6166]:warning: milter inet:127.0.0.1:8891: can't read SMFIC_OPTNEG reply packet header: Connection timed out
and than the dkim-filter daemon just stops.Nowhere on the Internet I couldn't find solution and none was able to help me. Even somewhere these errors were listed as a bug in dkim-filter package and suggestion was to use newer version, but none of this helped me. So I jujst used another package called opendkim, to configure this milter.
I decided to share my expereience with anyone who has this exact same problem. Note that opendkim package is working perfectly with ISP mail tutorial as far as I've tested it.
First install opendkim...
apt-get install opendkim
...with all dependencies proposed.
Next you'll need to create new keypair
I did this using openssl like this...
#openssl genrsa -out private.key 1024
#openssl rsa -in private.key -out public.key -pubout -outform PEM
and than just copy private.key and public.key where you want them for example in /etc/postfix/dkim/
like in workaround tutorial suggested.
Next step: you'll need to configure /etc/opendkim.conf there you need to specify 3 lines:
Domain example.com
KeyFile [the path to your private.key]
Selector [mail] #you can use here any word of your choice, you will need that later to configure your DNS zone
Next you have to specify the SOCKET connection in /etc/default/opendkim
SOCKET="inet:54321:localhost"
and than just run the service
# /etc/init.d/opendkim start
Next step is to modify postfix's /etc/postfix/main.cf just add these lines if you haven't done so already.
milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:localhost:54321
non_smtpd_milters = inet:localhost:54321
OK last step is to configure your DNS zone. How to configure it is really up to you, but basically you need to add the following 2 new records:
Replace the instances of DOMAIN.TLD with your actual mail domain name in both records, SELECTOR was configured in to opendkim earlier, in my example I used mail.
Your key will be called public.key, we created both public and private keys earlier. You only need to add the actual key from between the BEGIN and END lines, e.g. my test one below
-----BEGIN PUBLIC KEY-----
MIGfMWGwregWREGREwgERGREGergerDGdEPzFCAdYnf1Z9nRtfTqwP/mcdGg
NmbY11tCtwwFMu8/qEQwaK/Nc61q0D/z7NYwlsPFi08lnVSHGrewherh5630n
F6S0z961h6li/pOHiJy/l2ehnenhehO3d/NmATY90WlpEDmnlVAMTYgALBFJplp
1ruZ66Bgrewhg43y634567gewrgB
-----END PUBLIC KEY-----
Becomes: MIGfMWGwregWREGREwgERGREGerg [...snip...] plp1ruZ66Bgrewhg43y634567gewrgB
Finally just reload the postfix
/etc/init.d/postfix reload
You can send test mails once your DNS changes have propagated. Search for any errors in /var/log/mail.log
Hope this helps. If you have trouble setting opendkim you can drop me a line at workaround's chit-chat mail list. I'll try to help you.
Cheers
Philip Krastev
some typos, sorry for that
Submitted by Anonymous (not verified) on
I noticed some typos I've made, in the previous post. Like for example: SOCKET connection I missed the [@], it should be:
SOCKET="inet:54321@localhost"
Hopefully you will figure this out. And if you can't here is a nice tutorial which explains basically the same:
http://syslog.tv/2010/01/11/dkim-on-debian-with-postfix/
Hope this helps.
Have a nice day!
P.
Fixing your dkim-filter issue - prob: wants to do DNS with TCP
Submitted by Anonymous (not verified) on
A standard firewall configuration can cause the "can't configure DKIM library; continuing" problem you describe with dkim-filter and prevent it from starting properly.
If you've got a firewall up that expects DNS queries to happen over UDP port 53, you need to also open TCP port 53 so dkim-filter can do its lookups via TCP. This seems like abberant behavior to me, but that's probably what's going on.
Fixed it for me and for others.
This alone didn't get me whole - had to make sure dkim-filter was actually running, now I've got "no signature data". Will hammer it through, though.
Good luck!
D
Opendkim is newer, I think you should update ispmail HOWTO
Submitted by Anonymous (not verified) on
I experienced dkim-filter weird internal errors like:
dkim-filter[12722]: B32F328677: dkim_eoh(): internal error from libdkim: ar_addquery() for `20120113._domainkey.gmail.com' failed
Maybe this could be caused because I use UDP which is the default configuration for dkim-filter, but I suggest anyway to update this wonderful HOWTO with opendkim which is a newer implementation.
If you want to upgrade from dkim-filter to opendkim, you have to convert your KeyFile. I append you this note from README.Debian.gz
Thanks for this wonderful guide
Luca
Changes to key specifications
-----------------------------
The KeyList functionality in versions of OpenDKIM prior to 2.0.0 has been
replaced with two features called SigningTable and KeyTable. More information
on these can be found in opendkim.conf(5). If you use these features, the
script /usr/share/doc/opendkim/contrib/convert_keylist.sh can be used to read a
KeyList file and create appropriate SigningTable and KeyTable files.
More detailed information about the new data sets (including LDAP and other
data set types) can be found in README.opendkim.
-- Mike Markley <mike@markley.org> Thu, 13 Aug 2009 19:20:34 -0700
he.net free dns
Submitted by Anonymous (not verified) on
This is how to setup dkim to anyone out there that happen to use he.net free dns (like me):
Sorry, I'm confused!
Submitted by Anonymous (not verified) on
I've been following this page steadily and have got to configuring dkim keys.
You've written:
“The configuration file for the DKIM milter is /etc/dkim-filter.conf. Edit that file. The only change you need is to add a line for the key list file like:
KeyList /etc/dkim-keys.conf”
So are you saying you point the file to itself?
You then go on to say:
“Next edit the file /etc/dkim-keys.conf you just pointed to. Its contents define which key is used for which sender address. Or to be specific the syntax is:
sender-pattern:signing-domain:keypath”
which could be for example:
“*@example.org:example.org:/etc/postfix/dkim/example.org”
But that is suggesting I'm now going to edit dkim-keys.conf and by inference, I've already edited something different,
Would you mind clarifying please?
Sorry again!
Submitted by Anonymous (not verified) on
I'm no longer confused.
That'll teach me to try and configure something at 2.00am in the morning!
If I'd read it properly in the first place, I wouldn't have posted the previous - sorry.
I think I'm going slightly mad!
Submitted by Anonymous (not verified) on
As far as I can see, /etc/dkim-keys.conf doesn't exist anywhere.
I've just done a search on Linux packages and it lists the files produced by the package, but doesn't mention that file at all. In fact the only three that are produced in /etc are:
So are you saying, create a new text file from scratch?
I know it's late and perhaps I'm being really stupid, but I can't understand this at all.
You have throroughly confused
Submitted by Christoph Haas on
You have throroughly confused yourself. :) Actually it's simple:
I'll make this clearer in the text.
Absolutely true Christoph.
Submitted by Anonymous (not verified) on
I did thoroughly confuse myself and in retrospect, when it was all getting out of hand, I should have walked away and looked at it again today.
I shall create the file now and all should be well with the world, and I can walk away from the sanatorium!
After my initial post, I did recognise the difference between the files, but then got even more confused when I couldn't find dkim-keys.conf.
Thank you for taking the time to reply.
tumgreyspf - smtpd_sender or smtpd_recipient restrictions?
Submitted by Anonymous (not verified) on
Hi,
first - thanks for a great guide.
Now my question: In your description of setting up greylisting, you put the tumgreyspf check into the smtpd_recipient_restrictions section of main.cf.
But you also refer to the README.Debian file, which has this check in the smtpd_sender_restrictions section.
Does it make any difference where it is ? I've had it in the sender_restrictions part for half a year, and greylisting appears to work just fine here (and it appears to be rather efficient).
Regards,
Henrik
Thanks for the feedback,
Submitted by Christoph Haas on
Thanks for the feedback, Henrik. Regarding the position of the tumgreyspf I'd like to refer to the first section of this page where I write:
SPF checks need the client IP address and the sender name. In the SMTP dialog this information is available at the smtpd_sender_restrictions (MAIL FROM) stage. So you can put the SPF check in any restriction starting with smtpd_sender_restrictions - it can also be checked in later steps like smtpd_recipient_restrictions. The worst thing that happens if you do the SPF checks in smtpd_recipient_restrictions is that the SMTP dialog is cancelled one step later (RCPT TO insted of MAIL FROM) but unless you care about a few CPU cycles that doesn't really make a difference.
You could even put the check into smtpd_data_restrictions but in that case the entire spam email would get transferred and rejected afterwards. That would not be useful.
The official Postfix description
Submitted by Anonymous (not verified) on
Thanks for your reply.
I should have checked the Postfix docs, since there is a whole page dedicated to describing how the various checks work. http://www.postfix.org/SMTPD_ACCESS_README.html has all the gory details.
Henrik
dkm policy record
Submitted by Anonymous (not verified) on
You forgot the dkm policy record!
_domainkey IN TXT "t=n;o=-"
t=y means the domain is in test mode. When everything works it can be changed to "n"
o=~ means that some emails will be signed. "o=-" means that all domains are signed
Can anyone throw any light on this please?
Submitted by Anonymous (not verified) on
I've installed and configured dkim - successfully (I think), but when I run an email test to a dkim testing site, it says:
Fail. Email has no DKIM Signature headers. Make sure you have DKIM Signing turned on.
What does that mean please?
I did restart dkim and the dig +short command, returns the key, so I'm lost!
Certainly, when I check the source code of the email, the dkim section appears. But it seems something is still missing.
Where do you see this
Submitted by Anonymous (not verified) on
Where do you see this message:
"Fail. Email has no DKIM Signature headers. Make sure you have DKIM Signing turned on."
is this from your mail.log, or is it a returned message (Undelivered Mail Returned to Sender) from your mail server.
If it's the second I had a similar problem, with error 550:
550 Message does not pass DomainKeys requirements for domainIf this is the problem, and for anyone having the above returned mails. Let me share with you a quick solution. Just add "t=y" to your DNS record, like explaind in the previous post. This is to indicate that DKIM is in testing mode. Some servers out there are misconfigured badly about DKIM and if it's not in testing mode (e.g. "t=n"), they return the 550 error.
http://www.redline-software.com/eng/support/docs/mdaemon/c9s6.php
OK, so I had the 550 error from just a few domains. The others I had no problem with like Yahoo and Gmail. So this tells me that the server returning this error is misconfigured, since Gmail and Yahoo can verify my emails. Yahoo is now pending patent for DKIM technology and it is a good testing point. So if this is an important domain to deliver to. You might set your DNS records that DKIM is in testing mode: "t=y". And than contact the mail admins of the problematic domains to investigate further. Hope this helps to someone.
Though I'm not sure that this is your problem, please precise where do you see the error you are talking about, and check your mail.log and dkim logs for more information.
Further investigation,
Submitted by Anonymous (not verified) on
has revealed the dkim signature is no longer being attached to the email - which is strange.
When I configured the first part of this dkim tutorial and tested it, the signature was most definately attached.
Even now, the dig +short command, prints the public key to the screen. So the key exists and presumably is in the correct place.
Clearly then, I hadn't realised the signature had suddenly ceased to be attached, but I've no idea why!
See if dkim-filter is running
Submitted by Anonymous (not verified) on
Check that the filter is running.
ps ax |grep dkim
If it's not running start it, send one email and check again.
If it stopped after the first sent email, check out the previous comments on this page. There is a solution changing dkim-filter with opendkim which is better in my opinion.
Also check your logs, and investigate them first!
P.
Thanks.
Submitted by Anonymous (not verified) on
Thanks for your reply. I really do appreciate your input.
I have confirmed dkim is running. I need to investigate this further, but will probably not have any spare time until the weekend.
If all else fails, I'll certainly look at opendkim, but I would really like to establish why this has suddenly ceased to attach itself to the email, as I suspect, that even if I go to opendkim, I may well get the same result.
I had to create a DNS server to make this whole process work. This is an area that is completely new to me and I'm wondering if it's something to do with the DNS configuration.
The real puzzle for me is, the dig +short command renders the dkim public key. So I'm struggling to see where the breakdown is occurring.
I screwed up - partly.
Submitted by Anonymous (not verified) on
There was indeed a DNS configuration error and now I've fixed that, once again the dkim signature is attached to sent emails.
However, one of the email test sites I've used, returns this:
(I've removed the email addresses to avoid bot scans)
DKIM check details: ---------------------------------------------------------- Result: fail (wrong body hash: expected frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=) ID(s) verified: Canonicalized Headers: To:'20'<check-auth@verifier.port25.com>'0D''0A' Subject:'20'test'0D''0A' MIME-Version:'20'1.0'0D''0A' Content-Type:'20'text/plain;'20'charset=UTF-8'0D''0A' Content-Transfer-Encoding:'20'8bit'0D''0A' Date:'20'Mon,'20'04'20'Jul'20'2011'20'01:28:37'20'+0100'0D''0A' From:'20'<postmaster@*********.com>'0D''0A' Message-ID:'20'<3e3cbd6329d62a224e52aba79f4936bf@mail>'0D''0A' DKIM-Signature:'20'v=1;'20'a=rsa-sha256;'20'c=simple/simple;'20'd=*********.com;'0D''0A' '09's=*********.com;'20't=1309739317;'0D''0A' '09'bh=8IFT0WqUkNmUol1aNB/4rPxAXe3avQ0hNO+a+dRqzVQ=;'0D''0A' '09'h=To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:'0D''0A' '09''20'Date:From:Message-ID;'0D''0A' '09'b= Canonicalized Body: '0D''0A' DNS record(s): NOTE: DKIM checking has been performed based on the latest DKIM specs (RFC 4871 or draft-ietf-dkim-base-10) and verification may fail for older versions. If you are using Port25's PowerMTA, you need to use version 3.2r11 or later to get a compatible version of DKIM. ---------------------------------------------------------So my question is, what is "fail - wrong body hash" all about?
Or is it simply that Debian Squeeze has not caught up with the latest DKIM specs as noted at the bottom of the report?
Any pointers would be helpful - thanks.
Greyling a bad and annoying idea
Submitted by Anonymous (not verified) on
Hi,
your tutorial is just great and I love it since etch.
Still, I am wondering why you are proposing greylisting. Greylisting is annoying for sender and receiver specially if they are on the phone and send a mail while talking to show the other person a document. It is likely to happen, that the mail will get delayed for as long as your greylisting time is set. Additionally, I myself made the experience that even back in the time while your etch tutorial was the latest version that greylisting did not work very good any more. I had to push it up to 15 minutes because a lower value was not enough to prevent reconnecting SPAM bots.
I looked around and found policyd-weight, which immediately lowered the SPAM to about 4 per user per month. It includes scored multiple blacklist lookups and other helo, MX etc. tests. This way you will not have the problem, that you get no mail from google any more just because one blacklist provider puts its IP on the list.
Here is the simple installation howto to enable it. Do not forget to disable/remove all other blacklist rejections and the greylisting.
aptitude install policyd-weightCreate config
policyd-weight defaults > /etc/policyd-weight.conf
chmod 0644 /etc/policyd-weight.conf
Change settings:
# Reject if level is above
sed -i 's/\$REJECTLEVEL = [0-9]\+;/$REJECTLEVEL = 2;/' /etc/policyd-weight.conf
# Reject immediately if on more than half of the lists
sed -i 's/\$MAXDNSBLHITS = [0-9]\+;/$MAXDNSBLHITS = 4;/' /etc/policyd-weight.conf
# Reject if score of IP is above 10
sed -i 's/\$MAXDNSBLSCORE = [0-9]\+;/$MAXDNSBLSCORE = 10;/' /etc/policyd-weight.conf
Please have a look into the configuration file. Even the defaults are already very good, you might want to change blacklists or scores.
Restart service:
service policyd-weight restart
Activate in postfix
smtpd_recipient_restrictions =
...
warn_if_reject check_policy_service inet:127.0.0.1:12525
If you are sure that everything works fine, remove the part
warn_if_reject.Regards,
Dagobert
What about DKIM if you purge
Submitted by Anonymous (not verified) on
What about DKIM if you purge tumgreyspf?
Sorry, I meant SPF instead of
Submitted by Anonymous (not verified) on
Sorry, I meant SPF instead of DKIM. What do you use to check SPF instead of tumgreyspf?
SPF not necessary
Submitted by Anonymous (not verified) on
Well, hournestly I have to say that I do not have too much experience with SPF besides the theory. I have never needed it. I have to say that, as it was stated in the tutorial of workaround, SPF and DKIM are not really the greatest things against SPAM. SPF has at least the forwarding problem and DKIM is no help if the attacers have taken care of that.
As the page of policy-weightd on their front page states (http://www.policyd-weight.org/)
Of course you should still have SpamAssassin and Clamav running (especially if you are responsible for a company's security and data). But these programs will have a lot less to do and thus decrease the need for bandwidth and CPU cycles. Also you might not need greylisting (which would make sense for users that receive a lot of new spam, though), SPF, extraordinary whitelists or SQL and other DBs anymore.
I can only say that it is true. Just give it a try, you will not get disappointed.
Greets
You can use postfix-spf
Submitted by Anonymous (not verified) on
as you can read here:
https://help.ubuntu.com/community/Postfix/SPF
Interesting..
Submitted by Anonymous (not verified) on
Great!
I'm looking for an alternative to postgrey (due to delay time too high)
What about gmail's user? Does it block their e-mail?
Thank you.
No complains
Submitted by Anonymous (not verified) on
Hi,
with my setup I never had any complains. I know also other admins using this nice tool. We are all very happy.
Perfect!
Submitted by Anonymous (not verified) on
Today I removed tumgreyspf and installed:
postfix-policyd-spf-perl (for checking SPF record - previously done by tumgreyspf)
and policyd-weight.
I will test in these days, but at the moment everything seems ok and the mails arrived after 2 sec. :-)
Thank you for your hint!
@Dagobert
Submitted by Anonymous (not verified) on
"Still, I am wondering why you are proposing greylisting. Greylisting is annoying for sender and receiver specially if they are on the phone and send a mail while talking to show the other person a document. It is likely to happen, that the mail will get delayed for as long as your greylisting time is set."
1st: email services are not real-time services, with or without greylisting
2nd:all server stored (marked) as positive can be treated without any delay in good implementations on greylisting. (like this one: http://www.policyd.org/)
just my 2 cents, Alois
Final relay test
Submitted by Anonymous (not verified) on
The adress seems not to work:
telnet relay-test.mail-abuse.org
Is there another way to test it?
THX
Pages