Docker có khó không? :)

Câu trả lời: vừa khó, lại vừa không khó lắm 😉

Khó nhất là vì với một đứa lười như tớ, gần nửa đời người rồi, bắt đầu chuyển qua hệ mải chơi, chém gió, ham những món vận động vui khỏe như đạp xe, chạy bộ… rồi máu dong chơi lang thang từ thuở thiếu thời quay trở lại 😀

Nhưng mà cuộc sống thì vẫn phải làm việc, không lấy gì mà đi chơi 🙂 và quan trọng nhất là cần luôn tìm được niềm vui trong những việc mình làm, nên tớ quyết định bắt đầu mày mò.

Món Docker này kể ra cũng chả có gì gọi là mới, có mặt trên dưới chục năm rồi, từng là hot-trend và hiện vẫn được anh em devOps ưa dùng (dù đã xuất hiện một số công nghệ mới được đánh giá là có khả năng thay thế tốt hơn – tớ sẽ viết trong bài khác, khi có hứng)

Cảm nhận đầu tiên là Docker quả không hổ danh là một trong những nền tảng hot nhất những năm gần đây, documentation đầy đủ, cộng với hằng hà sa số những bài viết giá trị từ những người có kinh nghiệm. Tớ google trong 1/2 nốt nhạc ra ngay hướng dẫn cài đặt: https://docs.docker.com/engine/install/ và một Fedora contributor lâu năm thì chắc chắn phải cài thử lên con laptop chạy Fedora 34 rồi 🙂 (một số thử nghiệm sau này tớ cài thử lên cả CentOS 7 và Rocky Linux 8)

Sau khi thực hiện thiết đặt môi trường đầy đủ và chạy thử container đầu tiên “hello-world”, tớ bắt đầu mò mẫm tìm hiểu các khái niệm cơ bản thế nào là container, thế nào là image… và phát hiện ra thế giới Docker hub với rất nhiều image được cộng đồng đóng gói sẵn đưa lên các repo và share cho mọi người cùng sử dụng (các công ty cũng có thể lập các kho private, thậm chí lập nguyên 1 cái như Docker hub để đưa các image không public của mình lên). Trải nghiệm rất nhiều các món hot open source muốn dùng thử thì hầu như đều tìm thấy trên Docker hub hoặc public ở đâu đó; điều này quả thực nằm ngoài sức tưởng tượng của tớ trước đây; một cảm giác rất chi là “yomost”, từ giờ việc trải nghiệm một thứ hay ho mới trở nên đơn giản hơn bao giờ hết.

Sau một thời gian tìm hiểu, với bản tính tò mò và ham thích đóng góp trong các dự án nguồn mở đôi chục năm nay, tớ bắt đầu tự hỏi làm thế nào để tạo ra các Docker image như vậy và share cho cộng đồng. Trong các dự án phần mềm nguồn mở lâu nay vẫn làm việc cùng, tớ chọn Zimbra, dự án tớ và team iWay vẫn đang làm hàng ngày.

Zimbra hiện tại vẫn đang được đóng gói theo cách cũ (RPM, DEB packages) và đưa lên kho riêng maintained bởi công ty Synacor, chủ sở hữu thương hiệu Zimbra. Phiên bản Zimbra 9 open source mới nhất thậm chí còn không được cung cấp dưới dạng các gói đóng sẵn, người dùng muốn dùng phải tự compile/package từ source code (open source license). Đóng gói dưới dạng Docker image mới chỉ ở mức thử nghiệm và không được maintain/update thường xuyên.

Google trên Internet, cũng có một vài thành viên cộng đồng thực hiện đóng gói trên Docker, nhưng vì những lý do khác nhau cũng không thấy cập nhật. “Hoàn thiện” nhất có lẽ là kho của anh Jorge de la Cruz, một trong những thành viên tích cực nhất trong cộng đồng Zỉmbra, public tại https://github.com/jorgedlcruz/zimbra-docker/, đóng gói cho Zimbra 8.7 (rất cũ, hết support rồi) chạy trên Ubuntu 16.04 (cũng phát hành 5 năm rồi)

Hehe, vậy là có một đề bài hay đây rồi. Và cũng trong 1/2 nốt nhạc, tớ quyết định sẽ đóng gói Zimbra Docker image mới và chia sẻ với mọi người.

Đầu tiên, tớ thử tham gia vào kho mã nguồn của Jorge, tuy nhiên mọi thứ đã khá cũ và thực tế là không dùng được, tớ quay qua đọc README để tìm hiểu nguyên lý. Sau khi tìm hiểu sơ bộ, tớ quay qua đọc thêm tài liệu về build image của Docker và thấy mọi thứ cũng tương đối sáng sủa, dễ hiểu.

Lần mò tiếp, tớ thử áp dụng các kiến thức học được, cũng không khác nhiều so với viết file .spec để đóng gói các phần mềm phân phối dưới dạng RPM vẫn thường làm ở vai trò Feodora Packager gần chục năm, Dockerfile đầu tiên đã được viết xong và sẵn sàng build 🙂

