DIGITAL FORENSIC READINESS PADA EMAIL TRACE

HEADER UNTUK DETEKSI SPAM

Makalah Tugas Mata Kuliah

Operasi Keamanan dan Incident Response (EL6115)

Oleh
MUHAMAD TAUFIK YUSUF (23216056)

REKAYASA DAN MANAJEMEN KEAMANAN INFORMASI

SEKOLAH TEKNIK ELEKTRO DAN INFORMATIKA
INSTITUT TEKNOLOGI BANDUNG
2017
 ii

DAFTAR ISI

1. PENDAHULUAN ................................................................................................ 2
2. LANDASAN TEORI ........................................................................................... 3
2.1. Arsitektur Email ............................................................................................. 3
2.1.1. Komponen dan Protokol..................................................................................................... 3
2.1.2. Prinsip Kerja ...................................................................................................................... 3
2.1.3. Format Standard ................................................................................................................ 4
2.1.4. Header ................................................................................................................................ 6
2.2. Spam .............................................................................................................. 8
2.2.1. Tipe dan Jenis .................................................................................................................... 8
2.2.2. Teknik Spamming ............................................................................................................... 9
2.2.3. Anti Spam ......................................................................................................................... 10
2.3. Forensic Readiness ....................................................................................... 11
2.4. SMTP Trace Header ..................................................................................... 11
2.4.1. Simple Mail Transfer Protocol (SMTP) ........................................................................... 11
2.4.2. Email Spoofing ................................................................................................................. 12
2.4.3. Trace Header ................................................................................................................... 12

3. INVESTIGASI POLA SPAM PADA HEADER ............................................... 13

4. PENERAPAN FORENSIC READINESS.......................................................... 16
4.1. Modifikasi Trace Header .............................................................................. 16
4.2. Algoritma Deteksi......................................................................................... 17
5. KESIMPULAN .................................................................................................. 18
6. PENELITIAN LEBIH LANJUT ....................................................................... 19
7. REFERENSI ...................................................................................................... 19
 iii

DAFTAR GAMBAR

Gambar 1. Interaksi Protokol dan Komponen pada Sistem Email.................................. 3

Gambar 2. Proses Perpindahan Email ........................................................................... 4
Gambar 3. Format Email Sesuai RFC 5322 .................................................................. 5
Gambar 4. Pemakaian Envelope pada Format Email Baru ............................................ 6
Gambar 5. Header Lengkap pada Email ....................................................................... 8
Gambar 6. Received Rule dan Received-Token Rule.................................................... 13
Gambar 7. Fungsi Menampilkan Full Header pada Zimbra ......................................... 13
Gambar 8. Received-token dengan Penambahan Informasi Forensik Dijital ................ 16
Gambar 9. Received Rule Baru ................................................................................... 17

DAFTAR TABEL

Tabel 1. Kolom Header Email .................................................................................. 6

 1

Digital Forensic Readiness pada Email Trace Header

untuk Deteksi Spam

Muhamad Taufik Yusuf

Sekolah Teknik Elektro dan Informatika, Institut Teknologi Bandung
muhamad.taufik.yusuf@student.itb.ac.id

Abstraksi

Email sudah menjadi sarana utama dalam berkomunikasi menggunakan media

elektronik. Setiap orang yang memiliki komputer melakukan kirim terima pesan
menggunakan email setiap harinya. Saat ini email sudah menjadi bagian inti
komunikasi dengan fakta bahwa ada sekitar 3 (tiga) juta pesan terkirim setiap detiknya.
Penggunaan email yang luas tersebut ternyata juga mengakibatkan penyalahgunaan.
Orang-orang yang memiliki niat jahat menggunakan email untuk melakukan kejahatan.
Maraknya kasus penipuan melalui email menjadikan digital artefak memiliki
peranan penting dalam pengungkapan kasus kejahatan cyber. Sebab, forensik dijital
berbasis pada metode yang terbukti ilmiah dalam mengumpulkan dan menganalisa
informasi berbasis digital artefak. Penambahan informasi pada trace header
dimaksudkan untuk menjaga agar header tidak dimanipulasi, sehingga tetap dapat
menjadi digital artefak dan dapat digunakan untuk membuat mekanisme deteksi spam
atau pelacakan asal spam.
Pada makalah ini akan dibahas mengenai forensic readiness pada email yang
diterapkan pada SMTP trace header tanpa mengubah konten. Sebagai mekanisme
deteksi perubahan header pada email spam, akan diidentifikasi kesenjangan pada
received-token yang terdapat dalam received header.

Kata kunci: Forensic Readiness, SMTP Trace Header, Digital Artefak, Deteksi Spam.

EL6115 – Operasi Keamanan dan Incident Response

2

1. PENDAHULUAN

Email saat ini menjadi media yang paling popular untuk melakukan komunikasi
melalui internet. Karena kepopulerannya, komunikasi melalui email menjadi hal yang
menarik untuk di ekploitasi. Salah satu bentuk eksploitasi tersebut adalah spam. Pada
banyak kasus, spam menyebabkan masalah pada lalu lintas jaringan dan merugikan
perusahaan secara ekonomi. Spam juga mempengaruhi produktifitas para karyawan,
dimana banyak karyawan menghabiskan waktu kerjanya rata-rata 10 menit perhari
untuk memilah pesan email yang tidak diinginkan. Penerapan teknik penyaringan email
yang sudah ada seperti penerapan blacklist atau whitelist dan penyaringan konten, tidak
cukup mampu untuk mengidentifikasi spam. Hal ini karena para spammer menemukan
fitur pada header email yang dapat dimanipulasi untuk menghindari teknik penyaringan
email yang sudah ada. Teknik penyaringan tersebut hanya dapat mendeteksi email spam
menggunakan aturan atau keadaaan tertentu. Namun, akurasi pada teknik penyaringan
tersebut bisa menjadi false-positive atau false-negative yang disebabkan adanya
modifikasi informasi pada header email yang dilakukan oleh para spammer untuk
mengelabui teknik penyaringan tersebut. [1]
Header email menyediakan informasi yang berguna bagi kontennya.
Kebanyakan penelitian sekarang terfokus pada analisa tiap-tiap fitur yang terdapat pada
header untuk mengklasifikasikan email spam. Penelitian terbaru sudah dapat
mengidentifikasi beberapa fitur potensial pada header yang dapat digunakan untuk
mengklasifikasi spam. Penelitian tersebut mengusulkan beberapa fitur yang dapat
digunakan pada sistem pendeteksi untuk mandapatkan hasil yang efisien dalam
penyaringan terhadap email spam. Yahoo mail, Gmail and Hotmail adalah webmail
yang cukup popular memanfaatkan fitur yang tersedia pada masing-masing header-nya.
Setiap perubahan yang terjadi pada fitur-fitur tersebut dapat diasumsikan sebagai
perilaku spam. [2]
Ilmu forensik dijital berbasis pada metode yang terbukti ilmiah dalam
mengumpulkan dan menganalisa informasi digital atau artefak digital. Mengambil
teknik forensik dijital untuk mengumpulkan dan menganalisa informasi email,
menciptakan dimensi baru dalam melawan spam. Menambahkan konsep digital forensic
readiness pada email akan membuat pengumpulan artefak dijital menjadi lebih mudah.
Teknik forensik dijital dapat digunakan untuk memverifikasi informasi yang terkandung
dalam trace header pada email. Penambahan digital forensic readiness dilakukan pada
header “Receive:” yang merupakan bagian dari trace header pada SMTP. Dengan
memadukan forensik dijital, informasi trace header dapat digunakan untuk keperluan
lain seperti menciptakan mekanisme deteksi spam atau melacak asal spam tersebut.
Digital forensic readiness ditambahkan pada email envelope, jadi tidak ada pengaruh
kepada konten email. Sehingga konten tersebut tidak berubah.

