Category Archives: Weekly Tips

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.

goedkope energie

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.

Vấn đề đăng nhập vào Zimbra webmail với Firefox mới

Vừa upgrade lên Firefox 37 sau một thời gian dài sử dụng Firefox 33, tôi gặp ngay vấn đề không thể đăng nhập vào Zimbra (8.6) webmail. Thử truy cập phiên bản HTML thấy vào được bình thường, như vậy lỗi xảy ra với thiết đặt nào đó khiến AjaxPackage không load lên được.

Lần ngược về các thay đổi chính trong Firefox phiên bản mới, một điểm quan trọng tôi thấy là từ phiên bản Firefox mới thay đổi cách thức thiết đặt tham số, trong đó có một tham số quan trọng, dom.indexedDB.enabled, theo hướng dẫn của Mozilla, là một browser API dành cho client-side storage. Điều đáng nói là sau khi nâng cấp, tham số này trên Firefox của tôi được đặt là false; đổi lại thành true (xem hình dưới), mọi thứ hoạt động ngay tắp lự 🙂

firefox-37-zimbra

Các bước thực hiện:

  1. Nhập địa chỉ “about:config” để mở phần thiết lập tham số cho Firefox
  2. Search từ “indexedDB”
  3. Double click vào “dom.indexedDB.enabled” để đổi từ false thành true

Chúc các bạn may mắn 🙂

Nghiên cứu PMNM trong hệ thống Thư điện tử và Cộng tác: Quan điểm về An toàn và An ninh thông tin ở Mỹ và châu Âu

A Ponemon Institute Study – November 2014

Hơn 70% các chuyên gia IT Mỹ ưu tiên lựa chọn phần mềm nguồn mở (PMNM) bởi tính liên lục và khả năng kiểm soát.

Tiết kiệm chi phí không còn là chỉ số vàng duy nhất cho PMNM.

Viện Ponemon đã khảo sát 1,398 chuyên gia IT để xây dựng báo cáo “Nghiên cứu PMNM trong hệ thống Thư điện tử và Cộng tác: Quan điểm về An toàn và An ninh thông tin ở Mỹ và châu Âu” với mục tiêu tìm hiểu mức độ sử dụng các giải pháp thư điện tử và cộng tác nguồn mở trong các công ty và quan điểm của họ về an toàn và bảo vệ thông tin riêng tư.

Một số kết quả chính:

  • Phần mềm nguồn mở thương mại vượt trội so với phần mềm sở hữu độc quyền về tính liên tục, khả năng kiểm soát, chất lượng và giá thành – 66% các chuyên gia IT ở Mỹ đồng ý rằng PMNM thương mại ít lỗi hơn.
  • Đội ngũ nhân viên làm tăng các rủi ro về an toàn và an ninh thông tin – 89% nhân viên không tuân thủ các qui tắc của công ty khi chia sẻ tài liệu mật.
  • Sự không hài lòng với phần mềm sở hữu độc quyền của các chuyên gia IT là cơ hội cho PMNM – 55% chuyên gia IT tại Mỹ lên kế hoạch thay thế hệ thống thư điện tử và cộng tác trong vòng 2 năm tới.

Còn tổ chức của bạn thế nào? Tải về toàn bộ báo cáo miễn phí tại đây.

Tại sao ra quyết định đồng thuận tốt hơn cho các dự án PMTDNM

Nhiều người trong chúng ta sử dụng mô hình ra quyết định đồng thuận (Consensus-based decision making) trong các dự án PMTDNM như Apache’s lazy consensus model, nhưng phần lớn chúng ta thực hiện hay thậm chí đặt thành qui định cuối cùng theo qui trình biểu quyết theo đa số (Majority-based decision making).

Trong mô hình biểu quyết theo đa số, những người bất đồng quan điểm bị gạt sang một bên — nhóm đa số buộc phải đặt nhóm bất đồng thiểu số vào vị trí những kẻ thua trong cuộc biểu quyết. Trong mô hình ra quyết định đồng thuận, trách nhiệm của cả nhóm là luôn lưu tâm đến các mối lo ngại của những người bất đồng quan điểm.

Nhìn chung, các quyết định đồng thuận bắt buộc nhóm phải tập trung dàn xếp một giải pháp tốt nhất có thể. Khi mọi người bị đặt vào vị trí thắng/thua, họ có xu hướng suy nghĩ cứng nhắc vào một hoặc hai đầu, thứ mà chưa chắc đã đại điện cho giải pháp tốt nhất có thể (rất có thể nằm đâu đó ở giữa).