Một phát hiện thú vị khác, một Docker image để hữu dụng cho mọi người, cần được đóng gói đầy đủ sao cho người dùng chỉ việc pull về và run một container ngay lập tức, với mọi tham số có thể được truyền vào với lệnh “docker run”, không cần phải can thiệp điều chỉnh gì thêm (hehe, chả biết đây có thể được gọi là “phát hiện” không, và liệu logic đó có hoàn toàn đúng trong đa số các trường hợp không, nhờ các chuyên gia Docker advice thêm!). Vừa may, trình cài đặt Zimbra hỗ trợ luôn phương án truyền các tham số vào; nếu truyền đủ tham số thì chỉ việc chạy 1 lệnh rồi đi lấy 1 tách cafe chờ cài đặt hoàn thành.

Rồi, và bây giờ là hành trình trải nghiệm của tớ: <3

  1. Tớ quyết định chọn đóng gói phiên bản Zỉmbra 9 mới nhất, gói được build & maintain trực tiếp từ open source code bởi Zextras, công ty có trụ sở ở Milan, Italy, một trong các thành viên đóng góp nhiều nhất vào dự án Zimbra open source và hiện là một trong các nhà cung cấp dịch vụ Zimbra hàng đầu trên thế giới (iWay tự hào là đối tác duy nhất của Zextras tại Việt Nam). Các bạn có thể tìm hiểu nhiều thông tin thú vị xung quanh bản đóng gói này tại đây.
  2. Việc chọn phiên bản Rocky Linux 8 làm nền tảng cho Zimbra 9 cũng là một sự tình cờ thú vị mang đậm chất nhân văn. Số là cách đây khoảng 6 tháng, sau 6-7 năm sáp nhập dự án CentOS về, Redhat đã công bố chiến lược phát triển CentOS mới, trong đó CentOS không còn là bản “clone” của RHEL (cứ có 1 bản RHEL mới là cộng đồng lại lấy mã nguồn compile/package một bản CentOS tương ứng, chỉ thay đổi phần thương hiệu, logo), mà trở một bản “pre-built” của RHEL (đóng gói & thử nghiệm trong CentOS trước, rồi mới đưa vào RHEL). Việc này dẫn đến một tách ra (fork) những dự án mới, và một trong các dự án đó được anh Gregory Kurtzer, một trong các founder của CentOS, khởi động ngay trong ngày Redhat có thông báo về “số phận” của CentOS, đặt tên là Rocky Linux. Dự án này được rất nhiều thành viên trong cộng đồng hưởng ứng (trong đó có tớ, đương nhiên, hehe) và trong một hời gian ngắn, số lượng contributor đã rất đông, cũng như được sự hậu thuẫn của những công ty lớn. Và như một sự tình cờ hữu duyên, phiên bản Rocky Linux 8 chính thức đầu tiên đóng gói thành Docker image và được push lên Docker hub vào đúng ngày tớ bắt đầu thử chơi với Docker build <3
  3. Docker file đầu tiên nhanh chóng được viết ra và sau vài vòng cải tiến đã cho ra Docker image đầu tiên, based trên Rocky Linux 8 Docker image, gói cùng Zimbra 9 download từ kho đóng gói của Zextras. Toàn bộ công việc được open source, đưa lên https://github.com/iwayvietnam/zimbra-docker, phát hành theo giấy phép GNU GPL v3. Docker image này chứa tất cả các phần mềm cần thiết để triển khai một máy chủ Zimbra 9 mới (dưới dạng single-server), với toàn bộ các tham số được truyền qua dòng lệnh “docker run” khi khởi tạo container, đúng phong cách “gõ lệnh, đi uống cafe và canh giờ quay lại” :);  tiến thêm 1 bước nữa, tớ push Zimbra image mới lên Docker hub tại địa chỉ https://hub.docker.com/r/iwayvietnam/zimbra_all và chia sẻ cho mọi người trong nhóm “Cộng đồng Zimbra Việt Nam” trên Facebook có thể pull về thử (thay vì phải tự build từ Dockerfile kia)

Docker image đầu tiên này được hoàn thành trong ~48h, mới là phiên bản “thô” đầu tiên, còn rất nhiều thứ cần cải tiến thêm như:

  1. Tách các dịch vụ (Mailboxd, MTA, Proxy, LDAP…) thành các gói riêng để có thể deploy độc lập trong môi trường multi-server Zimbra.
  2. Thêm các thành phần bổ sung tính năng ngoài như Z-Push hỗ trợ ActiveSync mobile, hoặc các thành phần hỗ trợ HA/Cluster, các thành phần hỗ trợ theo dõi, giám sát, hỗ trợ phân tích logs, backup, security…
  3. Thêm các thành phần để có thể tự động hóa hoàn toàn quá trình deploy 1 hệ thống mới…