EL6115 – Operasi Keamanan dan Incident Response

 3

Pada makalah ini dibahas mengenai penambahan digital forensik readiness dan
menyoroti perubahan yang akan dibutuhkan untuk diimplementasikan pada trace
header SMTP. Sehingga pada akhirnya disimpulkan bahwa penambahan digital forensic
readiness meningkatkan level integritas pada trace header SMTP yang dapat digunakan
untuk menambah tingkat kepercayaan pengguna. [3]

2. LANDASAN TEORI

2.1. Arsitektur Email

2.1.1. Komponen dan Protokol
Sistem email secara umum terdiri dari 2 (dua) komponen inti dan adanya
protokol komunikasi yang memungkinkan terjadinya pertukaran pesan elektronik
diantara mereka. Komponen pertama adalah email client, yang berfungsi sebagai
antarmuka untuk menerima, membaca, menulis dan mengirimkan email. Komponen
kedua adalah mail server atau SMTP server atau Message Transfer Agent (MTA), yang
berfungsi sebagai pengantar pesan dari sumber ke tujuan. Protokol pada sistem email
terdiri dari protokol SMTP yang menentukan proses pengiriman pesan dari mail server
sumber ke mail server tujuan, dan protokol POP3 atau IMAP yang menentukan proses
pengambilan pesan dari mail server tujuan ke email client. [4]
Interaksi antara komponen dan protokol pada sistem email dapat dilihat seperti
pada gambar berikut [4].

Gambar 1. Interaksi Protokol dan Komponen pada Sistem Email

2.1.2. Prinsip Kerja

Pengiriman email adalah keseluruhan proses perpindahan pesan dari sumber
pesan ke tempat tujuan. Proses tersebut dapat dilihat seperti pada gambar berikut [4].

EL6115 – Operasi Keamanan dan Incident Response

4

Gambar 2. Proses Perpindahan Email

Pada gambar diatas, email akan dikirimkan dari Adam sebagai sumber kepada
Smith sebagai tujuan dengan proses sebagai berikut:
1) Adam membuat sebuah email yang ditujukan untuk alamat smith@b.com dan
mengirimkannya;
2) Mail server pengirim melihat bahwa email tertuju kepada domain b.com. mail
server kemudian menggunakan servis DNS dan menanyakan NS server tentang
MX record dari b.com. Dari MX record diketahui server yang bertugas untuk
menerima semua email dengan domain b.com adalah mail.b.com;
3) Email kemudian diarahkan supaya menuju mail server penerima mail.b.com;
4) Mail server penerima kemudian menempatkan email tersebut pada mailbox
penerima, yaitu mailbox Smith;
5) Smith memeriksa email untuk user smith@b.com menggunakan servis POP3.
Untuk bisa mengakses mailbox-nya, Smith harus berhasil melewati proses
otentikasi servis POP3;
6) Jika otentikasi berhasil, Smith dapat mengunduh email tersebut melalui mail
client miliknya.

2.1.3. Format Standard

Format email didefinisikan pada RFC 822. Terdiri atas 2 (dua) bagian yaitu
header dan body email. Bagian header mengandung informasi routing dan informasi
lain seperti asal dan tujuan email, alamat IP pengirim dan informasi waktu. Bagian body

EL6115 – Operasi Keamanan dan Incident Response

 5

email mengandung pesan yang sebenarnya. Pada body email terkandung juga berkas
lampiran dengan format MIME atau SMIME. [5]
Pada Blok header terkandung beberapa baris teks dimana tiap-tiap barisnya
menyatakan sintaks: “header title: value”. Bagian body email terpisah dari header oleh
baris kosong, dimana isinya mengandung informasi tekstual si pengirim. [4]
Standard email terbaru menggunakan RFC 5322 [6] yang diperbaharui pada
tahun 2008. Berdasarkan standard tersebut, email terdiri atas envelope dan konten.
Envelope merupakan bagian dari protokol SMTP yang dapat dianalogikan sebagai
wadah dari pesan. Envelope membawa informasi tentang dari siapa pesan tersebut
dikirim dan kepada siapa pesan tersebut ditujukan. Informasi tentang pengirim
diperlukan untuk memberitahu pengirim apabila terjadi kesalahan dalam pengiriman
pesan. Format email berdasarkan RFC 5322 dapat dilihat seperti pada gambar berikut
[4].

Gambar 3. Format Email Sesuai RFC 5322

Envelope sendiri hanyalah wadah sementara yang dibuat mail server asal
sebelum pesan tiba di mail server tujuan. Ketika pesan sudah diterima oleh mail server
tujuan, envelope kemudian dihilangkan dan pesan masuk ke mailbox penerima. Tidak
ada hubungan yang melekat antara alamat penerima di envelope dengan alamat di
bagian header (seperti To:, Cc:, Bcc:) [4]. Namun demikian, berdasarkan RFC 5321 [7]
kolom header yang sesuai dapat digunakan untuk membentuk daftar penerima. Seperti
halnya surat yang dikirim dengan pos, ada alamat dituliskan di amplopnya. Tetapi pada
saat yang bersamaan, ada alamat lain yang dituliskan pada suratnya walaupun tidak
memungkinkan untuk dikirimkan. Itulah sebabnya mengapa kadangkala penerima