Thông thường, để đạt được sự đồng thuận, chỉ cần làm rõ một số ý hiểu nhầm hoặc thực hiện một số điều chỉnh nhỏ so với đề xuất ban đầu. Tuy nhiên, sự xuất hiện phiếu trắng (-0) , kể cả khi không có phiếu chống (-1) nào, cũng cho thấy, đề xuất ban đầu nên được suy nghĩ thêm. Phiếu trắng từ những người lãnh đạo nhóm càng khuyến khích những người khác cân nhắc khả năng cần phải bổ sung thêm để đề xuất nhận được sự ủng hộ hoàn toàn.

Hiện tại, những dự án, cộng đồng PMTDNM lớn như CentOS, Fedora đã và đang áp dụng mô hình ra quyết định đồng thuận này.

Setup Email on smartphones, tablets to connect to Zimbra

Vậy là ActiveSync support đã được cài đặt lên Zỉmba server. Giờ là lúc cấu hình ActiveSync trên smartphones, tables của bạn để đồng bộ thư, lịch, địa chỉ… về thiết bị.

Trong khuôn khổ bài viết này, tôi chỉ giới thiệu cách cấu hình với Andoid (đã tested trên Google Nexus 7 và LG Optimus LTE SU640). Trình tự các bước như sau:

  1. Tại màn hình Set up email
    • Nhập account email address và password, rồi chọn Manual setup
  2. Tại màn hình Add email account
    • Chọn Microsoft Exchange ActiveSync (Z-Push đã giả lập), rồi chọn Next
  3. Tại màn hình Exchange server settings
    • Nhập server hostname
    • Bỏ chọn Use secure connection (SSL) nếu Z-Push không được cấu hình SSL
    • Chọn Accept all SSL certificates nếu Z-Push được cấu hình SSL bằng certificates tự sinh (không phải cung cấp bởi nhà cung cấp chứng thư trên Internet như VeriSign)
    • Chọn Next, thiết bị của bạn sẽ kết nối tới máy chủ; nếu thành công màn hình Account options sẽ hiện ra.
  4. Tại màn hình Account options
    • Chọn các option như bạn muốn là xong.

Bạn có thể thử nghiệm với thiết bị của bạn tương tự, kế cả các thiết bị BlackBerry, iOS… Mọi đóng góp đều sẽ được ghi nhận.

Again, special thanks to Z-Push team for your hard working.

Setup Z-Push with Zimbra to synchronize Emails, Calendar and Contacts with Mobile devices

Hey, cuối cùng thì vấn đề sync Emails, Calendar, Contacts từ hộp thư Zimbra (Open Source Edition) với Mobile devices đã được giải quyết ổn thỏa với Z-Push :).  Giải pháp đã được tested với chiếc tablet Google Nexus 7 và chiếc smartphone LG Optimus LTE SU640 (đều đã nâng cấp lên chạy CyanogenMod 10.1 ~tương đương với Android 4.2.2) của tôi.

Máy chủ Zimbra 8 đang hoạt động trên CentOS Linux 6. Việc cài đặt Z-Push cũng khá đơn giản, theo các bước:

  1. Enable RPMFusion (nếu bạn chưa từng thử món này thì quả thực là hơi tiếc cho công sức theo đuổi các dòng RPM-based Linux như Fedora, Red Hat, CentOS, etc 🙂 ) theo hướng dẫn http://rpmfusion.org/Configuration
  2. Cài đặt Z-Push bằng YUM:
    yum install z-push
  3. Cấu hình Z-Push trong file /etc/z-push/config.php, lưu ý mấy tham số sau:
    // Update existing fields in config
    define('TIMEZONE', 'Asia/Ho_Chi_Minh');
    define('PROVISIONING', false);
    $BACKEND_PROVIDER = "BackendZimbra";
  4. Tải Z-Push Zimbra backend về bằng SVN:
    svn checkout svn://svn.code.sf.net/p/zimbrabackend/code/zimbra-backend/branches/z-push-2 /usr/share/z-push/backend/zimbra
  5. Cấu hình Z-Push Zimbra backend trong file /usr/share/z-push/backend/zimbra/config.php, lưu ý mấy tham số sau:
    define('ZIMBRA_URL', 'https://mail.domain.com');
    define('ZIMBRA_USER_DIR', 'zimbra');
    define('ZIMBRA_SYNC_CONTACT_PICTURES', true);
    define('ZIMBRA_VIRTUAL_CONTACTS',true);
    define('ZIMBRA_VIRTUAL_APPOINTMENTS',true);
    define('ZIMBRA_VIRTUAL_TASKS',true);
    define('ZIMBRA_IGNORE_EMAILED_CONTACTS',true);
    define('ZIMBRA_HTML',true);
    define('ZIMBRA_ENFORCE_VALID_EMAIL', true);
    define('ZIMBRA_SMART_FOLDERS',false);
    define('ZIMBRA_RETRIES_ON_HOST_CONNECT_ERROR',5);
    define('ZIMBRA_LOCAL_CACHE', true);
    define('ZIMBRA_DEBUG',false);
  6. Khởi động lại Web server và thử truy cập vào địa chỉ http://<your-mail-server>/Microsoft-Server-ActiveSync
    Hệ thống sẽ hiện hộp thoại nhập username/password; nhập đúng tài khoản truy cập hộp thư Zimbra của bạn sẽ vào trang web thông tin về Z-Push
  7. Cài đặt tài khoản Email sync trên Mobile devices của bạn (ở đây tôi đang dùng thiết bị chạy Android) khai báo đang kết nối tới Exchange Server (Z-Push giả lập) không sử dụng SSL; nhớ bỏ chọn Sync SMS vì Zimbra không hỗ trợ lưu thông tin này.
  8. Và… a-lê-hấp… Email, Calendar, Contacts từ hộp thư Zimbra của bạn sẽ được Sync về tablet, smartphone.