Quá trình thử đóng gói Docker image đầu tiên cũng là dịp tuyệt vời cho tớ tìm hiểu nhiều ngóc ngách sau hơn về Docker: hiểu sâu hơn về Docker image vs. container, các tham số biến thể cho các lệnh Docker run, exec, stop/start, build, commit, pull/push…, các món xung quanh khác như docker-compose, docker-swarm, và đặc biệt mở ra một hướng học tập mới cho tớ trong thời gian tới: Kubernetes (hay còn gọi là K8S) <3

Còn rất nhiều thứ có thể học hỏi, nhiều việc phải làm… và nhiều đồ chơi để chơi cùng trong thời gian tới (đặc biệt là khi dịch Covid đang giữ bạn ở nhà, hehe). Hi vọng trải nghiệm này sẽ trở thành động lực cho tớ cũng như truyền năng thêm lượng, động lực cho các anh em say mê công nghệ, yêu thích Linux, Zimbra & open source tiếp tục không ngừng học hỏi và đóng góp cho cộng đồng open source ở Việt Nam nói riêng cũng như cộng đồng toàn thế giới.

Mong tiếp tục có nhiều dịp được chia sẻ & giao lưu với các anh em <3

Cảm ơn anh em đã đọc một bài rất dài, đến tận dòng cuối cùng này 😀

Số liệu thống kê về đồng-răn & đánh giá về các giải chạy?

Trong một buổi chiều phấn khích,

Tớ dự định thống kê số liệu thành tích của các đồng-răn tại các giải chạy đã diễn ra, và nếu có thể thì dự đoán xu hướng thành tích trong các giải chạy sắp tới, các bạn thấy sao?

Bạn có muốn xem đánh giá của các chuyên gia, những runner giàu kinh nghiệm, về các giải chạy sắp tới, giúp bạn lựa chọn giải chạy phù hợp?

Đặc biệt là khi dịch bệnh Covid sắp được khống chế (Việt Nam đã quyết định mua vaccine rồi nha, rồi cũng sắp có thuốc chữa Covid đặc hiệu nữa), các giải chạy sẽ thoải mái bung lụa, toàn cõi Việt Nam sẽ đón vài chục giải/năm, tần suất gần như hàng tuần, và có rất nhiều tuần sẽ trùng tới 2-3 giải.

Nếu bài này được ngàn like (đếm cả 1 share = 10 like), tớ sẽ bắt tay vào, hihi.

Các số liệu nổi bật về Email năm 2021

Những con số “biết nói” chứng tỏ sức sống của Email trong một xã hội công nghệ vẫn đang ngày một phát triển với rất nhiều lựa chọn liên lạc hiện đại: phone, chat, voice, video, mạng xã hội…

  • Có 3,9 tỷ người dùng email hàng ngày, con số này dự kiến ​​sẽ tăng lên 4,3 tỷ vào năm 2023 (Statista, 2020)
  • Tài khoản email đang hoạt động đã vượt 5,6 tỷ vào năm 2020 (Statista, 2020)
  • Số lượt mở bằng thiết bị di động chiếm 46% tổng số email được mở
  • 35% chuyên gia kinh doanh kiểm tra email trên thiết bị di động
  • 73% số người thuộc thế hệ Millennials (1981-1996) thích thông tin liên lạc từ các doanh nghiệp đến qua email
  • Các Marketers sử dụng chiến dịch có phân khúc ghi nhận doanh thu tăng 760%
  • 35% Marketers gửi cho khách hàng của họ 3-5 emails mỗi tuần
  • 78% các Marketers đã thấy sự gia tăng tương tác qua Email trong 12 tháng qua
  • 80% các chuyên gia kinh doanh tin rằng Marketing Email giúp tăng khả năng giữ chân khách hàng
  • 31% các marketer B2B nói rằng bản tin email là cách tốt nhất để nuôi dưỡng khách hàng tiềm năng (Content Marketing Institute, 2020)
  • 59% người được hỏi nói rằng Marketing Email ảnh hưởng đến quyết định mua hàng của họ

Phàn nàn của người dùng (Complaints)

Trong bài đầu tiên trong tuyến bài Email Deliverability, mô tả về Nguồn Gửi, địa chỉ IP và tên miền, tớ đã nhắc đến Phàn nàn (Complaints) như là một trong các chỉ số quan trọng bậc nhất, ảnh hưởng đến điểm tín nhiệm của nguồn gửi:

Email Deliverability part 1: IP và Domain

Khi nhận được thư không mong muốn vào inbox, người dùng sẽ thông báo “Đây là Spam”, những thông báo dạng này được gọi là Phàn nàn (complaints).

Có 3 cách để người nhận thư “phàn nàn”:

  • Nút “This is junk/spam”: người dùng nhấn nút Junk/Spam trên phần mềm email client.
  • Phàn nàn với quản trị hệ thống email: người dùng gửi thư phàn nàn về nguồn gửi tới nhóm quản trị hệ thống email của nhà cung cấp dịch vụ.
  • Phàn nàn với ứng dụng lọc spam: người dùng gửi phàn nàn tới ứng dụng lọc spam hoặc danh sách tự động chuyên tiếp nhận phàn nàn.

