Việc gửi Email không vào SPAM là điều chúng ta đều mong muốn, nhưng hiểu rõ cách thức chặn SPAM và xác thực của hệ thống thì không nhiều tài liệu tiếng Việt viết về vấn đề này.
Chính vì lý do này nên trong quá trình nghiên cứu về Email Marketing, mangkiemtien đã dành khá nhiều thời gian để dịch lại các tài liệu tiếng anh để hiểu được cơ chế xác thực. Sau khi đã cài đặt và ứng dụng được khá ổn
hệ thống Email Marketing. Chúng tôi xin phép được tổng hợp lại một số kiến thức để các bạn có nhu cầu tìm hiểu về Email marketing nắm rõ:
Chính vì lý do này nên trong quá trình nghiên cứu về Email Marketing, mangkiemtien đã dành khá nhiều thời gian để dịch lại các tài liệu tiếng anh để hiểu được cơ chế xác thực. Sau khi đã cài đặt và ứng dụng được khá ổn
hệ thống Email Marketing. Chúng tôi xin phép được tổng hợp lại một số kiến thức để các bạn có nhu cầu tìm hiểu về Email marketing nắm rõ:
1- Cơ chế xác thực email của các hệ thống email
Các bạn nhìn thấy bảng tổng hợp ở trên để có một cái nhìn tổng quan về các hệ thống Email họ xác thực Email SPAM hay không SPAM qua cơ chế: DKIM, SENDER ID, SPF, DOMAIN KEYS.Điều này một lần nữa xác định rõ, việc gửi Email từ phần mềm sẽ không thể qua được hệ thống chặn Email SPAM với 4 cơ chế lọc như trên.
Các bạn nhìn thấy bảng tổng hợp ở trên để có một cái nhìn tổng quan về các hệ thống Email họ xác thực Email SPAM hay không SPAM qua cơ chế: DKIM, SENDER ID, SPF, DOMAIN KEYS.Điều này một lần nữa xác định rõ, việc gửi Email từ phần mềm sẽ không thể qua được hệ thống chặn Email SPAM với 4 cơ chế lọc như trên.
- DKIM: DKIM (DomainKeys Identified Mail) là một phương pháp xác thực e-mail bằng chữ ký số của miền gửi thư, trong đó khóa công khai thường được công bố trên DNS dưới dạng một TXT record.
Khi gửi thư, bộ ký thư sẽ chèn lên đầu thư một trường DKIM-Signature có nội dung đại khái như sau:
Code:
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mycompany.com; s=sitec; t=1250425543;
Code:
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mycompany.com; s=sitec; t=1250425543;
bh=qQxSOEYYHCCISqVJ6pi/vUuNCr0EqMNkRSnD0B0TNFQ=; h=Message-ID:From:To:Subject: Date:MIME-Version:Content-Type; b=aiL+F+rqOdVxmR1V0bdfwsVOvMpwv1eMcCrX5I2C6U9CX+mkyepL3t0PwkW8pLSFc CpJ5NvsBGqgOK4f2h89IubyYMFU0BkqZmtlBFlL+wyximVXLtHxO95WOxJX380tCet XwofYIOK7tx45K41hG4T7+5ylNSuO1HHMpM/WfOM=
Trong đó có mọi thông tin cần thiết như phiên bản DKIM (v), thuật toán ký (a), thuật toán chuẩn hóa xâu ký tự đưa đi ký ( c ), tên miền ký (d), tên cặp khóa, hay còn gọi là selector (s), dấu ấn thời gian (t), thời hạn hiệu lực của chữ ký (x), phương thức truy vấn để lấy khóa công khai (q), danh sách các trường của phần đầu thư được ký (h), độ dài phần thân thư được ký (l), giá trị hash của nội dung được ký (bh), và chữ ký (b).
Khi nhận thư, bộ kiểm thư sẽ xác định khóa công khai theo phương pháp q (trong ví dụ trên, vốn dĩ không chỉ rõ q, phương pháp mặc định là truy vấn DNS tìm TXT record có tên là sitec._domainkey.mycompany.com.), dựa vào đó kiểm tra chữ ký rồi chèn kết quả kiểm tra vào trường Authentication-Results [2] của thư. Chẳng hạn, kết quả tốt được viết như sau:
Code:
Authentication-Results: … dkim=pass header.i=@mycompany.com
Authentication-Results: … dkim=pass header.i=@mycompany.com
Kết quả này xác thực các trường của phần đầu thư đã kể trong mục h (tức Message-ID, From, To, Subject, Date, MIME-Version và Content-Type trong ví dụ trên) cùng với phần thân thư có độ dài kể trong mục l (tức toàn bộ phần thân thư trong ví dụ trên, vốn dĩ với mục l mặc định).
Trong dây chuyền nộp – chuyển – phát thư, bộ ký thư thường đặt tại sending MTA và bộ kiểm thư thường đặt tại receiving MTA. Khi đó DKIM thực chất chỉ xác nhận thư được bảo toàn trên suốt chặng đường chuyển thư. Việc đảm bảo một lá thư From:alice@mycompany.com chắc chắn thuộc về Alice nằm ngoài trách nhiệm của DKIM.
Ngoài ra, tùy theo chính sách kiểm tra chữ ký DKIM của mình, bộ kiểm thư có thể tìm hiểu chính sách ký DKIM (tức ADSP, Author Domain Signing Practices [3]) của mycompany.com bằng cách truy vấn DNS tìm TXT record tên là _adsp._domainkey.mycompany.com., căn cứ vào đó (và tùy theo kết quả kiểm tra chữ ký) để quyết định có chấp nhận lá thư hay không
- Sender ID là gì ? là một đề nghị chống giả mạo từ các nhóm MARID cựu làm việc IETF đã cố gắng để tham gia Sender Policy Framework (SPF) và ID người gọi. Tên người gửi ID được định nghĩa chủ yếu trong thử nghiệm RFC 4406, nhưng có phần bổ sung trong RFC 4405, RFC 4407 và RFC 4408
- SPF là gì ? Sender Policy Framework (SPF) là một nỗ lực để kiểm soát giả mạo e-mail. SPF là không trực tiếp ngăn chặn spam – thư rác. Nó về cho chủ sở hữu tên miền một cách để nói trước với các nguồn thư hợp pháp cho tên miền của họ và những người thân mà không phải. Trong khi không phải tất cả các thư rác là giả mạo, hầu như tất cả các giấy tờ giả mạo là thư rác. SPF không chống thư rác trong cùng một cách mà là một phần của giải pháp.
SPF được tạo ra vào năm 2003 để giúp các lỗ hổng chặt chẽ trong hệ thống cung cấp thư điện tử cho phép gửi thư rác để “spoof” hoặc ăn cắp địa chỉ email của bạn để gửi hàng trăm, hàng ngàn hoặc thậm chí hàng triệu thư điện tử bất hợp pháp.
SPF là một giao thức được phát triển bởi một nhóm các tình nguyện viên năng động, sự tham gia của một mong muốn lẫn nhau để cải thiện hoạt động của Internet. Nó là không một sản phẩm thương mại được cung cấp bởi một công ty phi lợi nhuận. Giao thức SPF được thông qua bởi một số lượng ngày càng tăng của các máy chủ tên miền và cung cấp dịch vụ Internet (ISP), và trong bất kỳ quá trình phát triển công nghệ, sẽ có một số va chạm trên đường. Trong khi những người đứng sau trang web này và những người đã giúp phát triển SPF có thể có thể để giúp bạn hiểu làm thế nào để giải quyết vấn đề khi phát sinh, họ không trực tiếp chịu trách nhiệm cho những vấn đề bạn có thể gặp.
SPF hôm nay là một công nghệ tương đối mới. Nó không phải là thân thiện với người dùng nếu bạn không quen thuộc với các giao thức e-mail.
- Domain keys là gì? là một hệ thống email xác thực được thiết kế để xác minh tên miền DNS của một người gửi e-mail và tính toàn vẹn thông điệp. Các đặc điểm kỹ thuật DomainKeys đã thông qua các khía cạnh của mail Internet . Cả hai DomainKeys và DKIM đã được xuất bản tháng 5 năm 2007.
2- Bảng hướng dẫn cài đặt DKIM, SPF, DOMAIN KEYS, SENDER ID của Google:
| Name/Host | Value/Answer | |
|---|---|---|
| Domain verification | Blank or @, depending on the domain provider | Your unique Google Apps security token, provided in the Google Apps control panel’s verification instructions.
The token is a 68-character string that begins with google-site-verification:, followed by 43 additional characters.
|
| SPF record | Blank or @, depending on the domain provider | v=spf1 include:_spf.google.com ~all to authorize the Google Apps mail servers.
To authorize an additional mail server, add the server’s IP address before just before the ~all argument using the formatip4:address or ip6:address. (Click here for more details on the SPF format.)
|
| DKIM signing | Text from the DNS Host name (TXT record name) field in the Google Apps control panel | Text from the TXT record value field in the Google Apps control panel. |
| DMARC authentication | _dmarc.your_domain.com IN TXT | “v=DMARC1; p=quarantine; pct=100; rua=mailto:postmaster@your_domain.com”
To allow third-party recipients to monitor, quarantine, or reject all the messages that claim to be from “your_domain.com” and fail the DMARC checks. You must replace “your_domain.com” with your own domain name. Daily aggregate reports will be sent to “postmaster@your_domain.com” (You’ll need to specify a valid email address to receive reports for your domain).
|