EL6115 – Operasi Keamanan dan Incident Response

6

menerima pesan meskipun alamatnya tidak tercantum dalam daftar penerima.

Pemakaian envelope dapat dilihat seperti pada gambar berikut [4].

Gambar 4. Pemakaian Envelope pada Format Email Baru

2.1.4. Header
Kolom header utama dirincikan pada (RFC 5322) [6] sebagaimana dapat dilihat
pada tabel berikut:

Tabel 1. Kolom Header Email

Kolom Header Deskripsi

From: Nama dan alamat email pembuat /pengirim
Date: Waktu lokal saat pesan ditulis atau dikirim
Message-Id: Kode pengenal unik yang dibangkitkan oleh mail
server. Dirancang untuk mencegah pengiriman ganda
dan digunakan sebagai referensi pada “In-Reply-To:”
In-Reply-To: Digunakan hanya untuk membalas pesan dan
memuat “Message–Id:” dari pesan asli, membuat
susunan relasi dari pesan.
To: Alamat-alamat email dari para penerima utama
Cc: Alamat-alamat email dari para penerima kedua.
Biasanya digunakan untuk mengindikasikan
penerima yang tidak berhubungan langsung dengan
masalah yang dikomunikasikan namun harus tetap
ditembuskan.
Bcc: Sama dengan “Cc:”, tapi disembunyikan dari
penerima. SMTP akan menghilangkan kolom ini
sebelum menghantarkan pesan.
Subject: Rangkuman isi pesan yang dapat dibaca
Content Type: Tipe MIME dari konten pesan. Dirancang oleh

EL6115 – Operasi Keamanan dan Incident Response

 7

Kolom Header Deskripsi

aplikasi email agar menampilkan pesan secara baik.
Received: Memuat informasi tentang semua mail server yang
terlibat dalam penghantaran pesan
References: Seperti kolom In-Reply-To: menggunakan
“Message-Id:”, tetapi dirancang untuk identifikasi
untaian korespondensi
Keywords: Kata kunci yang ditentukan oleh pengirim
Reply-To: Alamat email yang akan digunakan untuk membalas
pesan
Return-Path: Mengindikasikan alamat email dari pengirim pesan.
Alamat yang ada pada kolom header ini seharusnya
sama dengan yang ada di kolom “From:” pada SMTP
Envelope
Delivered-To: Alamat email penerima
Sender: Pengirim asli pesan. Umumnya menggunakan alamat
yang tertera pada kolom “From:”.

Tidak semua kolom header harus ada, tergantung kepada penggunaannya.

Sebagai contoh, setiap pesan email harus ada kolom “From:” dan kolom “Date:”, dan
perlu kolom “Message-ID:” dan “In-Reply-To:”. Kolom sisanya bersifat opsional atau
diatur oleh mail server secara otomatis. Kolom header lain yang menarik untuk dibahas
secara rinci adalah “Received:”. Kolom ini secara signifikan mampu memudahkan
perlawanan terhadap spam dan para spammer. Ketika kumpulan email yang tidak
diinginkan diterima, aplikasi email client hanya memperlihatkan header standar seperti
“To:”, “From:”, “Subject:”, dan “Date:”. Sama seperti email-email biasa lainnya.
Alamat yang tercantum pada kolom “From:” bisa jadi terlihat seakan-akan dari
seseorang yang dikenal atau dari sebuah organisasi yang bisa dipercayai. Namun
kenyataannya, pesan tersebut tidak berasal dari alamat sesuai yang terlihat di kolom
“From:”. Untuk melihat alamat pengirim sebenarnya, perlu dilakukan pengamatan
terhadap kolom “Received:” dimana kolom tersebut memberitahukan rute yang dilalui
pesan pada proses pengiriman.
Dari kolom-kolom tersebut, kolom “Received:” dan “Message-Id:” memiliki
peran penting untuk identifikasi terhadap integritas dan otentisitas email. [8]
1) “Received:”
Kolom “Received:” adalah bagian paling penting pada header email dan
biasanya kolom yang paling handal sebagaimana secara otomatis ditambahkan
oleh mail server pada saat transmisi email dari pengirim ke penerima. Kolom ini
menyediakan informasi tentang semua server dan komputer yang dilalui dalam

EL6115 – Operasi Keamanan dan Incident Response

8

perjalanannya dari pengirim sampai ke tujuan. Pada header biasanya terdapat

beberapa kolom “Received:”. Pembacaannya dimulai dari bawah keatas. Dengan
kata lain, baris “Received:” yang paling bawah mengandung informasi tentang
pengirim email, nama domain, alamat IP, stempel waktu dan lain-lain.
Sedangkan baris “Received:” yang paling atas mengandung informasi tentang
penerima email.
2) “Message-Id:”
Pada kolom ini terdapat kode pengenal unik yang digunakan pada email untuk
membantu membuktikan otentisitas sebuah email. Format yang umum adalah
menyerupai alamat email yang berada dalam kurung siku. Kode pengenal ini
terdiri dari 2 bagian yang dihubungkan dengan karakter @. Bagian sebelah kiri
@ adalah tanggal dan waktu, sedangkan bagian sebelah kanan @ adalah nama
domain dari host lokal. “Message-Id:” biasanya dibangkitkan dan ditambahkan
ke header email oleh mail server pengirim. Nilai pada kolom “Message-Id:”
sifatnya unik dan tidak bisa digunakan ulang.
Berikut ini adalah contoh gambar header lengkap dari sebuah email. Sumber:
Akun email penulis.
1 X-Apparently-To: klepitom@yahoo.com; Sat, 08 Apr 2017 07:36:48
+0000
2 Return-Path: <endakarina14@usbrokersestate.com>
3 Received: from 127.0.0.1 (EHLO smtp101.biz.mail.bf1.yahoo.com)
(98.139.221.60)
by mta1003.mail.gq1.yahoo.com with SMTPS; Sat, 08 Apr 2017
07:36:47 +0000
4 Received: (qmail 86001 invoked from network); 8 Apr 2017 07:36:46
-0000
5 Message-ID: <06894f02-42833-1ca23588413426@desktop-vk4l4e7>
6 Reply-To: "Enda Karina" <endakarinaid@gmail.com>
7 From: "Enda Karina" <endakarina14@usbrokersestate.com>
8 To: klepitom@yahoo.com
9 Subject: Halo
Gambar 5. Header Lengkap pada Email

