2014-02-13 bounce processing
by Vasil KolevПонеже няколко пъти се е случвало да решавам тоя проблем или да го разказвам на някой, реших да го напиша.
Проблемът е следният: как да разберем, че не можем да пращаме mail до определено място, като ни дойде bounce от там? Да се parse-ва самото писмо е загубена кауза, понеже няма никакъв ясен формат.
Идеята е сравнително проста: във всеки mail има Return-Path: header, който винаги е първи, и към който се bounce-ва mail-а. Ако всяко съобщение има уникален такъв, може да се познае за кой получател (и може би и за кое съобщение) става въпрос. Самият bounce може да се познае по празният return-path (така че ако някой заблуден spam реши да дойде, да не създаде проблем).
(като всички такива хитрини, и тази е открита от Дан Бернщайн и даже си има нещо като стадарт – Verp)
Има различни начини да се направи, последният вариант, който написахме правеше return-path-а да е във следния формат:
UID_TIMESTAMP_SIGN@bounce.domain.com
където uid беше id-то на потребителя от базата, timestamp си е unix-ки timestamp и sign е sha1 на uid_timestamp_secret, като secret само ние си го знаем и така можем да проверим дали наистина ние сме го генерирали това. За да се избегне един race condition, в който потребителя си е сменил email-а преди ние да получим bounce, може в sign да се включи и оригиналния email адрес, така че bounce просто да не match-не сигнатурата си.
(гледайки сега по стандарта, заради graylist-а може да е добра идея да сменя първото _ с +)
От там нататък просто ви трябва нещо просто, което да засилва цялата поща за @bounce.domain.com към един скрипт, който да прави тривиален анализ на header-ите и да казва “да, тоя mail не е верен”.
Tags: работа
February 13th, 2014 at 22:53
Понеже ползваме подобна технология в нашите проекти от дълго време искам да споделя, че тя освен положителните си страни има и отрицателни. Причините за отрицателните страни са, че имейл клиенти пишат всякакви хора (в т.ч. и ние;) и всеки тълкува стандартите по различен начин.
Някои клиенти използват Return-Path с предимство, пред From, в следствие на което отговорите на потребителите отиват на кофти място. Разбира се, едно добро решение на този проблем е технологията с ‘+’ и ‘=’ в първата част на имейла. По този начин нашите рreturn адреси станаха:
`Return-Path: `
Първото нещо е оригиналния user, `returned` е да покаже екшъна, защото подобен синтаксис използваме и за други хедъри, а часта лсед равното до клюмбата е случаен стринг, записан в нашата база.
Това нещо работи, но има клиенти, като някои от българските web пощи, които не изпращат отговора за неполучено писмо на целия адрес, а само на `team@mydomain.bg`.
Друг проблем са автоматичните отговори от типа “Аз съм във ваканция. Ако ви трябвам …”. Те също понякога се насочват неправилно към `Return-Path`.
Третият проблем е, че някой спам филтри (не знам защо предимно от фрнски клиенти) тълкуват разликите в `Return-Path` и `From` като увеличаващи риска от СПАМ. Този риск стана по-малък, като махнахме цифрите от случайната част.
=====================================
Извън темата:
Ако имате имейл адрес в Gmail.com, може да накарате някои услуги, които искат имейл за регистрация да си мислят, че всеки път имате нов адрес, като добавяте нещо в името си, след знака ‘+’. Gmail се справя добре и насочва всичко във вашата поща:
myname+test1@gmail.com и myname+test2@gmail са два адреса към една пощенска кутия за гугъла, но за някои услуги (където могат да се въведат) те са различни.