Cách an toàn để gửi thư qua PHP cho nhiều người dùng

Không có lý do gì khiến bạn không thể viết nó bằng PHP, mặc dù tôi không biến nó thành một phần của quy trình webrequest / HTTP. Tôi đã triển khai thành công cho hoặc nhận 500.000 người đăng ký mỗi lần gửi thư (tùy thuộc vào dữ liệu cục bộ có sẵn, vì đây là một dự án dành riêng cho vị trí). Đó là một dự án nội bộ, vì vậy rất tiếc là không có mã / gói nào cho bạn, nhưng tôi đã xem qua một số gợi ý:

Thiết lập phân phối

• Bắt đầu với chính phpmailer, để đảm nhận việc định dạng, mã hóa nội dung và tiêu đề, thêm tệp đính kèm, v.v. Phần đó hoạt động tốt và tôi sẽ không muốn viết lại từ đầu.
• Bản thân việc 'gửi' email chỉ là đặt một số cờ trong cơ sở dữ liệu xem / cách / nội dung gì sẽ được gửi đến (một phần) người đăng ký.
• Sau khi cờ này được đặt, nó sẽ tự động được cronjob chọn, không cần máy chủ web nào nữa.
• Tôi bắt đầu với cơ sở dữ liệu bị ô nhiễm nặng với hàng triệu địa chỉ email, trong đó có rất nhiều rõ ràng là không hợp lệ, vì vậy điều đầu tiên là xác thực tất cả các địa chỉ email cho định dạng, sau đó cho máy chủ lưu trữ:
  • filter_var($email, FILTER_VALIDATE_EMAIL); qua số người đăng ký (và hiển nhiên là lưu trữ kết quả) đã loại bỏ vài trăm nghìn email không hợp lệ đầu tiên.
  • Tách máy chủ lưu trữ (và lưu trữ tên máy chủ) từ email và xác thực điều đó (nó có MX hay ít nhất là bản ghi A trong DNS không, nhưng hãy nhớ:bạn có thể gửi email đến địa chỉ IP [email protected][255.255.255.255] , vì vậy hãy giữ những giá trị đó hợp lệ)) đã loại bỏ một phần tốt hơn. Địa chỉ email ở đây không phải bị vô hiệu hóa vĩnh viễn nhưng có cờ trạng thái cho biết chúng bị vô hiệu hóa do tên miền / ip.
  • Tập lệnh đã được thay đổi thành yêu cầu địa chỉ email hợp lệ khi đăng ký / trước khi chèn, điều vô nghĩa này 'bạn sẽ nhận được ví dụ @ sqldat.com ' ô nhiễm đăng ký trong cơ sở dữ liệu thật nực cười.
• Bây giờ tôi đã kết thúc với một danh sách các địa chỉ email có khả năng hợp lệ. Về bản chất, có 3 cách để phát hiện địa chỉ không hợp lệ (hãy nhớ rằng tất cả có thể là tạm thời):
  • Chúng bị máy chủ từ chối ngay lập tức.
  • Máy chủ được xác định trước đó chỉ không lắng nghe lưu lượng truy cập.
  • Chúng được trả lại rất lâu sau khi bạn nghĩ rằng mình đã giao chúng.