Pada gambar diatas, tampak bahwa email tersebut dikirim oleh enda karina
(baris ke-7) kepada alamat klepitom@yahoo.com (baris ke-8). Informasi server
pengirim terletak pada baris ke-4 dan informasi server penerima terletak pada baris ke-
3. Sedangkan kode pengenal “Message-Id:” tampak pada baris ke-5.

2.2. Spam
2.2.1. Tipe dan Jenis
Spam email atau biasa disebut email sampah didefinisikan sebagai kumpulan
email yang tidak diinginkan. Kebanyakan spam email berisi tentang iklan komersial.
Namun tidak jarang pula mengandung tautan ke situs yang kelihatannya familiar, tetapi

EL6115 – Operasi Keamanan dan Incident Response

 9

ternyata ke situs malware. Spam email sendiri bisa juga mengandung malware dalam
bentuk script atau file lampiran executeable. [9]
Tipe-tipe spam dapat digolongkan sebagai berikut:
1) Spamvertise,
Merupakan spam email yang mengandung URL ke sebuah situs iklan. Menurut
laporan cyberoam, paling banyak adalah email produk farmasi seperti Viagra.
Kedua tentang tawaran kerja dan ketiga tentang produk diet.
2) Scam,
Spam email yang berisi modus penipuan. Tujuan akhirnya adalah meminta uang
kepada korbannya.
3) Phising,
Spam email palsu yang menggiring calon korban untuk memasukkan data
pribadi kedalam situs palsu. Biasanya situs yang dipalsukan adalah situs milik
institusi perbankan.

2.2.2. Teknik Spamming

Beberapa teknik yang berkembang dalam spam email diantaranya:
1) Appending,
Mengambil data pelanggan (nama depan, nama belakang, dan alamat) dan
mencocokkannya dengan database vendor untuk mendapatkan alamat email
pelanggan. Tujuannya adalah untuk membuat daftar email para pelanggan
tersebut dan mengirim informasi kepada email mereka.
2) Image spam,
Metode pengelabuan filter dengan meletakkan pesan teks sebagai file gambar
dengan format GIF atau JPEG dan menampilkannya pada email.
3) Blank spam,
Spam tanpa isi pada email. Metode ini menggunakan efek bouncing untuk
memisahkan alamat yang valid dengan alamat yang tidak valid. Dan merupakan
salah satu bentuk serangan directory harvest. Tujuannya adalah untuk
mengumpulkan alamat yang valid dari suatu penyedia layanan email.
4) Backscatter spam,
Terjadi ketika ada kesalahan konfigurasi mail server dalam mengirimkan bounce
email. Jika alamat pengirimnya dipalsukan, maka bouncing bisa masuk penerima
yang tidak seharusnya. Pesan ini tidak diminta oleh penerima, diterima berkali-
kali dan dikirim dalam jumlah banyak, sehingga digolongkan sebagai email
sampah atau spam.

EL6115 – Operasi Keamanan dan Incident Response

10

2.2.3. Anti Spam

Metode yang sudah popular dipakai untuk penyaringan dan menolak spam
diantaranya adalah penyaringan email berdasarkan konten email, daftar hitam berbasis
DNS (DNSBL), greylisting, spamtraps, pemaksaan kebutuhan teknis email (SMTP),
dan sistem deteksi spam dengan checksum. [10] Tiap-tiap metode memiliki kekuatan
dan kelemahan masing-masing.
1) Penyaringan Email,
Teknik penyaringan konten bergantung pada spesifikasi daftar kata atau kalimat
yang tidak diizinkan dalam pesan email. Misal kata “Viagra” termasuk dalam
konfigurasi penyaringan, maka mail server akan menolak setiap email yang
mengandung kata tersebut. Selain konten, ada juga penyaringan terhadap
header. Jika kata “Viagra” ditemukan pada kolom header, maka mail server
juga akan menolak email tersebut.
2) DNSBL,
Daftar hitam berbasis DNS, atau DNSBL adalah penyaringan berdasarkan
alamat IP. Mail server dapat dengan mudah diatur untuk menolak setiap pesan
yang berasal dari alamat IP tertentu. DNSBL dikategorikan menjadi beberapa
skor penilaian tergantung kebijakan yang berlaku. Misalnya: yang mengeluarkan
spam; yang berlaku sebagai mail relay; dan pendukung spam.
3) Greylisting,
Teknik greylisting dibuat karena protokol SMTP membolehkan penolakan
sementara terhadap pesan yang datang. Greylisting akan menolak semua pesan
secara sementara dari pengirim atau mail server yang belum dikenal, namun
nantinya akan diteruskan apabila memenuhi kriteria yang ditentukan.
4) Spamtraps,
Mencantumkan alamat email tertentu pada suatu situs namun tidak terbaca oleh
mata manusia karena ditempatkan pada kode sumber HTML. Alamat tersebut
dapat ditemukan jika menggunakan program aplikasi scrapping yang mengambil
alamat email dari kode sumber HTML. Ketika ada yang mengirimkan email ke
alamat tersebut, maka pengirimnya akan dimasukkan dalam daftar hitam dan
email dapat ditolak.
5) SMTP compliant,
Analisa kesesuaian email terhadap standard RFC untuk SMTP dapat digunakan
untuk menentukan apakah sebuah pesan termasuk kedalam kategori spam. Para
spammer menggunakan program kecil yang tidak bisa menyesuaikan dengan
standard. Spam dapat ditekan secara signifikan dengan mengatur limit yang
lebih ketat untuk kesenjangan terhadap standard RFC yang bisa diterima.

EL6115 – Operasi Keamanan dan Incident Response

 11

Resikonya, teknik ini juga akan menolak email yang berasal dari server yang
menggunakan konfigurasi lawas.
6) Checksum,
Penyaringan berbasis checksum mengandalkan variasi antar pesan yang
dikodekan sebagai checksum. Asumsinya adalah spam pada umumnya terkirim
dalam bentuk yang berulang dan dalam jumlah yang banyak. Pesan yang
terkirim secara masal biasanya akan tampak identik dengan variasi yang sedikit.
Sehingga checksum mudah diidentifikasi. Keuntungan dari teknik ini, pengguna
biasa selain administrator dapat ikut menentukan pesan-pesan yang dianggap
spam. Jadi resistensi terhadap spam dapat lebih luas dan cepat. Kekurangannya,
para spammer dapat menyisipkan nilai-nilai unik pada tiap pesan spam mereka
yang akan menghasilkan nilai checksum yang berbeda-beda pula.

