Home > World Of ICT > CNAME and MX record will effect email Problem

CNAME and MX record will effect email Problem


Benar sekali saudara saudara ada pepatah yang menyatakan bahwa Pengalaman adalah Guru yang paling berharga, baru-baru ini ada kejadian aneh terkait dengan transaksi pengiriman email dari domain unila ke ke domain salah satu kampus di eropa tepat nya kampus cvut dengan domain cvut.cz  Problem yang terjadi adalah pada saat rekan di rektorat berkirim email ke salah satu dosen yang sedang studi disana, ternyata email dikirimkan tidak sampai ke tujuan alias bounching, entah sejak kapan kejadian tersebut pastinya selaku tim pengelola tidak ingin kejadian terus berulang.

Proses troubleshoot pun dilakukan dimulai dengan melakukan traceroute dari arah benua eropa menuju ke domain unila dengan hasil baik-baik saja, kemudian lanjut dengan ujicoba pengecekan entry record resolv domain baik dari sisi penamaan maupun record PTR dan lagi lagi tidak ada masalah  semua MX record domain unila terbaca dengan baik diberbagai DNS server test lintas benua. Tambah penasaran kan, iseng-iseng saja coba  mengirimkan email ke rekan dosen di Bradford Inggris, cc ke Yahoo dan Gmail, pun tidak ada masalah , sukses diterima oleh mail server tujuan.

Finally saya coba query SMTP manual menuju ke MX domain feld.cvut.cz untuk melihat respons  dari mail server mereka, dengan hasil adalah sebagai berikut;

ns1# telnet max.feld.cvut.cz 25
Trying 147.32.192.36...
Connected to max.feld.cvut.cz.
Escape character is '^]'.
220 max.feld.cvut.cz ESMTP service ready
ehlo unila.ac.id
250-max.feld.cvut.cz
250-PIPELINING
250-SIZE 30000000
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
mail from:gigih@unila.ac.id
250 2.1.0 Ok
rcpt to:ulvanmel@fel.cvut.cz
450 4.1.8 <gigih@unila.ac.id>: Sender address rejected: Domain not found
421 4.4.2 max.feld.cvut.cz Erro

Tanpa disangka ternyata domain unila.ac.id tidak dikenali oleh mail server max.feld.cvut.cz  ditandai dengan adanya error log 450 4.1.8 ,  penelusuran tetap terus dilanjutkan dengan mencoba memanfaatkan online MX tool dari internet salah satu dengan layanan terpopuler adalah http://www.mxtoolbox.com/SuperTool.aspx?action=smtp%3amail.unila.ac.id, dengan aplikasi ini bisa mendeteksi apakah ada problem dengan MX server di tiap-tiap domain dengan melakukan cross check ke beberapa RBL server dunia, hasilnya pun baik-baik saja blok ip unila terbebas dari database RBL (Salah satunya mungkin juga karena kita sudah menggunakan Barracuda sebagai anti spam Filter), OK THAT’S IT pusing kepala harus bagaimana lagi, sempat kepikiran untuk menanyakan ke administrator Email kampus tersebut apa sih problem-nya sehingga kok cuma mereka saja yang mereject email dari unila padahal dengan server mail lain baik-baik saja, saya coba mengurungkan niat untuk bertanya dan melanjutkan mencari tahu apa yang sebenarnya terjadi.

Googling pun dilakukan , 5  Tab dibuka di Firefox tidak ada informasi berarti, tambah lagi 20 tab, hingga 50 tab kali yah. akhirnya ada secercah harapan dan menemukan link berikut

http://email-museum.com/2008/09/08/why-you-shouldnt-mix-cname-and-mx

You may recall our recent cautionary tale about DNS configuration. Adding a CNAME record to a domain can cause some mail servers to ignore the MX records. Instead, they simply follow the CNAME pointer and try to deliver the email there. In our example, they tried to deliver email to the Web server! , RFC 2821 defines how email should be delivered. Its specifications for what should happen only hint at this behavior. Sections 2.3.5, 3.6, and 5 really could be more clear on this:  A domain (or domain name) consists of one or more dot-separated components. These components (“labels” in  DNS terminology [22]) are restricted for SMTP purposes to consist of a sequence of letters, digits, and hyphens drawn from the ASCII character set

[1]. Domain names are used as names of hosts and of other entities in the domain name hierarchy. For example, a domain may refer to an alias (label of a CNAME RR) or the label of Mail eXchanger records to be used to deliver mail instead of representing a host name.