Chỉ với một tỷ lệ nhỏ phàn nàn của người dùng có thể ảnh hưởng lớn đến khả năng chuyển phát thư vào inbox. Vì vậy cần cố gắng giữ tỷ lệ phàn nàn dưới 0.1%.

Người dùng phàn nàn bởi nhiều nguyên nhân khác nhau. Hiểu được nguyên nhân sẽ giúp giảm tỷ lệ phàn nàn.

Một số lưu ý cụ thể:

  • Xem xét tất cả các nguồn thu thập địa chỉ thư xem liệu nguồn nào dẫn tới số lượng phàn nàn tăng cao bất thường. Xử lý làm sạch tập địa chỉ thu thập từ nguồn đó, thậm chí hủy hẳn nguồn thu thập gây ra vấn đề. Các danh sách mua ngoài, danh sách liên kết, form tự khởi tạo trên web… thường dễ là thủ phạm gây vấn đề.
  • Nếu người đăng ký không nhận ra thương hiệu hoặc nhớ ra đã từng đăng ký vào danh sách thư, có khả năng họ sẽ phàn nàn. Hãy gửi một thông điệp chào mừng đúng lúc, đúng chỗ, nhắc lại về thương hiệu và/hoặc các lợi ích từ chương trình.
  • Nội dung không liên quan hoặc không đáng quan tâm rất dễ nhận phàn nàn. Nên có công cụ tiếp nhận phản hồi của người nhận về những nội dung họ muốn/không muốn để cải thiện trong các chiến dịch gửi sau.
  • Cần đảm bảo link hủy đăng ký phải được nổi bật và dễ thực hiện. Người dùng thường chọn nút “Spam” nếu họ không biết hủy đăng ký thế nào.
  • Tham gia vào các FBL (feedback loop – sẽ được giải thích trong bài sau) để tiếp nhận lại các phàn nàn của người dùng từ nhà cung cấp dịch vụ phía đầu nhận và xử lý sớm.

Riêng chủ đề Phàn nàn (Complaints) có thể viết hẳn thành một tuyến bài riêng. Sau khi kết thúc loạt bài về Email Deliverability, nếu mọi người thấy nội dung có ích và đón nhận nhiệt tình, tớ sẽ bố trí thời gian viết tiếp, tập trung vào chủ đề Phàn nàn của người dùng và làm thế nào để kiểm soát chúng tốt nhất.

iWay và Zextras ký thỏa thuận hợp tác chiến lược

Từ nhiều năm nay, Zextras đã trở thành cái tên quen thuộc trong cộng đồng phát triển và người dùng Zimbra toàn thế giới. Công ty có trụ sở tại Milan, Italia, là một trong những nhà phát triển có đóng góp lớn nhất vào dự án nguồn mở Zimbra với bộ phần mềm nổi tiếng Zextras Suite, bao gồm rất nhiều các thành phần mở rộng, bổ sung các tính năng quan trọng vào phiên bản Zimbra Open Source edition. Nhiều tính năng trong số này sau đó đã được đưa vào trở thành một phần của phiên bản Zimbra Network edition.

Các tính năng chính trong bộ phần mềm Zextras Suite bao gồm:

  • Quản lý lưu trữ: hỗ trợ lưu trữ dữ liệu thư điện tử đồng thời trên nhiều thiết bị, với các công nghệ khác nhau: đĩa cứng nội bộ, SAN/NAS, Cloud…
  • Sao lưu và phục hồi theo thời gian thực.
  • Phân quyền cho Quản trị viên.
  • Video conf, Voice call và Chat (tương tự Google Meet).
  • Lưu trữ, chia sẻ và cùng soạn sửa tài liệu (tương tự Google Docs và Google Drives).
  • Hỗ trợ thiết bị di động, Outlook và Windows Mail theo giao thức chuẩn ActiveSync.
  • Dễ dàng cài đặt, cập nhật và quản trị: Zextras Suite được tích hợp hoàn hảo trong Zimbra, theo quy trình cài đặt tiêu chuẩn nhanh chóng và dễ dàng.
  • Tuân thủ GDPR (General Data Protection Regulation), bộ quy tắc về bảo vệ dữ liệu cá nhân do Châu Âu đề xướng.

Không lâu sau khi Synacor, công ty sở hữu thương hiệu Zimbra, ra thông báo chính thức về việc bắt đầu từ bản Zimbra 9, phần webmail với tên mới là ModernUI sẽ không được phát hành theo giấy phép nguồn mở và cũng không tiếp tục phát hành các bản đóng gói chính thức cho phiên bản Zimbra 9 Open Source, Zextras là công ty đứng ra nhận trách nhiệm biên dịch và đóng gói phiên bản Zimbra 9 Open Source, bởi lý do rất đơn giản, Zextras được sinh ra (bởi các founders) từ cộng đồng và luôn đặt sứ mệnh ưu tiên hỗ trợ cho cộng đồng lên hàng đầu.

Các bạn có thể tìm hiểu thêm về Zimbra 9 Open Source, unofficial builds, made by Zextras tại: https://www.zextras.com/zextras-build-based-on-zimbra-official-repository/ (bao gồm cả các thông tin quan trọng về tuân thủ giấy phép nguồn mở)