2.3. Forensic Readiness

Ilmu forensik dijital merupakan cabang studi baru pengembangan dari ilmu
forensik. Ilmu forensik dijital lebih popular disebut forensik dijital atau forensik
komputer. Palmer [11] mendefinisikan forensik dijital sebagai penggunaan metode yang
diturunkan secara ilmiah terhadap presirvasi, pengumpulan, validasi, identifikasi,
analisis, interpretasi, dokumentasi, dan penyajian bukti digital yang berasal dari sumber
dijital untuk tujuan memfasilitasi atau melanjutkan rekonstruksi peristiwa-peristiwa.
Forensic Readiness adalah pencapaian dari tingkat kemampuan yang sesuai oleh
sebuah organisasi agar dapat mengumpulkan, menjaga, melindungi dan menganalisis
bukti digital sehingga bukti tersebut dapat digunakan secara efektif dalam setiap
masalah hukum, masalah penegakan disiplin, pengadilan tenaga kerja atau pengadilan
umum. Rowlingson [12] menyatakan bahwa digital forensic readiness terdiri atas dua
tujuan. Tujuan pertama adalah untuk memaksimalkan kemampuan untuk
mengumpulkan informasi forensik dijital. Tujuan kedua untuk meminimalkan biaya
investigasi forensik.
Agar SMTP siap secara forensik dijital, dibutuhkan penambahan sebuah
mekanisme pada SMTP untuk menjaga, mengumpulkan dan melakukan validasi
terhadap informasi yang terkandung pada SMTP header. Informasi-informasi yang
dikumpulkan dari SMTP header kemudian dapat digunakan sebagai bagian dari
investigasi forensik dijital. [3]

2.4. SMTP Trace Header

2.4.1. Simple Mail Transfer Protocol (SMTP)
SMTP pertama kali diusulkan dalam Request for Comments (RFC) 821 di bulan
Augustus 1982. Protokol ini berbasis pada arsitektur “snail mail” dimana email dikirim
dari satu kantor pos ke kantor pos berikutnya sampai diterima di mailbox yang
diinginkan. RFC SMTP terbaru muncul pada Oktober 2008 yaitu RFC 5321. Servis

EL6115 – Operasi Keamanan dan Incident Response

12

standard yang tidak digunakan secara regular, tidak dijabarkan pada dokumen RFC
terbaru namun tetap tersedia. [7]
SMTP dibuat dengan harapan menjadi protokol komunikasi yang ringan sebagai
standard komunikasi elektronik melalui internet. Sejak standardisasi SMTP pada 1982,
pemanfaatan komunikasi berbasis SMTP semakin meningkat. Hal itu disebabkan karena
kehandalan dan kemudahan penggunaan SMTP. Namun karena kemudahan tersebut,
protokol ini cenderung disalahgunakan. Perlindungan yang paling sering diterapkan
untuk melindungi pengguna dari spam adalah saringan anti spam yang melindungi
mailbox milik pengguna dari email yang tidak diinginkan.

2.4.2. Email Spoofing

Informasi pada header SMTP tersimpan dalam bentuk teks terbaca. Oleh
karenanya dapat dengan mudah di edit. Perubahan pada header email dilakukan untuk
menyembunyikan informasi asal email. Kegiatan merubah header email untuk
menyembunyikan informasi disebut dengan spoofing (pemalsuan). [3] Spoofing juga
digunakan untuk memasukkan validitas palsu dari sebuah konten email melalui domain
terpercaya dalam rangka menyukseskan serangan phising.
Pada RFC 4406 dipaparkan 2 (dua) uji terhadap server SMTP untuk melakukan
verifikasi terhadap header email yang sudah mengalami pemalsuan. [13] Uji pertama
adalah uji Purported Responsible Address (PRA). Jika tidak ditemukan PRA pada
header SMTP, kemungkinan besar email tersebut sudah mengalami pemalsuan. Jika
PRA didapatkan, belum tentu email tersebut tidak mengalami pemalsuan. Sehingga
memerlukan uji selanjutnya untuk meyakinkan validitasnya. Uji kedua menggunakan
Sender Policy Framework (SPF) untuk melakukan otentikasi terhadap keabsahan client
SMTP sebagai domain asal. Wong [14] mengusulkan agar SPF dijadikan metode untuk
mendeteksi email palsu yang modusnya menggunakan informasi domain yang valid
agar terlihat asli. Domain pengirim yang seharusnya dan informasi routing pada header
diotentikasi oleh DNS pemilik domain. Hal ini untuk memastikan domain dari client
SMTP memiliki otoritas untuk bertindak sebagai domain pengirim yang benar. Jika
prosesn otentikasi gagal, maka email ditandai sebagai email palsu.

2.4.3. Trace Header

Trace header terdiri dari dua sub header bernama “Return-path:” dan
“Received:”. “Return-path:” digunakan untuk menyimpan alamat pengiriman laporan
jika terjadi kesalahan. “Received:” menyimpan jalur penghantaran dengan kode
penanda data untuk setiap entri pos penghantaran. Format trace header didefinisikan
pada RFC 5322 sebagai trace rule. Cara penggunaan trace header sebagaimana
didefinisikan pada RFC 5321 adalah dengan mengirimkan laporan kesalahan kepada
pengirim seperti membuat laporan pengiriman yang dpat digunakan sebagai informasi
inputan ketika melakukan troubleshooting. Klensin [7] mengusulkan pada RFC 5321

EL6115 – Operasi Keamanan dan Incident Response

 13

agar trace header diwajibkan untuk semua server SMTP yang menerapkan standard
5321.
Penambahan pada trace header dibatasi untuk kolom “Received:” saja, sehingga
hanya received rule yang diberikan. Received rule dan received-token rule dapat dilihat
sebagaimana pada gambar berikut [7].

received = "Received:" *Received-token ";" date-time CRLF

received-token = "from" (word / angle-addr / addr-spec / domain)
"by" (word / angle-addr / addr-spec / domain)

Gambar 6. Received Rule dan Received-Token Rule