Only resolvable, fully qualified domain names (FQDNs) are permitted when domain names are used in SMTP. In other words, names that can be resolved to MX RRs or A RRs (as discussed in section 5) are permitted, as are CNAME RRs whose targets can be resolved, in turn, to MX or A RRs.

Once an SMTP client lexically identifies a domain to which mail will be delivered for processing (as described in sections 3.6 and 3.7), a DNS lookup MUST be performed to resolve the domain name [22]. The names are expected to be fully qualified domain names (FQDNs): mechanisms for inferring FQDNs from partial names or local aliases are outside of this specification and, due to a history of problems, are generally discouraged. The lookup first attempts to locate an MX record associated with the name. If a CNAME record is found instead, the resulting name is processed as if it were the initial name. The standard assumes you’re already familiar with RFC 1034, which defines how DNS records work. In section 3.6.2, it recommends not mixing  CNAME records with any other type of record: If a CNAME RR is present at a node, no other data should be present Even that is a little ambiguous — in the jargon of the IETF, “should” usually denotes a recommendation, as opposed to “must,” which denotes a mandate. Perhaps this would have been better reworded, “If a CNAME RR is present at a node, other data must not be present.”

Here’s what he probably should have done:

example.com.    A    1.2.3.4
http://www.example.com.    CNAME    example.com
mail.example.com.    A    1.2.3.5
example.com.    MX    mail.example.com.

In other words, define an IP address for example.com and create an alias for it, called www. This can be counterintuitive for those of us who like to  separate different server roles by machine name. Arguably, this may expose the Web server to additional load generated by spammers, because we’re now effectively advertising that the Web server is also a mail exchanger. However, in practice this isn’t a problem, for two reasons:  Spammers often try to connect using A records, even in the presence of MX records — so that load would already have been there. Our anonymous friend isn’t completely stupid — he’s already firewalled off the unused ports of all his externally facing servers.
===============================================

OK setelah dicross check memang pada saat pergantian mail system ke server baru, ada perubahan record domain dengan entry record sebagai berikut;

zimbra    IN    A            103.3.46.21
                   IN    MX 10  barracuda.unila.ac.id.

mail        IN    CNAME zimbra    
                  IN    MX 10  barracuda.unila.ac.id.

Nah tuh ketauan deh problemnya, ternyata dibeberapa mail server menerapkan metode Strong FQDN domain untuk menangkal email SPAM, jadi harus mapping reverse termasuk PTR,  harus memiliki address tidak cukup hanya dengan mendefinisikan record CNAME saja, GOT IT ketahuan deh masalah nya, buang record CNAME diganti langsung dengan IN A  ,  dicoba lagi kirim ke mail server max.feld.cvut.cz , akhirnya berhasil.

SMTP -> FROM SERVER:
220 max.feld.cvut.cz ESMTP service ready
SMTP -> FROM SERVER:
250-max.feld.cvut.cz
250-PIPELINING
250-SIZE 30000000
250-ETR
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM: gigih@unila.ac.id
SMTP -> FROM SERVER:
250 2.1.0 Ok
RCPT TO: ulvanmel@feld.cvut.cz
SMTP -> FROM SERVER:
250 2.1.5 Ok
Sending Mail Message Body...
SMTP -> FROM SERVER:
354 End data with .
SMTP -> FROM SERVER:
250 2.0.0 Ok: queued as E7AB619F32FB
Message completed successfully.

Jreng Jreng.. beres deh masalahnya, Sekali lagi jangan pernah melakukan entry zone domain dengan kombinasi CNAME dan MX saja,

  1. September 5, 2012 at 10:20 am

    Artikelnya menarik.

    Saya menjumpai permasalahan yang agak mirip.
    Adalah domain aku.com dengan web server di situs.aku.com dan email server ada di layanan Gmail. DNS server aku.com menggunakan layanan dari Godaddy.

    Seseorang dari user@teman.co.id apabila mengirim email ke user@aku.com, maka email server dari teman.co.id terkadang berhasil mengirim email ke user@aku.com di Gmail tetapi kadang gagal mengirim email karena email server teman.co.id berusaha mengirim email tersebut ke situs.aku.com yang tentu saja ditolak karena memang tidak ada layanan email di situs.aku.com.

    Mungkin bisa bantu memberikan pencerahan.

  1. September 30, 2011 at 2:27 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: