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 tham số UseContactAttributes bật, module đọc danh sách thuộc tính liên hệ và xử lý gửi bằng luồng lưu liên hệ. Hệ thống kiểm tra mã chống gửi lặp, lưu dữ liệu liên hệ, báo đã nhận yêu cầu và đổi mã form. Nhánh này không thực hiện đoạn gửi SMTP của form cũ.
Vì vậy, nếu form động báo đã nhận yêu cầu nhưng không có email, chưa thể kết luận mật khẩu email sai. Kiểm tra dữ liệu liên hệ được lưu và yêu cầu thông báo thực tế của website trước. Điền SMTP vào tham số cũ không tự bổ sung bước gửi thư cho nhánh động.
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 form cũ
- 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 thành công nhưng doanh nghiệp muốn nhận email tự động, cần cấu hình hoặc triển khai một luồng thông báo phù hợp với form động; bài này không khẳng định luồng đó đã có. Nếu form cũ báo lỗi xác thực, kiểm tra cặp tài khoản gửi và mật khẩu thực tế. Nếu báo gửi thành công nhưng không nhận, kiểm tra hộp thư nhận và cơ chế lọc thư ở bước giao nhận.