Thanks Z-Push and all other Open Source communities. Your work is so great!

P.S. To: iWayers: Zimbra server của chúng ta đã cài Z-Push! Còn chờ gì nữa mà không sync thư về smartphone của các bạn đi 🙂

Giới thiệu hệ thống thư điện tử thế hệ mới Zimbra 8

Zimbra, hệ thống thư điện tử thế hệ mới, được xây dựng bởi cộng đồng PMTDNM và công ty VMWare, đáp ứng các nhu cầu về trao đổi thư tín điện tử và hỗ trợ làm việc cộng tác kỷ nguyên hậu PC, phiên bản mới nhất 8.0 vừa chính thức ra mắt. Zimbra 8.0 đơn giản hóa việc liên lạc, tăng cường khả năng quản trị trên đám mây công cộng cũng như đám mây riêng, tiện dụng hơn cho người dùng thư điện tử, sổ địa chỉ và lịch. Zimbra 8.0 tiếp nối phiên bản 7.2 thể hiện cam kết của cộng đồng Zimbra và công ty VMWare với thị trường phần mềm hỗ trợ làm việc cộng tác (collaboration). Bạn có thể thấy ba cải tiến quan trọng trong Zimbra, bao gồm:

Đơn giản hóa việc liên lạc

Zimbra 8.0 giới thiệu khả năng tích hợp với các giải pháp Liên lạc thống nhất (Unified Communications) của các hãng lớn như Cisco, Mitel… cho phép người dùng có thể tiếp tục sử dụng các giải pháp Liên lạc thống nhất với các tính năng tiện dụng như Click2Call, thư thoại, thể hiện trạng thái, và chat ngay trong Zimbra’s web client. Người dùng có thể dễ dàng tích hợp các giải pháp Liên lạc thống nhất sẵn có của Cisco hoặc Mitel; cũng như tận dụng tính ưu việt trong kiến trúc mở của Zimbra để xây dựng và tùy biến hệ thống Liên lạc thống nhất tích hợp với bất kỳ nhà cùng cấp giải pháp nào họ chọn.

Các tính năng tích hợp hệ thống Liên lạc thống nhất mới trong Zimbra 8.0 bao gồm:

  • Module tích hợp với các giải pháp Liên lạc thống nhất của Cisco và Mitel
  • Thể hiện trạng thái và nhấn để chat khi di chuột trên thẻ liên lạc hoặc địa chỉ bất kỳ bao gồm cả Cisco Jabber
  • Nhấn-để-Gọi (Click-to-Call) số điện thoại bất kỳ bằng cách điều hướng cuộc gọi tới thiết bị hoặc phần mềm thoại (soft phone)
  • Thư thoại trực quan cho phép nghe lại trực tiếp, quản lý và cập nhật trạng thái thể hiện
  • Lịch sử cuộc gọi cho các cuộc gọi đi, đến, cuộc gọi nhỡ
  • Bộ phát triển phần mềm (SDK) cho phép mở rộng hoặc tích hợp với các giải pháp Liên lạc thống nhất của các hãng thứ 3
  • Tích hợp Cisco WebEx cho các cuộc hẹn

Quản trị IT như dịch vụ trong kỷ nguyên Điện toán đám mây

Mang tới các tính năng phù hợp với yêu cầu trong doanh nghiệp luôn là một thách thức cho mọi bộ phận IT. Các công năng của điện toán đám mây nhằm đơn giản hóa việc quản trị các dịch vụ chủ chốt buộc phải được cân bằng giữa bảo mật, kiểm soát hệ thống và quản trị dữ liệu. Zimbra 8.0 giới thiệu tới người dùng một hệ thống đa máy chủ được xây dựng hướng tới việc mở rộng trong khi vẫn giữ được khả năng triển khai và bảo trì dễ dàng. Với máy chủ đóng gói sẵn phần mềm, người dùng có thể dễ dàng đưa hệ thống thư điện tử vào hoạt động chỉ trong vòng 10 phút, tối giản thời gian tạm dừng dịch vụ trong khi thực hiện nang cấp và bảo trì.

Zimbra 8.0 giới thiệu giao diện quản trị mới giúp người quản trị kiểm soát hệ thống dễ dàng hơn bao giờ hết. Giao diện quản trị trên trình duyệt mang tới người quản trị hệ thống thư một công cụ đơn giản nhưng không kém phần mạnh mẽ để kiểm soát hệ thống giống như mọi ứng dụng đám mây khác, không phụ thuộc vào việc hệ thống đang chạy trên đám mây riêng hay với một nhà cung cấp dịch vụ công cộng.

Zimbra 8.0 cũng bao gồm một tập các tính năng tự phục vụ cho người dùng cuối, tối giản đòi hỏi vào tài nguyên IT. Giờ đây, người dùng cuối có thể thực hiện các tác vụ như tạo nhóm thư trong web client, tìm kiếm và khôi phục các mục đã bị xóa trong cả Thư, Lịch, Địa chỉ, Nhiệm vụ tuân thủ các qui tắc về lưu trữ, khôi phục được định nghĩa sẵn bởi bộ phận IT.

Kết nối tới Đám mây cá nhân

Giao diện người dùng thoáng

Với người dùng cuối, kỷ nguyên Hậu PC có nghĩa là không bao giờ còn bị khóa trói vào một thiết bị đơn lẻ. Zimbra 8.0 giới thiệu một Hộp thư trên trình duyệt thông minh hơn, tập trung vào tính sạch thoáng, “ít để thể hiện nhiều” cho phép người dùng truy cập và quản lý thư điện tử và các thông tin khác.

Tìm kiếm nâng cao

Một điểm mới trong Zimbra 8.0 là chức năng tìm kiếm nâng cao cho phép giảm thiểu sự cần thiết phải tổ chức thư điện tử theo thư mục và nhãn của người dùng. Bằng cách trình bày nhiều hơn các tùy chọn tìm kiếm, người dùng có thể tìm thấy các thư điện tử cần thiết nhanh hơn, giảm thiểu thời gian tổ chức thư vào các thư mục hoặc đánh nhãn.

Tính năng quản lý lịch cũng được cải tiến đáng kể cho phép người chuyên dùng lịch có thể truy cập tới các chi tiết rất nhỏ giúp cho các công việc như sắp xếp lịch cho một nhóm lớn trở nên dễ dàng hơn. Với những người dùng lịch thông thường, Zimbra 8.0 tăng cường khả năng tích hợp với các ứng dụng lịch cá nhân như Google Calendar, mang tới một vùng nhìn toàn bộ về lịch công việc cũng như lịch cá nhân.

Lợi ích của việc vận hành một hệ thống ứng dụng thư điện tử và hỗ trợ làm việc cộng tác là rất rõ ràng. Tuy nhiên, không phải tổ chức nào cũng ở cùng thang bậc trên con đường đến với điện toán đám mây. Zimbra 8 cho phép các tổ chức triển khai hệ thống hệ thống ứng dụng thư điện tử và hỗ trợ làm việc cộng tác sẵn sàng công nghệ đám mây, mang tới cho người dùng những lợi ích của các ứng dụng đám mây – truy cập bằng trình duyệt và các thiết bị di động – và quản trị IT tiên tiến không phụ thuộc vào nơi vận hành Zimbra. Zimbra giúp quản trị viên IT một cách thức bảo mật và dễ dàng để triển khai một dịch vụ đám mây trong doanh nghiệp phục vụ nhu cầu về thư điện tử và làm việc cộng tác của người dùng cuối với bất cứ thiết bị hay nền tảng nào, trên hệ thống truyền thống, trên đám mây riêng của doanh nghiệp hay trên các đám mây công cộng.

Xem thêm về các tính năng mới trong Zimbra 8.0 và tải phần mềm về tại: http://www.zimbra.com/products/whats_new.html

HDD Sizing for a Zimbra system

Đây là một bảng ví dụ tính lượng đĩa cứng cần thiết cho một hệ thống Zimbra Mail
(Dựa trên giả định hệ thống có 1,000 người dùng, mỗi người dùng khoảng 500MB)

  • Dữ liệu người dùng: 1,000 users with 500 MB = 500 GB
  • Dữ liệu MySQL: 5% * 500 GB (dữ liệu người dùng): 25 GB
  • Chương trình chạy Zimbra: 10 GB
  • Zimbra logs: 50 GB
  • Zimbra indexes: 25% * 500GB (dữ liệu người dùng) = 125 GB
  • Tổng sử dụng: 500 + 25 + 10 + 50 + 125 = 710 GB
  • Sao lưu: 160 % of Tổng sử dụng: 710 * 160% = 1,136 GB
  • TỔNG CỘNG: 710 + 1,136 = 1,846 GB ~2TB
css.php