Когато формулярът за контакт казва „Благодарим ви“, но имейл не пристига

Представете си малка физиотерапевтична практика. Уебсайтът ѝ има формуляр за контакт и формулярът работи – или поне изглежда така. Посетителите го попълват, кликват „Изпрати“ и виждат любезно „Благодарим ви, ще се свържем с вас скоро“. Това, което никой не вижда: съобщенията отдавна са спрели да достигат до пощенската кутия на практиката. Няма грешка, няма върнато писмо в ничия пощенска кутия, никъде не свети червена лампичка. Формулярът се проваля безшумно.

Защо никой не забелязва

Страницата „Благодарим ви“ на формуляра обикновено означава само едно: уебсайтът е предал съобщението нататък. Дали пощенски сървър ще го приеме, ще го класифицира като спам или ще го отхвърли по пътя, се случва по-късно, извън полезрението на формуляра. Функцията mail() на PHP например докладва успех веднага щом локалната система приеме съобщението за доставка – а не когато то достигне до някого. Така посетителят получава потвърждение и продължава нататък. Собственикът междувременно вижда празна пощенска кутия и предполага, че просто месецът е спокоен. По-малкото запитвания рядко са тревожни сами по себе си: празници, времето, икономиката – винаги има обяснение, което звучи по-правдоподобно от „формулярът е повреден“.

Обичайните причини

• Паролата за SMTP или доставчикът на имейл услуги са сменени. Формулярът продължава да влиза със старите данни за достъп и пощенският сървър отказва – безшумно, доколкото може да прецени посетителят.
• PHP mail() без удостоверяване. Уеб сървърът изпраща пощата директно, без да влиза в истински пощенски сървър. Много приемащи сървъри третират такава поща като подозрителна: тя попада в спама или направо се отхвърля.
• SPF, DKIM и DMARC не съответстват. Много формуляри поставят адреса на посетителя в полето From. Тогава съобщението твърди, че идва например от адрес в gmail.com, но е изпратено от вашия уеб сървър – точно това, което DMARC е създаден да спира.
• Актуализация на плъгин или смяна на темата поврежда формуляра или неговата CAPTCHA. Променен шаблон премахва поле, скрипт вече не се зарежда или уиджетът на CAPTCHA се появява без скрипта си – и всяко изпращане не преминава валидирането.
• Приемащата пощенска кутия е пълна. Пощенският сървър отказва нови съобщения, а върнатото писмо отива на адрес, който никой не чете.
• Банерът за бисквитки блокира скрипта на формуляра. Ако инструментът за съгласие класифицира CAPTCHA или скрипта на формуляра като „маркетинг“, посетителите, които откажат бисквитките, може да получат формуляр, който не може да бъде изпратен или чиито изпращания се отхвърлят, защото липсва токен.
• Изтекъл TLS сертификат или домейн. Посетителите виждат предупреждение в браузъра и си тръгват или пощенският сървър вече не може да бъде достигнат сигурно. Ако домейнът на приемащата пощенска кутия изтече, пощата до нея просто спира.
• Кеширащ слой обслужва остарели страници. Кешът на цели страници може да достави формуляр с изтекъл токен за сигурност (nonce или CSRF токен). Сървърът отхвърля изпращането и в зависимост от настройката посетителят не вижда ясна грешка.

Капанът с адреса в From

Третата причина заслужава по-внимателен поглед, защото много настройки на формуляри я имат вградена по подразбиране. DMARC проверява дали домейнът във видимия адрес From съвпада с домейн, за който гарантира SPF или DKIM. Ако формулярът изпраща съобщение „от“ адреса на посетителя, сървърът ви не е оправомощен да изпраща от името на този домейн, така че проверката е неуспешна. В зависимост от DMARC политиката на домейна на посетителя и от собствения ви доставчик на имейл услуги съобщението попада в спама или се отхвърля. Решението е просто: изпращайте от адрес в собствения си домейн и поставете адреса на посетителя в Reply-To. Кликването върху „Отговор“ пак достига до посетителя.

Какво да направите

1. 1Редовно изпращайте тестово съобщение чрез собствения си формуляр – поне веднъж месечно и винаги след актуализации, смяна на темата или промени в настройките на пощата. Обозначете го ясно като тест, за да не му отговаря никой.
2. 2Познавайте нормалния си ритъм. Ако формулярът обикновено носи няколко съобщения седмично, две седмици тишина са повод за проверка, а не спокоен месец.
3. 3Изпращайте чрез SMTP с удостоверяване – чрез вашия доставчик на имейл услуги или специализирана услуга за изпращане – вместо да разчитате на PHP mail().
4. 4Използвайте собствения си домейн в From и адреса на посетителя в Reply-To. След това настройте SPF, DKIM и DMARC за този домейн, за да преминават съобщенията проверките.
5. 5Пазете копие от всяко изпращане в базата данни. Много плъгини за формуляри предлагат това, понякога като добавка. Ако пощата откаже, запитванията пак са налице.
6. 6Проверявайте формуляра след всяка актуализация на плъгин – включително CAPTCHA, а също и при отказани бисквитки.

Такива проверки лесно се забравят, затова си струва да ги автоматизирате. С акаунт и верифициран домейн formexposed може да изпрати ясно обозначено тестово съобщение и да провери дали то действително пристига (проверката на доставката, само при включване). Той открива и тишина – формуляр, който обикновено получава съобщения, внезапно не получава никакви – и проверява SPF, DKIM и DMARC на имейлите с известия, както и изтичането на TLS сертификата и домейна. Получавате известие само когато нещо се промени.

Ако искате само да хвърлите първи поглед: безплатна проверка на formexposed.com не изисква акаунт и не изпраща нищо. Наред с другото тя показва дали има CAPTCHA, която е налице, но повредена – уиджет без скрипта си, публичен тестов ключ, грешки в браузъра – един от по-незабележимите начини, по които формулярът спира да работи. Дали съобщенията наистина пристигат, може да потвърди само истинско тестово съобщение, така че изпратете едно още днес.