Received rule pada gambar diatas mengindikasikan bahwa trace header harus
diawali dengan kata “Received:” dan diikuti dengan daftar received-token. Daftar
received-token kemudian diikuti dengan stempel waktu dan karakter Carriage Return
Line Feed (CRLF) untuk menandakan akhir dari isi trace header. Sedangkan received-
token rule, menandakan bahwa received-token harus dimulai dengan kata “from” diikuti
dengan alamat host pengirim. Dan received-token diakhiri dengan kata “by” diikuti
dengan alamat host penerima.

3. INVESTIGASI POLA SPAM PADA HEADER

Pemalsuan alamat email dapat dengan mudah dilakukan. Cukup dengan

merubah alamat pengirim email pada header. Untuk dapat mengamati header, perlu
dilihat keseluruhan header. Semua program aplikasi email client, biasanya memiliki
sebuah fungsi khusus untuk menampilkan keseluruhan bagian email. Berikut ini adalah
gambar fungsi untuk menampilkan header lengkap pada akun email student.itb.ac.id
yang berbasis aplikasi zimbra. Sumber: Akun email penulis.

Gambar 7. Fungsi Menampilkan Full Header pada Zimbra

EL6115 – Operasi Keamanan dan Incident Response

14

Berikut ini adalah email dengan format header lengkap.

1 Return-Path: jokowi@yahoo.co.id
2 Received: from students.itb.ac.id (LHLO students.itb.ac.id)
(167.205.23.24)
by students.itb.ac.id with LMTP; Wed, 10 May 2017 16:16:14 +0700
(WIB)
3 Received: from localhost (localhost [127.0.0.1])
by students.itb.ac.id (Postfix) with ESMTP id 462887CA150D
for <muhamad.taufik.yusuf@students.itb.ac.id>; Wed, 10 May
2017 16:15:56 +0700 (WIB)
4 X-Virus-Scanned: amavisd-new at students.itb.ac.id
5 X-Spam-Flag: NO
6 X-Spam-Score: -0.22
7 X-Spam-Level:
8 X-Spam-Status: No, score=-0.22 tagged_above=-10 required=6.6
tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001,
FREEMAIL_FROM=0.001,
NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_PASS=-0.001,
SPF_NEUTRAL=0.779]
autolearn=no autolearn_force=no
9 Received: from students.itb.ac.id ([127.0.0.1])
by localhost (students.itb.ac.id [127.0.0.1]) (amavisd-
new, port 10024)
with ESMTP id lIVBvgeeiV10
for <muhamad.taufik.yusuf@students.itb.ac.id>;
Wed, 10 May 2017 16:15:55 +0700 (WIB)
10 Received: from emkei.cz (emkei.cz [46.167.245.71])
by students.itb.ac.id (Postfix) with ESMTPS id
AB6737CA16A0
for <muhamad.taufik.yusuf@student.itb.ac.id>; Wed, 10 May
2017 16:15:55 +0700 (WIB)
11 Received: by emkei.cz (Postfix, from userid 33)
id 901FFD60E5; Wed, 10 May 2017 11:15:53 +0200 (CEST)
12 To: muhamad.taufik.yusuf@student.itb.ac.id
13 Subject: Undangan makan malam di Balaikota
14 From: "Joko Widodo" <jokowi@yahoo.co.id>
15 X-Priority: 3 (Normal)
16 Importance: Normal
17 X-Mailer: Zimbra
18 Errors-To: jokowi@yahoo.co.id
19 Reply-To: jokowi@yahoo.co.id
20 Content-Type: text/plain; charset=utf-8
21 Message-Id: <20170510091553.901FFD60E5@emkei.cz>
22 Date: Wed, 10 May 2017 11:15:53 +0200 (CEST)

23 Bersama ini Bapak Gubernur DKI Jakarta, Ir. Joko Widodo mengundang
Saudara untuk jamuan makan malam di balaikota Provinsi DKI Jakarta
pada:

Hari/tanggal : Sabtu, 13 Mei 2017

Pukul : 18.00 s.d Selesai
Dresscode : Batik

Mengingat pentingnya acara tersebut, agar dapat hadir tepat waktu.

Tembusan: Sekda Provinsi DKI Jakarta

Nb. Ada undian berhadiah rumah dan motor.

EL6115 – Operasi Keamanan dan Incident Response

 15

Pada contoh email diatas, baris ke-1 sampai dengan ke-22 adalah header
sedangkan baris ke-23 adalah body. Berikut ini adalah potongan header dari baris ke-11
sampai dengan baris ke-14.
11 Received: by emkei.cz (Postfix, from userid 33)
id 901FFD60E5; Wed, 10 May 2017 11:15:53 +0200 (CEST)
12 To: muhamad.taufik.yusuf@student.itb.ac.id
13 Subject: Undangan makan malam di Balaikota
14 From: "Joko Widodo" <jokowi@yahoo.co.id>

Pada potongan header diatas, kolom “Receive:” berada pada baris ke-11 dan
diikuti kata “by” yang menandakan bahwa email tersebut diterima oleh mail server
postfix dengan domain emkei.cz. Sedangkan alamat email pengirim pada kolom
“From:” di baris ke-14 menandakan bahwa pengirim email tersebut adalah Joko
Widodo dengan alamat jokowi@yahoo.co.id. Berikut ini adalah potongan header dari
baris ke-1 sampai dengan baris ke-3 dan baris ke-9 sampai dengan baris ke-11.
1 Return-Path: jokowi@yahoo.co.id
2 Received: from students.itb.ac.id (LHLO students.itb.ac.id)
(167.205.23.24)
by students.itb.ac.id with LMTP; Wed, 10 May 2017 16:16:14 +0700
(WIB)
3 Received: from localhost (localhost [127.0.0.1])
by students.itb.ac.id (Postfix) with ESMTP id 462887CA150D
for <muhamad.taufik.yusuf@students.itb.ac.id>; Wed, 10 May
2017 16:15:56 +0700 (WIB)
…………………………………………………………………………………………………………………………………………………………
9 Received: from students.itb.ac.id ([127.0.0.1])
by localhost (students.itb.ac.id [127.0.0.1]) (amavisd-
new, port 10024)
with ESMTP id lIVBvgeeiV10
for <muhamad.taufik.yusuf@students.itb.ac.id>;
Wed, 10 May 2017 16:15:55 +0700 (WIB)
10 Received: from emkei.cz (emkei.cz [46.167.245.71])
by students.itb.ac.id (Postfix) with ESMTPS id
AB6737CA16A0
for <muhamad.taufik.yusuf@student.itb.ac.id>; Wed, 10 May
2017 16:15:55 +0700 (WIB)
11 Received: by emkei.cz (Postfix, from userid 33)
id 901FFD60E5; Wed, 10 May 2017 11:15:53 +0200 (CEST)

