Hướng dẫn cấu hình email thông báo từ website
Phân biệt email nhận thông báo và tài khoản gửi SMTP; giải thích tham số của form liên hệ và luồng lưu liên hệ động trong CMS.
Tính năng này dùng để làm gì?
Email thông báo giúp người phụ trách nhận nội dung khách gửi trên website khi chức năng đang sử dụng có hỗ trợ gửi thư. Cần phân biệt ba việc: khách gửi form, hệ thống lưu dữ liệu liên hệ và hệ thống gửi email. Ba việc này không phải lúc nào cũng nằm trong cùng một luồng.
Bài này đối chiếu module ContactDynamic hiện có. Những chức năng khác như giỏ hàng hoặc module tùy biến cần kiểm tra cách đọc cấu hình riêng; không suy rộng tên một tham số thành quy tắc cho toàn bộ website.
Giao diện xác định loại form đang sử dụng
Form liên hệ dùng thuộc tính động
Khi biểu mẫu dùng thuộc tính động hoặc đã chọn một nhóm thuộc tính liên hệ, hệ thống kiểm tra thông tin rồi lưu yêu cầu vào mục Liên hệ trong CMS. Nếu MailAccount có địa chỉ nhận, hệ thống tiếp tục thử gửi email thông báo cho người phụ trách, kèm các trường đã nhập và ảnh đính kèm khi có. Thông báo đã nhận yêu cầu xác nhận việc lưu liên hệ, không phải xác nhận thư đã vào hộp thư.
Nếu form báo đã nhận yêu cầu nhưng chưa có email, trước tiên kiểm tra liên hệ trong CMS và địa chỉ MailAccount của đúng khối biểu mẫu. MailAccount để trống thì không gửi thông báo. Nếu gửi thư gặp lỗi, liên hệ đã lưu vẫn được giữ và người gửi vẫn có thể thấy thông báo đã nhận; nhờ người vận hành kiểm tra nhật ký gửi thư theo thời điểm và mã liên hệ, không yêu cầu khách gửi lại chỉ để tạo email.
Form liên hệ theo luồng cũ
Khi không dùng thuộc tính động, module có thể gửi thư và có tùy chọn lưu thông tin khách. Mở đúng module đang gắn lên trang liên hệ để kiểm tra các tham số bên dưới. Không sửa cấu hình của một form khác chỉ vì có tiêu đề giống nhau.
Giao diện tham số thông báo của biểu mẫu liên hệ
- MailAccount: trong luồng ContactDynamic này là địa chỉ nhận thông báo. Nếu để trống, chương trình bỏ qua bước gửi email của nhánh này. Không hiểu đây luôn là tài khoản đăng nhập SMTP.
- MailServer: tên máy chủ gửi thư. Khi dùng thông số riêng, nhập đúng hostname được bên quản trị email cung cấp, không nhập URL hộp thư web.
- MailPort: cổng kết nối do dịch vụ thư quy định. Chọn cùng cấu hình bảo mật được hỗ trợ; không dùng một cổng chung cho mọi nhà cung cấp.
- MailEnableSSL: bật hoặc tắt yêu cầu bảo mật kết nối theo cấu hình SMTP. Bật không có nghĩa mọi cổng đều sử dụng được; phải đối chiếu với dịch vụ và thư viện gửi thư đang triển khai.
- MailPassword: mật khẩu phục vụ xác thực trong nhánh ghi đè thông số gửi. Không phải mật khẩu của người đang điền form liên hệ.
- DisplayName: tên người gửi hiển thị trong thư, giúp người nhận nhận diện nguồn thông báo.
- Title: tham số tiêu đề thư, được chương trình đọc vào MailTitle; khi trống, xử lý gửi dùng tiêu đề module làm dự phòng.
- SubTitle: nội dung phụ đề mà skin liên hệ có thể hiển thị; không phải địa chỉ nhận hay thông tin xác thực gửi thư.
- SaveCustomer: bật để nhánh form cũ thực hiện lưu thông tin khách sau phần xử lý gửi. Lưu dữ liệu và gửi thư có phản hồi riêng.
- CaptchaLength: lớn hơn 0 thì dùng mã xác nhận của form cũ; nhập sai mã làm dừng bước xử lý nội dung và đổi mã xác nhận. Đây không phải độ dài mật khẩu email.
Nghiệp vụ ngầm cần hiểu trước khi nhập SMTP
Khi tạo đối tượng gửi, chương trình lấy tài khoản đăng nhập, mật khẩu, máy chủ, cổng, bảo mật và địa chỉ From từ cấu hình chung của ứng dụng. Chỉ khi cả MailServer và MailPassword riêng đều có giá trị, nó mới ghi đè máy chủ, cổng, SSL và mật khẩu.
Nhánh ghi đè này không thay tài khoản đăng nhập SMTP và địa chỉ From vốn lấy từ cấu hình chung. Do đó, không nhập máy chủ/mật khẩu của một hộp thư hoàn toàn khác rồi cho rằng MailAccount sẽ đổi cả người gửi. Cần người quản trị kỹ thuật đối chiếu tài khoản chung và thông số riêng như một bộ thống nhất.
Đây cũng là lý do chỉ đổi MailPort hoặc bật SSL trong khi thiếu điều kiện ghi đè có thể không tạo hiệu quả như người dùng mong đợi. Hãy xác định website đang dùng cấu hình chung hay cấu hình ghi đè trước khi lưu.
Chuẩn bị quyền gửi thư ở nhà cung cấp
Lấy cấu hình từ người quản trị hệ thống email của doanh nghiệp. Với tài khoản Google có hỗ trợ mật khẩu ứng dụng, tính năng này yêu cầu xác minh hai bước và có thể không khả dụng với một số tài khoản tổ chức hoặc chế độ bảo vệ. Không dùng hướng dẫn cũ yêu cầu bật “ứng dụng kém an toàn”. Xem hướng dẫn mật khẩu ứng dụng của Google.
Không dán mật khẩu vào nội dung bài viết, banner, mã hiển thị công khai hoặc gửi lại cho khách. Thông tin xác thực cần được lưu đúng khu vực cấu hình được phân quyền.
Quy trình lưu và kiểm tra
- Xác định form động hay form cũ, đúng module và đúng website.
- Với form cũ, kiểm tra địa chỉ nhận và bộ cấu hình tài khoản gửi đang thực sự được áp dụng.
- Lưu thông số, sau đó gửi một yêu cầu kiểm tra có nội dung dễ nhận biết qua form ngoài website.
- Đọc thông báo trên form, kiểm tra thư đến và thư rác của địa chỉ nhận.
- Kiểm tra dữ liệu liên hệ/khách hàng nếu chức năng có lưu; không lấy việc có dữ liệu làm bằng chứng email đã gửi.
- Nếu chưa nhận, ghi lại giờ kiểm tra, module và thông báo lỗi để đối chiếu. Tránh gửi lặp nhiều yêu cầu khách hàng thật chỉ để thử cấu hình.
Khi nào cần xử lý thêm?
Nếu form động đã lưu liên hệ nhưng chưa nhận được email, kiểm tra MailAccount, bộ thông số gửi đang áp dụng và nhật ký gửi thư. Luồng hiện tại đã có bước thông báo cho người phụ trách; không cần mặc định kết luận phải làm thêm chức năng chỉ vì chưa thấy thư. Với form cũ báo lỗi xác thực, kiểm tra tài khoản gửi và mật khẩu thực tế. Khi đã gửi mà chưa thấy, kiểm tra địa chỉ nhận, thư rác và nhật ký giao nhận.