iWay là một trong những công ty đầu tiên tại Việt Nam tham gia trực tiếp đóng góp phát triển vào các dự án nguồn mở cùng cộng đồng thế giới, bao gồm các dự án rất lớn như Fedora Linux, Zimbra và nhiều dự án nguồn mở được chọn là nhân lõi cho Zimbra.

Với tầm nhìn trở thành nhà phát triển phần mềm nguồn mở đồng thời nhà cung cấp dịch vụ nguồn mở lớn nhất tại Việt Nam và trong khu vực, qua hơn 16 năm phát triển, iWay luôn là lá cờ đầu, tiên phong đóng góp phát triển các dự án nguồn mở theo đúng qui tắc tiêu chuẩn, cùng cộng đồng thế giới, được ghi nhận là một trong những nhà phát triển nguồn mở có nhiều đóng góp nhất trong khu vực Châu Á – Thái Bình Dương. Riêng trong dự án nguồn mở Zimbra, iWay đã tham gia đóng góp phát triển nhiều thành phần nhân lõi, cũng như thành phần mở rộng, và đặc biệt các đóng góp này đều được phát hành 100% theo giấy phép nguồn mở.

Tháng 11/2020, Zextras và iWay đã chính thức kỹ kết thỏa thuận chiến lược, cùng hợp tác phát triển dự án nguồn mở Zimbra, đồng thời iWay cũng trở thành nhà phân phối chính thức Zextras Suite tại Việt Nam: https://iwayvietnam.com/i-news.html

Nhân dịp Giáng Sinh và Năm Mới 2021, chúng tôi xin gửi lới chúc mừng tới toàn thể thành viên cộng đồng Zimbra và cộng đồng nguồn mở Việt Nam nói chung, và xin gửi tặng đến các bạn một món quà đặc biệt, Voucher giảm 20% Zextras Suite subscription, có giả trị đến hết ngày 31/1/2021.

Hãy liên hệ với chúng tôi. Điện thoại: +84(24)3527-8684 / Email: sales@iwayietnam.com.

Email Deliverability part 2: Chất lượng tập địa chỉ nhận

Trong bài trước, chúng ta đã phân tích yếu tố ảnh hưởng đầu tiên đến email deliverability: Nguồn Gửi.

Email Deliverability part 1: IP và Domain

Loạt bài tiếp theo đây, chúng ta sẽ phân tích các yếu tố ảnh hưởng tiếp theo: Chất lượng tập địa chỉ nhận.

Nguồn: ChooseWhat

Có 3 loại địa chỉ đặc biệt được nhà cung cấp dịch vụ mailbox xem xét: Địa chỉ không tồn tại (Unknown users), Bẫy spam (Spam traps) và Địa chỉ không hoạt động (Inactive users).

Địa chỉ không tồn tại (Unknown users)
Là địa chỉ chưa từng tồn tại, hoặc bị nhà cung cấp dịch vụ mailbox hay chính người dùng xóa khỏi hệ thống. Khi nhận email đến 1 địa chỉ không tồn tại, hệ thống email nhận sẽ trả về mã lỗi Hard-bounce 5xx có dạng:
550 <subscriber@acme.com> User unknown
550 <subscriber@acme.com> Mailbox does not exist
550 <subscriber@acme.com> Invalid recipient

Tỷ lệ unknown users / tổng số email trong 1 đơn vị thời gian cần được kiểm soát ở mức an toàn dưới 2%. Tỷ lệ trên 2% bắt đầu được coi là dấu hiệu nguồn gửi này là spammers. Tỷ lệ trên 10% thì hầu hết các hệ thống nhận email đều coi nguồn gửi này chắc chắn là Spammers.

Bẫy spam (Spam traps)
Là những hộp thư đặc biệt, được nhà cung cấp dịch vụ dành riêng để tiếp nhận email và phân tích khả năng nguồn gửi là spammers hay không.
Một email rơi vào bẫy spam nghĩa là nguồn gửi có vấn đề: 1/ lấy địa chỉ email từ nguồn xấu, hoặc 2/ địa chỉ nhận email không được dọn dẹp thường xuyên. Kể từ thời điểm này, địa chỉ IP, tên miền của nguồn gửi hoặc mẫu nội dung thư có thể bị liệt vào danh sách chặn tạm thời, hoặc vĩnh viễn. Loại và tuổi của bẫy spam là những yếu tố ảnh hưởng đến mức độ quyết định ngăn chặn.

Có 2 loại bẫy spam:

  • Bẫy spam tái sử dụng (Recycled): địa chỉ từng thuộc về một người thật, nhưng đã được chuyển thành bẫy spam sau khi người dùng dừng sử dụng. Bẫy spam loại này thường chỉ ra là tập địa chỉ nhận email không được dọn dẹp thường xuyên.
  • Hũ mật (Honey pot): địa chỉ được lập ra với mục đích rõ ràng từ đầu nhằm chặn bắt các nguồn gửi xấu. Nhiều nhà cung cấp dịch vụ bẫy spam để địa chỉ “hũ mật” lên website hoặc các diễn đàn, trang mạng khác, ẩn so với người dùng, nhưng lại dễ dàng đọc bởi các robot chuyên đi thu thập địa chỉ email. Nguồn gửi tới các địa chỉ “hũ mật” này ngay lập tức bị đánh giá là spammer.