Pada potongan header diatas, kolom “Receive:” pada baris ke-10 diikuti kata
“from” dan “by”. Artinya email diterima oleh mail server students.itb.ac.id dari mail
server emkei.cz yang alamat IP nya adalah 46.167.245.71. Jika email tersebut adalah
spam, maka mail server ini kemungkinan adalah Servis SMTP yang digunakan untuk
mengirim spam. Kolom ‘Receive:” berikutnya terletak pada baris ke-9 yang
menandakan bahwa email diterima oleh mail server localhost dengan alamat IP
127.0.0.1 pada domain students.itb.ac.id. Pada baris ini terlihat mail server
student.itb.ac.id mengirimkan email tersebut kepada amavisd-new yang merupakan
program perantara untuk diteruskan kepada program antivirus. Pada baris ke-3 email
diterima kembali oleh postfix mail server student.itb.ac.id dari localhost. Tampak pada
baris tersebut email ditujukan kepada muhamad.taufik.yusuf@students.itb.ac.id. Dan

EL6115 – Operasi Keamanan dan Incident Response

16

pada baris ke-2 email diterima dari mail server students.itb.ac.id dengan alamat IP
167.205.23.24. Jika di amati, perjalanan email tersebut adalah sebagai berikut: emkei.cz
(Postfix)  students.itb.ac.id (Postfix)  localhost (students.itb.ac.id - amavisd-new)
 students.itb.ac.id (Postfix)  muhamad.taufik.yusuf@students.itb.ac.id.
Berikut ini adalah potongan header dari baris ke-1, baris ke-11, baris ke-14 dan
baris ke-21 sampai dengan baris ke-22.
1 Return-Path: jokowi@yahoo.co.id
…………………………………………………………………………………………………………………………………………………………
11 Received: by emkei.cz (Postfix, from userid 33)
id 901FFD60E5; Wed, 10 May 2017 11:15:53 +0200 (CEST)
14 From: "Joko Widodo" <jokowi@yahoo.co.id>
…………………………………………………………………………………………………………………………………………………………
21 Message-Id: <20170510091553.901FFD60E5@emkei.cz>
22 Date: Wed, 10 May 2017 11:15:53 +0200 (CEST)

Pada potongan header diatas, isi kolom “From:” pada baris ke-14 sama dengan
kolom “Return-Path:” pada baris ke-1. Jika kedua baris tersebut tidak sama, bisa jadi
email tersebut adalah spam. Pada baris ke-21 terdapat kolom “Message-Id:” yang
merupakan kode pengenal unik yang dibangkitkan dari mail server pengirim. Jika
domain pada kolom “Message-Id:” dengan domain pada kolom “Received:” diatasnya,
yaitu pada baris ke-11 tidak sama, bisa jadi email tersebut juga spam. Parameter lain
yang bisa dilihat adalah nama domain pada kolom “From:” seharusnya sama dengan
nama domain pada kolom “Message-Id:” kecuali jika Servis SMTP pada mail server
tersebut digunakan untuk mengirim spam.

4. PENERAPAN FORENSIC READINESS

4.1. Modifikasi Trace Header

Informasi untuk keperluan forensik dijital bisa ditambahkan pada SMTP trace
header untuk memastikan validitas informasi pelacakan berdasarkan teknik forensik
dijital. Penambahan Informasi forensik dijital difokuskan kepada receive rule yang
merupakan subheader dari SMTP trace header. Receive rule dirubah untuk
mengakomodasi penambahan informasi forensik dijital berupa nilai hash. Perubahan
receive-token rule dapat dilihat seperti gambar berikut [3].

received-token = "from" (word/angle-addr/addr-spec/domain)":" hash

"by" (word/angle-addr/addr-spec/domain)":" hash

Gambar 8. Received-token dengan Penambahan Informasi Forensik Dijital

Pada gambar diatas, terdapat penambahan 2 (dua) nilai hash. Nilai hash pertama
setelah kata “from” yang merupakan nilai hash dari nama domain pengirim dan alamat
IP hasil DNS lookup dari nama domain pengirim. Nilai hash kedua setelah kata “by”

EL6115 – Operasi Keamanan dan Incident Response

 17

yang merupakan nilai hash dari nama domain host penerima dan alamat IP hasil DNS
lookup dari nama domain host penerima. Fungsi hash yang dipakai adalah SHA-1 atau
algoritma lain yang sejenis untuk menjaga integritas dari received-token. Perubahan
received rule dapat dilihat seperti gambar berikut [3].

received = "Received:" 1*1Received-token ";" date-time CRLF

Gambar 9. Received Rule Baru

Pada gambar diatas, received rule yang tadinya “*” dirubah menjadi “1*1” yang
artinya paling tidak ada satu dan hanya satu saja entri received-token. Artinya kolom
“Received:” paling tidak ada satu received-token, sehingga informasi forensik dijital
selalu tersedia. Dan kolom “Received:” hanya ada satu entri received-token maksudnya
adalah untuk memudahkan proses ekstraksi informasi menggunakan algoritma deteksi
kesenjangan.

4.2. Algoritma Deteksi

Kolom “Receive:” yang mengandung daftar received-tokens dalam bentuk
pasangan host pengirim dan host penerima disebut pasangan send-receive. Daftar
tersebut tidak akan lengkap jika semua host SMTP yang terlibat selama proses
pengiriman tidak melakukan pembaruan terhadap kolom “Receive:” sesuai dengan
spesifikasi yang sudah ditetapkan. Dengan kata lain akan terjadi kesenjangan pada
daftar tersebut. Kesenjangan yang dimaksud adalah putusnya informasi pengiriman
pada kolom “Receive:” ketika satu atau lebih pasangan send-receive tidak terdeteksi di
informasi forensik dijital. Kesenjangan-kesenjangan tersebut dapat dideteksi
menggunakan pasangan send-receive. Algoritma deteksi digunakan untuk mendeteksi
kesenjangan pada informasi forensik dijital yang tersimpan pada kolom “Receive:” dan
untuk menyimpan informasi pelacakan untuk penggunaan lebih lanjut.
Algoritma deteksi kesenjangan dijabarkan dengan langkah-langkah sebagai
berikut:
1) Simpan pasangan send-receive yang diterima, mulai dari entri terakhir sampai
dengan yang pertama dalam sebuah antrian.
2) Catat alamat host yang diterima dari entri pertama pada antrian.
3) Lihat pada pasangan send-receive berikutnya dan bandingkan alamat host
pengirim dengan alamat host penerima. Jika alamatnya sama, lanjut ke langkah
4. Namun jika alamatnya tidak sama, simpan alamat pengirim dan lanjut ke
langkah 5.
4) Simpan alamat host penerima pada daftar terbukti dan lanjutkan ke langkah 6.
5) Simpan alamat host penerima pada daftar terbukti. Simpan alamat host
pengiriman pada daftar kesenjangan dan pasang flag untuk temuan kesenjangan
dengan kondisi true. Kemudian lanjutkan ke langkah 6

