Омана адрес
Омана адрес (переміщення адрес, мунінг адрес) — це практика маскування адреси електронної пошти, щоб запобігти її автоматичному збиранню непроханими постачальниками масової електронної пошти. Мунінг адреси призначено для маскування адреси електронної пошти таким чином, що не дозволяє комп'ютерному програмному забезпеченню бачити справжню адресу або навіть будь-яку адресу взагалі, але дозволяє читачеві відновити оригінал і зв'язатися з автором: адреса електронної пошти, наприклад, як «ніхто@example.com», стає «ніхто at example dot com».
Будь-яка адреса електронної пошти, опублікована для всіх, імовірно, буде автоматично зібрана комп'ютерним програмним забезпеченням, яке використовується масовими розсиланнями (процес, відомий як вимивання адрес електронної пошти). Адреси, розміщені на вебсторінках, Usenet або в чатах, особливо вразливі до цього. Приватну електронну пошту, надіслану між окремими особами, навряд чи вдасться зібрати, але електронну пошту, надіслану до переліку розсилань, який архівується та стає доступним через Інтернет, або передається на сервер новин Usenet і оприлюднюється, зрештою можна відсканувати та зібрати.
Недоліки ред.
Маскування адрес ускладнює людям надсилання електронної пошти одне одному. Багато хто розглядає це як спробу усунути симптом, а не як розв'язання справжньої проблеми спаму електронної пошти[en] за рахунок створення проблем для непричетних користувачів.[1] Крім того, є збирачі електронної пошти, які знайшли способи читати замасковані адреси електронної пошти.
Використання омани адреси в Usenet суперечить рекомендаціям RFC 1036, що регулюють формат публікацій Usenet, який вимагає вказувати дійсну адресу електронної пошти в полі повідомлення "Від: ". На практиці мало хто суворо дотримується цієї рекомендації.[2]
Систематичне маскування адрес електронної пошти (наприклад, user[at]domain[dot]com) забезпечує незначний захист.
Будь-яка перешкода зменшує бажання користувача докладати зайвих клопотів, щоб надіслати електронний лист на таку адресу. Навпаки, добре підтримана фільтрація електронної пошти на стороні користувача не відштовхує потенційних кореспондентів. Однак жоден фільтр спаму не захищений на 100 % від помилкових спрацьовувань, і той самий потенційний кореспондент, якого відлякували б адреси, може натомість витрачати час на довгі листи, які просто зникають у теках небажаної пошти.
Для комерційних структур підтримка контактних форм на вебсторінках, а не оприлюднення адрес електронної пошти може бути одним із способів гарантувати, що вхідні повідомлення відносно вільні від спаму, і не втрачаються. У поєднанні з полями CAPTCHA спам у таких полях коментарів може бути зведений до нуля. За винятком того, що відсутність доступності до CAPTCHA створює ті ж проблеми, що й стримувальні проблеми при маскуванні.
Альтернативи ред.
Як альтернатива маніпуляції адреси існує кілька «прозорих» методів, які дозволяють людям публікувати дійсну адресу електронної пошти, але все одно ускладнюють автоматичне розпізнавання та збір адреси:
- «Прозоре змінення імен» передбачає заміну символів в адресі еквівалентними посиланнями HTML зі списку посилань на об'єкти символів XML і HTML, наприклад, '@' замінюється на 'U+0040' або ' & #64;' і '.' замінюється на 'U+002E' або ' & #46;' з користувачем, який знає, що потрібно вийняти тире.[3]
- Розміщення всієї або частини адреси електронної пошти як зображення,[4] наприклад, ніхто
example.com, де знак «at» маскується під зображення, іноді з альтернативним текстом, зазначеним як «@», щоб дозволити копіювати та вставляти, але при зміні адреси залишатися за межами типових регулярних виразів спам-ботів. - Використання форми на стороні клієнта з адресою електронної пошти як анімованого текстового логотипу CSS3 і його скорочення до нормального розміру за допомогою вбудованого CSS.[5]
- Опублікування адреси електронної пошти з перемішаним порядком символів і відновлення порядку за допомогою CSS.
- Побудова посилання за допомогою сценаріїв на стороні клієнта.[6]
- Використання сценаріїв на стороні клієнта для створення багатоключевого шифратора електронної адреси.[7]
- Використання сценаріїв на стороні сервера для запуску контактної форми.[8]
Прикладом використання " user@example.com " за допомогою сценаріїв на стороні клієнта буде:
<script type="text/javascript">
var name = 'user';
var at = '@';
var domain = 'example.com';
document.write(name + at + domain);
</script>
Використання зображень і сценаріїв для обфускації адрес може спричинити проблеми для людей, які використовують програми зчитування з екрана, та користувачів з обмеженими можливостями, а також ігнорує користувачів текстових браузерів, таких як lynx та w3m[en], хоча прозорість означає, що вони не шкодять людям, які не говорять англійською, які не можуть зрозуміти звичайний текст, прив'язаний до однієї мови, що є частиною непрозорих змінених адрес або інструкцій, які їх супроводжують.
Згідно з дослідженням 2003 року, проведеним Центром демократії та технологій, навіть найпростіше «прозоре маніпулювання іменами» адрес електронної пошти може бути ефективним.[9]
Приклади ред.
Поширені методи маскування адрес:
| Замаскована адреса | Відновлення оригінальної адреси |
|---|---|
| no-one at example (dot) com | Замініть «at» на «@», і «(dot)» на «.» |
| no-one@elpmaxe.com.invalid | Зворотне доменне ім'я : elpmaxe до example відкинувши.invalid |
| moc.elpmaxe@eno-on | Відзеркалити всю адресу |
| no-one@exampleREMOVEME.com | Інструкція в самій адресі; видалити REMOVEME |
| no-one@exampleNOSPAM.com.invalid | Видаліть NOSPAM і .invalid з адреси. |
| n o — o n e @ e x a m p l e . c o m | Це все ще читається, але пробіли між літерами зупиняють більшість автоматичних спам-ботів. |
| no-one@example.com (як HTML) | Це все ще читається і може бути скопійовано безпосередньо з вебсторінок, але зупиняє багато збирачів електронної пошти. |
| по-опе@ехатрlе. сот | Не можна скопіювати безпосередньо з вебсторінок, потрібно скопіювати вручну. Усі літери, крім l, є кириличними гомогліфами, які ідентичні латинським еквівалентам для людського ока, але сприймаються більшістю комп'ютерів по-різному. (Див. також IDN homograph атака[en] для більш зловмисного використання цієї стратегії.) |
Зарезервований домен верхнього рівня .invalid додається, щоб гарантувати, що справжня адреса електронної пошти не буде створена випадково.
Посилання ред.
- ↑ Address Munging Considered Harmful [Архівовано 20 червня 2020 у Wayback Machine.], Matt Curtin
- ↑ See Usenet.
- ↑ Raffo, Daniele (20 січня 2015). Email Munging. Daniele Raffo. Процитовано 12 лютого 2015.
- ↑ E-mail as an image. Архів оригіналу за 4 травня 2009. Процитовано 17 травня 2009.
- ↑ Client-side contact form generator (the generator requires JavaScript enabled, output for displaying emails requires CSS)
- ↑ JavaScript address script generator [Архівовано 11 лютого 2022 у Wayback Machine.] (the generator requires cookies enabled, output for displaying emails requires javascript enabled)
- ↑ Hattum, Ton van (13 березня 2012). Email Address on Your Site, SPAM Protection, Encrypting. Ton van Hattum. Архів оригіналу за 22 лютого 2017. Процитовано 22 лютого 2017.
- ↑ PHP contact form generator. Архів оригіналу за 11 лютого 2022. Процитовано 11 лютого 2022.
- ↑ «Why Am I Getting All This Spam? Unsolicited Commercial E-mail Research Six Month Report» March 2003. [Архівовано 3 вересня 2021 у Wayback Machine.] accessed 2016-09-12