Các lưu ý cụ thể duy trì chất lượng tập địa chỉ nhận:

  • Cách li riêng các tập dữ liệu mới: chỉ gửi thư chào hỏi, nếu không nhận lại mã lỗi 5xx mới đưa vào tập địa chỉ chính thức.
  • Cung cấp lựa chọn cập nhật địa chỉ tiện lợi: mọi người thường thỉnh thoảng thay đổi địa chỉ email và mong muốn cập nhật thông tin liên hệ nếu được cung cấp công cụ tiện lợi.
  • Xác nhận khi đăng ký: khi người dùng đăng ký, cần gửi thư xác nhận, thường đơn giản là click vào 1 đường dẫn tạo sẵn.
  • Cẩn thận lựa chọn tập địa chỉ: thường xuyên kiểm tra tập địa chỉ được cung cấp bởi bên thứ 3, để ra các quyết định sử dụng hay loại bỏ một nhóm hoặc cả tập địa chỉ.
  • Gửi email thường xuyên: về nguyên tắc, càng ít gửi email, nguy cơ email bị trả lại (bounce), hay thậm chí bị gửi vào bẫy spam (dạng “tái sử dụng”) càng cao. Dĩ nhiên, tần suất ở đây phải hiểu là tần suất gửi thực tế hàng ngày, hàng tuần…, không phải kiểu bắn email hàng loạt, lặp đi lặp lại đến 1 tập địa chỉ.
  • Theo dõi hành vi của người nhận: như một luật bất thành văn, địa chỉ nhận không hoạt động hoặc không có phản hồi gì hơn 1 năm cần được loại bỏ khỏi tập địa chỉ. Quãng thời gian có thể là 6 tháng hoặc 3 tháng nếu tần suất gửi khá thường xuyên.
  • Dọn dẹp tập địa chỉ: thường xuyên dọn dẹp các địa chỉ dạng chức danh (role) như sales@domain.com, địa chỉ dạng thử nghiệm như test@domain.com hoặc địa chỉ lỗi như jane@gmal.com.

Địa chỉ không hoạt động (Inactive users)

Địa chỉ không hoạt động đại diện chi những người không mở, click, hoặc thực hiện bất cứ hành động gì trên email nhận được trong một khoảng thới gian xác định. Nhiều tập địa chỉ chứa đến 80% là địa chỉ không hoạt động.

Địa chỉ không hoạt động tồn tại bởi nhiều nguyên nhân. Chúng không tác động trực tiếp đến chất lượng Tập địa chỉ và Khả năng nguồn gửi bị đánh giá spam như Địa chỉ không tồn tại (Unknown users) hoặc Bẫy spam (Spam traps), nhưng chúng làm giảm tỷ lệ phản hồi của cả chiến dịch/chương trình, và gián tiếp ảnh hưởng xấu đến điểm tín nhiệm nói chung. Vì vậy, cách tốt nhất là kiểm soát các địa chỉ không hoạt động trong trên phần mềm gửi thư qua từng chiến dịch/chương trình.

Một số lưu ý cụ thể:

  • Sử dụng chức năng của phần mềm gửi thư theo dõi dữ liệu về phản hồi của người dùng qua từng chiến dịch/chương trình.
  • Theo dõi, thống kê số lượng mở, click và bị trả lại (bounce). Đặc biệt lưu ý khi tỷ lệ mở, click giảm, hoặc khi tỷ lệ bị trả lại tăng bất thường. Dùng chính dữ liệu này làm các mốc xác định Địa chỉ không hoạt động hay Hoạt động, sau đó chủ động thiết đặt giảm tần suất gửi thư tới các địa chỉ không hoạt động.
  • Kiểm soát nguồn cung cấp các địa chỉ không hoạt động (từ website, từ đối tác, từ giới thiệu…) xác định mẫu số chung phát sinh các địa chỉ không hoạt động của từng nguồn để phòng tránh, giảm bớt tập địa chỉ loại này.

Thực hành tốt các lưu ý trong bài viết này để kiểm soát tốt cả 3 loại địa chỉ đặc biệt: Địa chỉ không tồn tại (Unknown users), Bẫy spam (Spam traps) và Địa chỉ không hoạt động (Inactive users) sẽ giúp nâng cao chất lượng tập địa chỉ nhận, qua đó kiểm soát tốt nhất điểm tín nhiệm cho nguồn gửi (sender reputation), đảm bảo email deliverability luôn ở mức cao nhất.

Email Deliverability part 1: IP và Domain

Như đã hẹn, sau đợt hỗ trợ đồng bào miền Trung tạm ổn, tớ bắt đầu quay lại với series bài viết về Email Deliverability.