EL6115 – Operasi Keamanan dan Incident Response

18

6) Jika pasangan send-receive berikutnya bernilai null, maka lanjutkan ke langkah

7. Jika tidak, simpan alamat host penerimaan berikutnya dan lanjutkan ke
langkah 3.
7) Jika flag penemuan kesenjangan dalam kondisi true, akhiri proses dengan pesan
keluaran “kesenjangan terdeteksi”. Jika tidak, akhiri proses dengan dengan pesan
keluaran “kesenjangan tidak ditemukan”.

Pada akhirnya tercipta dua daftar: daftar terbukti yang memperlihatkan host
yang menerapkan tambahan kolom “Receive:” dan daftar kesenjangan yang
memperlihatkan host yang diketahui terakhir kali tidak menerapkan penambahan pada
kolom “Receive:”.
Jika tidak ada kesenjangan yang terdeteksi pada email, informasi pada daftar
yang berkaitan dengan email tersebut dapat digunakan sebagai jejak forensik dijital
dengan mengikuti pasangan send-receive yang benar pada kolom “Receive:”. Meskipun
informasi forensik dijital ditambahkan pada kolom “Receive:”, namun headernya
sendiri tetap disimpan dalam bentuk teks terbaca dan tetap dapat diedit oleh spammer.
Oleh karenanya, hanya pada kondisi tidak ada kesenjangan pada kolom “Receive:”, lah
pasangan send-receive dapat digunakan untuk melacak jejak asal email spam.

5. KESIMPULAN

Popularitas komunikasi email tanpa dibarengi dengan perubahan signifikan

terhadap arsitekturnya membuat email rentan terhadap banyak jenis serangan spam.
Untuk meningkatkan kehandalan email, sangat dibutuhkan mekanisme untuk dapat
melakukan verifikasi alamat pengirim pada kolom “From:” dan alamat penerima pada
kolom “to:”. Metode verifikasi tersebut berdasar pada investigasi terhadap trace header
yang membuat metode ini memungkinkan untuk membedakan email yang diinginkan
dengan spam dengan akurasi yang tinggi.
Pada trace header email dapat ditambahkan informasi forensik dijital berupa
nilai hash dari informasi domain pada received-token yang ada pada kolom “Receive:”.
Algoritma deteksi kesenjangan, menggunakan informasi received-token untuk membuat
2 (dua) daftar informasi yaitu daftar terbukti dan daftar kesenjangan. Daftar terbukti
menyimpan informasi tentang host SMTP yang menerapkan trace header yang sudah
ditentukan. Sedangkan daftar kesenjangan menyimpan informasi tentang host SMTP
yang tidak menerapkan trace header yang sudah ditentukan.

EL6115 – Operasi Keamanan dan Incident Response

 19

6. PENELITIAN LEBIH LANJUT

Penelitian selanjutnya perlu dilakukan perbaikan dan penerapan forensic

readiness untuk menciptakan jaringan SMTP terpercaya beserta penggunaannya.

7. REFERENSI

[1] S. Hinde, "Spam, scams, chains, hoaxes and other junk mail," Computers &
Security, vol. 21, pp. 592 - 606, 2002.
[2] S. Bin Abd Razak and A. F. Bin Mohamad, "Identification of spam email based on
information from email header," International Conference on Intellient Systems
Design and Applications, vol. 13th, pp. 347-353, 2013.
[3] F. R. Van Staden and H. S. Venter, "Adding digital forensic readiness to the email
trace header," in 2010 Information Security for South Africa, Sandton,
Johannesburg, 2010.
[4] A. Adamov, "Internet technologies in depth. the technique of spam recognition
based on header investigating," International Conference on Application of
Information and Communication Technologies (AICT), vol. 5th, pp. 1-4, 2011.
[5] H. Guo, B. Jin and W. Qian, "Analysis of Email Header for Forensics Purpose,"
International Conference on Communication Systems and Network Technologies,
pp. 340-344, 2013.
[6] P. Resnick, "RFC 5322 : Internet Message Format," Oktober 2008. [Online].
Available: https://www.ietf.org/rfc/rfc5322.txt. [Accessed 01 Mei 2017].
[7] J. Klensin, "RFC 5321 : Simple Mail Transfer Protocol," Oktober 2008. [Online].
Available: https://tools.ietf.org/pdf/rfc5321.pdf. [Accessed 01 Mei 2017].
[8] A. Jayan and S. Dija, "Detection of spoofed mails," in 2015 IEEE International
Conference on Computational Intelligence and Computing Research (ICCIC),
Madurai, 2015.
[9] Wikipedia, "Email Spam," [Online]. Available:
https://en.wikipedia.org/wiki/Email_spam. [Accessed 24 April 2017].
[10] Wikipedia, "Teknik Anti Spam," [Online]. Available:
https://en.wikipedia.org/wiki/Anti-spam_techniques. [Accessed 24 April 2017].
[11] G. Palmer, "Road Map for Digital Forensic Research," [Electronic Publication] s.l.
: Digital Forensic Research Workshop (DFRWS), 2002.
[12] R. Rowlingson, "A Ten Step Process for Forensic Readiness," International
Journal of Digital Evidence, vol. II, no. 3, 2004.
[13] J. Lyon and M. Wong, "Sender ID: Authenticating E-Mail," RFC 4406. s.l. :
Internet Engineering Task Force (2006), April 2006.
[14] M. Wong and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of
Domains in E-Mail, Version 1," RFC 4408. s.l. : Internet Engineering Task Force
(2006), April 2006.

EL6115 – Operasi Keamanan dan Incident Response