• Điều kỳ lạ, những lần trả lại, mà mọi máy chủ email dường như có định dạng khác ban đầu rất khó phân tích cú pháp, cuối cùng lại thực sự khá dễ dàng để nắm bắt bằng cách sử dụng VERP . Thay vì phân tích cú pháp toàn bộ email, một địa chỉ email chuyên dụng (hãy gọi nó là [email protected] ) đã được định cấu hình để sau đó gửi đến hộp thư, để chuyển nó qua một lệnh và nếu chúng tôi đã gửi email đến [email protected] , Return-Path được đặt cho [email protected] . Dễ dàng phân tích cú pháp khi nhận được và sau bao nhiêu lần trả lại (hộp thư không tồn tại, hộp thư có thể đầy (có, vẫn còn!), V.v.) bạn khai báo địa chỉ email không sử dụng được là tùy thuộc vào bạn.
• Bây giờ, máy chủ từ chối trực tiếp. Có thể chúng ta đã định cấu hình đúng một số MTA và / hoặc viết plugin cho những thứ đó, nhưng vì email nhạy cảm về thời gian và chúng ta phải có quyền kiểm soát có thể định cấu hình tuyệt đối cho mỗi lần gửi thư trong thời gian gửi có thể sử dụng cuối cùng (sau đó email không còn nữa quan tâm đến người dùng), điều chỉnh mỗi máy chủ nhận và nói chung là mọi thứ, sẽ mất khoảng thời gian tương tự khi viết một bưu phẩm bằng PHP mà chúng tôi biết rõ hơn, sử dụng giao thức SMTP trực tiếp đến socket 25 trên các máy chủ nhận. Với một nỗ lực tối thiểu, khả năng xảy ra một phương tiện truyền tải khác thì các lựa chọn mặc định trong PHPMailer đã được tích hợp sẵn. Giao thức SMTP thực sự khá đơn giản, nhưng có một số lưu ý:
  • Rất nhiều máy chủ nhận áp dụng Danh sách xám:hầu hết các spam bots sẽ không thực sự quan tâm nếu một thư cụ thể đến, họ chỉ chuyển chúng ra. Vì vậy, nếu một người gửi không xác định / chưa đáng tin cậy gửi thư, nó sẽ tạm thời bị từ chối. Nắm bắt thông tin đó (thường là mã 451) và đặt email vào hàng đợi để thử lại sau.
  • Một máy chủ thư, đặc biệt là của ISP lớn hơn và các dịch vụ miễn phí (gmail, hotmail / msn / live, v.v.) sẽ không chịu được một dòng thư mà không phản hồi:sau vài trăm / nghìn đầu tiên, họ bắt đầu từ chối bạn. Thông tin thêm về điều đó sau.

Bắt tốc độ

• Bây giờ, chúng tôi đã có một hệ thống phân phối hoạt động, nhưng nó cần phải nhanh . Gửi 10.000 email trong một giờ đều tốt nếu bạn chỉ có 10.000 địa chỉ để gửi, nhưng mức tối thiểu chúng tôi yêu cầu là khoảng 200.000 mỗi giờ. Khởi đầu của nó là một máy chủ chuyên dụng (thực sự có thể được cung cấp năng lượng khá thấp, bất kể bạn làm gì, phần lớn thời gian gửi email là trong mạng chứ không phải trên máy chủ của bạn).
• Lưu vào bộ nhớ cache của IP:nhớ tất cả những IP mà chúng tôi đã yêu cầu từ tên máy chủ trong địa chỉ email? Chúng tôi đã lưu trữ những thứ đó một cách rõ ràng, và việc tra cứu IP của họ nhiều lần gây ra độ trễ đáng kể. Tuy nhiên, các IP có thể thay đổi:một bản ghi DNS ở đó, một MX khác ở một nơi khác ... dữ liệu sẽ cũ nhanh chóng. Hầu hết thời gian máy chủ không thực sự gửi bất kỳ thứ gì (các bản tin đăng ký hiển nhiên đến từng đợt), một cronjob có mức độ ưu tiên thấp đang chạy kiểm tra tất cả các tên máy chủ có IP cũ (chúng tôi đã chọn cũ hơn 1 ngày là cũ) cho một địa chỉ IP , bao gồm cả những thứ trước đây không có (tên miền mới luôn được đăng ký, vậy tại sao một tên miền không khả dụng vào một ngày sau khi ai đó đã nhiệt tình đăng ký bằng địa chỉ email hoàn toàn mới của họ? Hoặc sự cố máy chủ với một số tên miền đã được giải quyết, v.v.). Trên thực tế, việc gửi email bây giờ không cần tra cứu miền nữa.
• Tái sử dụng kết nối SMTP:thiết lập kết nối với máy chủ mất một phần lớn thời gian để gửi email khi bạn đang nói chuyện trực tiếp với cổng 25. Bạn không phải thiết lập kết nối mới cho mọi email, bạn chỉ có thể gửi email tiếp theo qua cùng một kết nối. Một chút sơ suất đã dẫn đến việc đặt giá trị mặc định ở đây thành khoảng 50 email cho mỗi kết nối (giả sử bạn có nhiều hoặc nhiều hơn cho miền). Tuy nhiên, đôi khi việc đóng địa chỉ email không thành công và mở lại kết nối để thử lại. Nói chung, điều này thực sự đã giúp đẩy nhanh tiến độ.
• Một số điều hiển nhiên, quá rõ ràng mà tôi gần như đã quên đề cập đến nó:sẽ thật lãng phí nếu bạn phải tạo phần nội dung email ngay tại chỗ:nếu đó là một thư chung, hãy chuẩn bị phần nội dung đó (tôi đã thay đổi phần nào PHPMailer để có thể sử dụng email được lưu trong bộ nhớ cache), có thể vài ngày trước đó (nếu bạn biết bạn sẽ gửi thư vào thứ Sáu và máy chủ của bạn đang không hoạt động, tại sao không chuẩn bị cho chúng vào thứ Tư? Nếu phần đó được cá nhân hóa, bạn vẫn có thể chuẩn bị trước khi có đủ thời gian, nếu không, ít nhất hãy chờ các phần không được cá nhân hóa.
• Nhiều quy trình. Tôi đã đề cập đến phần lớn thời gian để gửi email là dành cho mạng? Một quá trình gửi thư gần như không tận dụng được nhiều nhất từ ​​máy chủ email của bạn, tải hầu như không đáng kể và các thư đang nhỏ giọt. Hãy thử với một số quy trình gửi thư các phần khác nhau của hàng đợi để xem điều gì phù hợp với máy chủ / kết nối của bạn, nhưng hãy nhớ 2 điều rất quan trọng:
  • Các quy trình khác nhau khiến bạn rất dễ bị ảnh hưởng bởi các điều kiện chủng tộc:hãy chắc chắn tuyệt đối bạn có một hệ thống bảo vệ toàn diện sẽ không bao giờ gửi cùng một thư hai lần (ba lần, thậm chí nhiều hơn). Nó không chỉ gây khó chịu nghiêm trọng cho người dùng mà hành vi gửi spam của bạn còn tăng lên một bậc.
  • Giữ các miền cùng nhau nếu có thể:chọn ngẫu nhiên từ hàng đợi, bạn sẽ mất lợi thế khi giữ kết nối mở với máy chủ nhận email cho miền.

Tránh từ chối

• Bạn sẽ gửi rất nhiều thư. Đó chính xác là những gì những kẻ gửi thư rác làm. Tuy nhiên, bạn không muốn bị coi là người gửi thư rác (sau tất cả, bạn không phải vậy)? Có một số cơ chế được áp dụng sẽ giúp bạn tăng đáng tin cậy một cách triệt để đối với các máy chủ tiếp nhận:
• Có DNS ngược thích hợp:các quy trình kiểm tra DNS thuộc về IP đang gửi email giống như nó rất nhiều nếu miền cấp hai khớp:bạn có đang gửi thư thay mặt cho example.com không ? Đảm bảo DNS ngược của máy chủ của bạn giống như somename.example.com .
• Xuất bản bản ghi SPF cho miền của bạn:cho biết rõ ràng máy được sử dụng để gửi email hàng loạt của bạn được phép và dự kiến ​​sẽ gửi thư với các tiêu đề Đường dẫn Từ / Trở lại đó.
• ghi nhớ các lần từ chối :máy chủ không thích nó cho bạn biết đi nói lại rằng các địa chỉ email khác nhau không tồn tại. Các cơ chế tự động và thậm chí cả quản trị viên của con người, đã chặn máy chủ của chúng tôi trong khi chúng tôi làm việc với tất cả các địa chỉ email không được xác thực đã (không còn) tồn tại. Chúng tôi đã không sử dụng tính năng chọn tham gia kép cho đến sau này, vì vậy cơ sở dữ liệu bị ô nhiễm bởi lỗi chính tả, mọi người chuyển đổi IP và do đó địa chỉ email, địa chỉ email chơi khăm, v.v. Hãy đảm bảo nắm bắt được những điểm yếu đó và đưa ra đủ hoặc cắt bỏ đủ số lỗi, hãy hủy đăng ký chúng . Họ đang làm không tốt cho bạn, họ đang sử dụng tài nguyên và nếu họ thực sự muốn bạn gửi thư và hộp thư sẽ khả dụng sau đó, họ sẽ chỉ cần đăng ký lại.
• DKIM là một cơ chế khác có thể tăng độ tin cậy của bạn, nhưng vì chúng tôi chưa triển khai (chưa) nên tôi không thể cho bạn biết nhiều về điều đó.
• Bản ghi MX:một số máy chủ vẫn thích nó nếu máy chủ gửi của bạn cũng là máy chủ nhận cho miền. Tại thời điểm đó, chúng tôi chỉ có 1 MX và vì máy chủ gửi thư vẫn chưa bận rộn lắm, chúng tôi đặt tên nó là máy chủ MX dự phòng cho miền. Máy chủ MX thông thường không phải máy chủ gửi đăng ký, vì rất khó chịu khi bị máy chủ chặn tạm thời mà bạn đang cố gửi một email quan trọng đến (máy khách, v.v.) vì bạn đã gửi một lượng thư ít quan trọng hơn. Nó có ưu tiên cao nhất là nhận MX, nhưng trong trường hợp không thành công, chúng tôi có phần thưởng tuyệt vời là máy chủ gửi đăng ký của chúng tôi sẽ vẫn dự phòng để phân phối, vì vậy trong khủng hoảng, chúng tôi vẫn có thể sử dụng nó, tránh bị trả lại khó xử cho khách hàng đang thử để liên hệ với chúng tôi.
• Cho họ biết về bạn. Nghiêm túc. Nhiều người chơi chính trong các địa chỉ email miễn phí như live.com cung cấp cho bạn cơ hội đăng ký theo một cách nào đó hoặc có một số đầu mối liên hệ để được trợ giúp và hỗ trợ nếu email của bạn bị từ chối. Tôi có lý do chính đáng để gửi nhiều email như vậy, và có thể tin rằng bạn có nhiều người đăng ký, rất có thể họ đã tăng số lượng email bạn có thể gửi đến máy chủ của họ mỗi giờ. 1.000 ít ỏi có thể trở thành con số mười nghìn hoặc thậm chí cao hơn nếu bạn đủ thuyết phục và trung thực. Có thể có những hợp đồng, những yêu cầu bạn phải thực hiện, và những lời hứa bạn phải thực hiện (và tuân giữ) để được phép thực hiện điều này. ISP là một thương hiệu khác biệt và mọi người chơi khác đều khác biệt. Đừng bận tâm gọi cho họ thường xuyên, bởi vì 99% thời gian các số duy nhất bạn có thể tìm thấy sẽ chỉ có những người sẵn sàng khắc phục sự cố kết nối internet của bạn, những người hiểu (hoặc được phép) một chút khác. [email protected] địa chỉ email là một nơi tốt để bắt đầu, nhưng hãy xem liệu bạn có thể nghiên cứu thêm một địa chỉ email trọng điểm hơn từ một nơi nào đó hay không. Hãy chính xác, trung thực và đầy đủ:đại khái có bao nhiêu người đăng ký của bạn có địa chỉ email với ISP đó, tần suất bạn đang cố gắng gửi thư cho họ, lỗi hoặc từ chối bạn nhận được là gì, quy trình đăng ký và hủy đăng ký như thế nào và là gì dịch vụ mà bạn thực sự cung cấp cho khách hàng của họ. Ngoài ra, hãy tốt bụng:việc gửi những bức thư đó có thể có ý nghĩa quan trọng như thế nào đối với doanh nghiệp của bạn, việc hoảng sợ về nó và tuyên bố tổn thất khủng khiếp không liên quan đến họ. Một tuyên bố lịch sự về sự kiện và mong muốn, và yêu cầu liệu họ có thể giúp được gì không thì việc yêu cầu một giải pháp sẽ phải trải qua một chặng đường rất dài.
• Throttling:dù bạn đã cố gắng, một số máy chủ sẽ chỉ chấp nhận một lượng thư nhất định mỗi giờ và / hoặc ngày từ bạn. Tìm hiểu những con số đó (chúng tôi vẫn đang ghi lại những thành công và thất bại), đặt chúng thành mặc định hợp lý cho các miền thông thường, đặt chúng thành các giới hạn đã thỏa thuận cho những người chơi lớn hơn.

Tránh bị gắn thẻ là spam

• Quy tắc đầu tiên:không gửi thư rác!
• Quy tắc thứ hai:đã từng! Không phải là "một lần tắt", không phải là "họ chưa đăng ký nhưng đây có thể là thỏa thuận cả đời đối với họ", không phải với mục đích tốt nhất, mọi người đã phải hỏi email của bạn.
• Rõ ràng là đã thiết lập một cơ chế đăng ký tham gia hai lần chính xác.
• PHPMailer tự đặt tiêu đề phù hợp,
• Thiết lập cơ chế hủy đăng ký dễ dàng trên web (bao gồm liên kết đến cơ chế đó trong every thư), có thể cả email và dịch vụ khách hàng nếu bạn có. Đảm bảo rằng dịch vụ khách hàng có thể hủy đăng ký mọi người trực tiếp.
• Như đã nói trước đó:việc hủy đăng ký (quá mức) không thành công và bị trả lại.
• Tránh những từ ngữ spam 'thỏa đáng cả đời'.
• Sử dụng url trong email của bạn một cách tiết kiệm.
• Tránh thêm các liên kết đến các miền nằm ngoài tầm kiểm soát của bạn, trừ khi bạn hoàn toàn chắc chắn rằng bạn có thể tin tưởng chúng không gửi thư rác, nếu ngay cả khi đó ...
• Cung cấp giá trị cho người dùng:bị gắn thẻ là spam do tương tác của người dùng trong ứng dụng khách google / yahoo / live webmail ảnh hưởng nghiêm trọng đến những thành công trong tương lai (trên trang web lưu ý:nếu bạn đăng ký, live / msn / hotmail sẽ chuyển tiếp tất cả thư mà bạn gửi theo miền của bạn bị người dùng gắn thẻ là thư rác. Hãy học cách yêu thích nó và như mọi khi:hủy đăng ký họ, họ rõ ràng không muốn trung tâm mua sắm của bạn và đang ảnh hưởng đến xếp hạng thư rác của bạn).
• Theo dõi danh sách đen cho IP của bạn. Nếu bạn xuất hiện trên một trong những địa chỉ đó, thì tạm biệt, vì vậy hãy thực hiện ngay hành động xóa tên của bạn và xác định trường hợp là bắt buộc.

Đo lường tỷ lệ thành công

• Với toàn bộ quy trình nằm trong tầm kiểm soát của bạn, bạn chắc chắn rằng email đã kết thúc ở đâu đó (mặc dù nó có thể là bitbucket của MX hoặc một thư mục spam), hoặc bạn đã ghi nhật ký bị lỗi và lý do tại sao. Điều đó sẽ quan tâm đến những con số "thực sự đã được phân phối".
• Một số người sẽ cố gắng thuyết phục bạn thêm liên kết đến hình ảnh trực tuyến vào email của bạn (ảnh thật hoặc ảnh gif trong suốt 1x1 nổi tiếng) để đo lường số người thực sự đọc email của bạn. Vì tỷ lệ phần trăm cao sẽ chặn những hình ảnh đó, nên những con số này tốt nhất là không đáng tin cậy và chúng tôi tin rằng chúng tôi không nên bận tâm đến chúng, những con số của chúng hoàn toàn không đáng tin cậy.
• Đặt cược tốt nhất của bạn để đo lường tỷ lệ thành công thực tế sẽ dễ dàng hơn rất nhiều nếu bạn muốn người dùng làm điều gì đó. Thêm thông số vào các liên kết trong thư, để bạn có thể đo lường số lượng người dùng truy cập vào trang web mà bạn đã liên kết, cho dù họ có thực hiện các hành động mong muốn (xem video, để lại nhận xét, mua hàng) hay không.

Nói chung, với tất cả ghi nhật ký, giao diện người dùng, cài đặt có thể định cấu hình cho mỗi miền / email / người dùng, v.v. Chúng tôi mất khoảng 1,5 tháng công để xây dựng và khắc phục các vấn đề. Đó có thể là một khoản đầu tư khá lớn so với việc thuê ngoài các email, cũng có thể không, tất cả phụ thuộc vào khối lượng và bản thân doanh nghiệp.

Bây giờ, hãy bắt đầu bùng cháy rằng tôi thật là ngu ngốc khi viết một MTA bằng PHP, tôi thực sự rất thích nó (đó là một lý do tôi viết một lượng lớn văn bản này), và khả năng ghi nhật ký và cài đặt cực kỳ linh hoạt, trên mỗi máy chủ. cảnh báo dựa trên tỷ lệ phần trăm lỗi, v.v. đang làm cho việc phát trực tiếp trở nên thật dễ dàng;)