Email Deliverability là khả năng hệ thống deliver email tới được Inbox người nhận, giống như kiểu anh shipper chuyển được hàng đến tận tay bạn.

Đây là bài đầu tiên trong tuyến bài, nói về một trong các thành phần cơ bản nhất, và cũng là thành phần quan trọng nhất: Nguồn Gửi.

Mời mọi người đọc & comment & trao đổi thêm.

Nguồn: BigMailer

Một trong các thông tin quan trọng nhất được công cụ Spam filter phía đầu hệ thống email người nhận dùng để đánh giá một email có phải là spam hay không là nguồn gửi, được cấu thành bởi 2 thành tố: địa chỉ IP và tên miền.

Về địa chỉ IP:

  • Hệ thống email đầu nhận kiểm tra điểm tín nhiệm (reputation) của địa chỉ IP dùng để kết nối, chuyển phát thư tới (Sender IP) theo một số thuật toán tương đối phức tạp, kết hợp nhiều tham số khác nhau để tính toán ra một chỉ số chung gọi là SenderScore có điểm số từ 0-100; một số hệ thống sử dụng các thuật toán khác tính toán ra chỉ số SenderBase có giá trị từ -10 đến +10. Một số tham số chính có thể kể đến:
    • Complaints: số lượng thông báo “đây là spam” của người dùng (chỉ số quan trọng nhất – nên cần tìm cách giảm thiểu complaints của người dùng)
    • Spam Traps: một loại dịch vụ đặc biệt của các nhà cung cấp dịch vụ Internet, chuyên bẫy các loại Spam khác nhau.
    • Message Composition: cách thức thu thập/trộn thông tin tạo ra nội dung thư gửi đi.
    • Volume: số lượng thư gửi đi theo đơn vị thời gian.
    • Blacklists: một loại dịch vụ đặc biệt của các nhà cung cấp dịch vụ Internet chuyên kiểm tra, theo dõi và liệt kê các địa chỉ IP gửi spam (cố tình hoặc có lỗi vô ý) vào danh sách đen.
  • Một số lưu ý cụ thể:
    • Địa chỉ IP cho chuyển phát thư số lượng lớn nên dùng riêng, tránh chia sẻ với các dịch vụ khác. Mỗi địa chỉ IP cần được thiết đặt bản ghi ánh xạ ngược PTR.
    • Các tham số ảnh hưởng chính đến IP reputation như nêu ở trên cần được kiểm soát thường xuyên, đảm bảo luôn trong ngưỡng giá trị cho phép. VD: Volume nên giữ tương đối cân bằng, không nên tăng đột ngột trong một khoảng thời gian ngắn.
    • Tránh thay đổi địa chỉ IP, trừ trường hợp bất khả kháng. Trường hợp thêm địa chỉ IP mới vào hệ thống chuyển phát thư số lượng lớn, cần thêm vào các hàng đợi phụ, được kiểm soát tốc độ chuyển phát thư, trước khi đưa vào các hàng đợi tốc độ nhanh hơn và cuối cùng vào hàng đợi chính. Hệ thống email phía đầu nhận gọi kỹ thuật này là “email throttling”, chuyên dùng để loại trừ các địa chỉ IP mới, thường được các spammer dùng để phát tán spam.

Về tên miền:

  • Tên miền được đăng ký trên hệ thống DNS toàn cầu, và trong phạm vi, ngữ cảnh về email, thường gắn liền với kỹ thuật “ký tên miền” (signing domain) được sử dụng trong giao thức xác thực tên miền như SPF, DKIM…
  • Điểm tín nhiệm của tên miền (Domain Reputation) được tính toán từ các tham số chính sau:
    • Spam folder placement rate: số email từ tên miền này bị đưa vào Spam folder sau khi Spam filter đánh giá IP reputation và nội dung thư.
    • Inbox placement rate: số email từ tên miền này vào Inbox.
    • Complaint rate: số email từ tên miền này bị người dùng đánh dấu là Spam.
    • “This is not spam” rate: số email từ tên miền này bị đưa vào thư mục Spam (nhóm 1) hoặc từng bị đánh dấu spam (nhóm 3), nhưng sau đó lại được người dùng đánh dấu là Not Spam.
  • Một số lưu ý cụ thể:
    • Cần thiết đặt các bản ghi DNS chuyên dùng cho các giao thức xác thực tên miền như SPF, DKIM, DMARC. Hầu hết các hệ thống email phía đầu nhận đều kiểm tra xác thực xem liệu email nhận được có thực sự được gửi từ tên miền này không. Việc thiết đặt này còn tăng cường điểm tín nhiệm cho tên miền và rộng hơn là thương hiệu của doanh nghiệp, đảm bảo những nguồn gửi không được xác thực sẽ bị Spam filter phía đầu nhận chặn lại.
    • Một số bản ghi DNS cần được thiết đặt bao gồm:

Các thành tố cấu thành nguồn gửi (địa chỉ IP và tên miền) cần được thường xuyên kiểm soát theo thời gian thực, đảm bảo luôn duy trì điểm tín nhiệm tốt nhất. Một sai sót nhỏ có thể dẫn đến ảnh hưởng rất lớn đến khả năng chuyển phát của cả hệ thống.

Ngoài nguồn gửi, còn nhiều yếu tố khác ảnh hưởng đến khả năng thư được deliver tới Inbox người nhận (email deliverability). Tuy nhiên hầu hết các yếu tố đó nằm ngoài phạm vi của hệ thống chuyển phát thư số lượng lớn nên sẽ cần được xem xét riêng.

FAD APAC KL 2016

FAD APAC for budget planning has been happened during two days 9th-10th of July in Kuala Lumpur with a lot of exciting discusions (something really hot 😉

Day 0:

My flight was booked lately so I have to transit in HCMC (the direct flight fare from Hanoi to KL was increased so much) and I came to KLIA a bit late. After a almost 2 hours to pass through Immigration gate, I decided to take a taxi to the hotel. It was a bit late so I did not want to look for routes on the map (I also had not got Internet connection on my phone). Finally, I met Zsun, Prima and other participants at the hotel!

Day 1:

Day 1 started with our discussions about current issues in each APAC country.

The most important for me is leadership status in APAC region. I have worked as the only APAC regional leader for years. Sometimes, due by the day life, I could not respond in time to everything as others expected. Especially, since I decided to jump into another big new open source project, OpenCPS, a half year ago, my spare time have been less. That’s why I really liked to delegate APAC leadership to a group of active Fedora contributors in APAC, the ones attended three last APAC FADs for budget planning. I am still here to support everyone. However, I would like others to be more active to take the leadership to push APAC region toward.

The next interesting topic we discussed in the morning is how to do more activities within APAC, while keep the region connected to the world. We discussed the idea of running bi-annual FUDCons (proposed by gnokii). The ideas behind this is to save a half of money for running FUDCon every other year ($15k per year, at this moment) for supporting APAC people to attend Flock every year ($7.5k per year). Annual FAD can be organized as a separated event in a year and mixed to FUDCon another year. Some travel subsidy could be saved for other useful activities/events (or added to Flock support for APAC people – raised to ~$9k per year).

During the first day, we did review the whole APAC FY2017 budget to cut it down to the final allocated budget, $11,500. After a lot of adjustments, it was cut down to $12,200 ($700 difference). The updated budget table could be found on the wiki here with about $3k left for media and $4,200 left for events/activities in APAC budget until the end of FY2017.

Day 2:

During the day 2, we discussed about FY2018 budget for media, swag, events and activities.

Some of important fixed items were listed as below:

  • Swags ($1,000), DVD ($1,500), Release parties ($1,000) for 2 releases: $3,500 * 2 releases = $7,000
  • FAD for budget planning: $5,000
  • SEA translation sprints (for approx 10 teams): $3,000
  • SFD 2017: $1,000
  • Some events in India: $1,000
  • Some events impact to the whole region:
    • Hong Kong Open Source
    • Barcamp Bangkok
    • Barcamp Yangoon
    • COSCup
  • Then fianally, we decided to support COSCup with $4,000 to send gnokii there to re-connect Fedora community in China, Hongkong and Taiwan.
  • Total requested funds: $20,000

The whole budget table could be found here: https://fedoraproject.org/wiki/FAD_KualaLumpur_2016/APAC/Budget:2017-2018 not has been really updated (someone will surely upload our final spreadsheet onto that page).

We also have a lot of discussion about how to grow up the APAC community. Some of them are really hot 😉 but most of them are quite effective for the whole region.

The FAD was ended at about 3:00 PM for sending some people (include me) to the airport to catch the late flights back to our cities for a coming work week.

Thank you all for attending and continuously contributing to Fedora. Especially thanks Izhar for hosting us, for welcoming us to our home with that really nice local dinner.

See you all everywhere 🙂

Nha Trang ICT 2015

I came to Nha Trang this year to bring Fedora back there after the successful event last year. This year, the event was held in another university in Nha Trang, TCU with more participants from other universities in Nha Trang and nearby cities.

There was a academy/science conference in the morning with some talks from open source enterprises who sponsor the whole event. The afternoon was reserved for FOSS communities and I had a session to introduce about the Fedora project to all students and lectures. There were about 200 attendees join into a big classroom.

During the session, I talked to them about the benefit of contributing to FOSS and Fedora. I told participants what the employers need in general when they recruit new employees, especially young students. Basically, they need candidates to have critical thinking, group working, English speaking and technical skills. Students can study those skills during participating in a FOSS project like Fedora.

I also had got a table to put some Feodra 23 DVD and small pins there. People were really interested in those gifts and grabbed them all in less than half an hour. People asked a lot of questions about Fedora and FOSS and I tried my best to answer most of them.

The last session in the afternoon was for Q&A. I was appointed to answer most community-related questions.

Hope students and lectures in the university and nearby would be more interested in Fedora and FOSS after this event.

See some more pictures here.