Чи потрібно переписування SRS абсолютно необхідним для сервера пересилання?

Я використовую сервер електронної пошти Postfix для свого домену, скажімо, mydomain.com. Він здебільшого діє як сервер електронної пошти для переадресації: користувачі отримують адресу електронної пошти @ mydomain.com, але, як правило, обирають переадресувати свою адресу на зовнішню папку "Вхідні" (Gmail, Yahoo тощо). Пересилається кілька тисяч адрес, тому сервер обробляє досить значний обсяг поштового трафіку.

Раніше сервер не використовував переписування SRS. Це, звичайно, означало, що пересилається пошта не може перевірити SPF, оскільки моя ip-адреса технічно не має права надсилати електронні листи від імені оригінального домену відправника. Однак, як я бачу, це, здається, не викликає значних проблем. Як правило, жодні скарги користувачів, як Gmail, Yahoo тощо, здаються досить розумними, щоб ігнорувати збої SPF та доставляти повідомлення в будь-якому разі.

Зважаючи на це, чи дійсно потрібно включити переписування SRS? Я розглядаю можливість його ввімкнути, але головна моя проблема полягає в тому, що мій домен потрапить у чорний список для надсилання спаму, коли спам неминуче переслідує. Не вдалося б переписати так, ніби я є автором спаму? (Принаймні, це я розумію, читаючи кращі практики Gmail для переадресації поштових серверів ).

Зрозуміло, я вже вживаю деякі рекомендовані заходи безпеки, такі як використання SpamAssassin для додавання "СПАМ" до тематики підозрюваного спаму перед переадресацією, не пересилаючи спам високої впевненості (оцінка 15+) та використовуючи блок-список спаму, але ці заходи не є не ідеально, і спам все ще може прослідкувати без позначення.

Чи варто включити переписування SRS, якщо це підвищує ризик неправильно позначити як спамер? Або було б безпечніше просто залишити його таким, який є, і проігнорувати провали SPF?

postfix spam spamassassin

— tlng05
джерело

З досвіду я знаю, що деякі Інтернет-провайдери у Великобританії відхилять вхідний електронний лист, який, як стверджується, від їх власних клієнтів, але він не надсилався від їх власних електронних повідомлень. Те саме може статися і для Gmail, Yahoo та AOL. Такі ситуації можна вирішити лише шляхом переписування адреси відправника.

— roaima

Відповіді:

Мені здається, що ваше питання зводиться до " скільки поштових серверів там перевіряють SPF-записи на вхідну електронну пошту? ". Якщо це більшість із них, SRS є абсолютною вимогою для сервера переадресації; якщо це жодна з них, SRS вам не потрібен.

На жаль, я не можу одразу покласти руку на будь-яку академічну роботу з цього приводу. Але оскільки я перевіряю SPF на вхідну пошту, можу з впевненістю сказати, що деякі поштові сервери це перевіряють. Будь-який з ваших клієнтів, у якого ваш сервер перенаправлений до облікових записів мого сервера, втратить електронну пошту від відправників, які рекламують SPF, який закінчується (як слід) -all, якщо ви не використовуєте SRS. Тож можу з упевненістю сказати, що без SRS деякі електронні листи ваших клієнтів не будуть доставлені .

Прошу вибачення у Марка, що я не можу читати німецьку мову, тому я не можу сказати, чи PDF, який він цитує, висуває переконливі аргументи, але можу повторити, що без SRS деяка частина електронних листів ваших клієнтів не буде доставлена. Я не можу сказати, що це за фракція, але вона не дорівнює нулю - і, враховуючи це, я не думаю, що у вас немає альтернативи, крім як запустити SRS.

Я погоджуюся, що ваш сервер не допоможе собі, пересилаючи СПАМ, але, на мій досвід, більшість репутаційних збитків наносяться на його IP-адресу, а не на конверт-з домену; це буде зроблено незалежно від використання SRS.

Більш глибока відповідь на ваше запитання полягає в тому, що між SPF та його (непродуманим та порушеним в Інтернеті) подальшим DMARC мені здається, що служби переадресації пошти мали свій день. Я вже вимагав, щоб усі мої користувачі мали остаточну доставку на моєму сервері, і цього користувача доведеться змінити або залишити в 2016 році. В даний час багато систем веб-пошти дозволять інтегруватися через кілька поштових скриньок, збираючи пошту поза сервером за допомогою IMAP або POP та багато поштових клієнтів дозволяють безлічі облікових записів IMAP або POP представляти собою єдиний інтегрований INBOX, тому пересилання не є вигодою для централізованого читання, як це було раніше.

Коротше кажучи, я б сказав, що вам потрібні SRS у короткостроковій перспективі та нова бізнес-модель у довгостроковій перспективі.

— MadHatter
джерело

Вся справа в тому, що SRS - це рішення для виправлення питань переадресації SPF. SRS переписує, наприклад, користувач @ A до A = користувач @ B, і SPF-записи B відповідають тоді. Проблема: B все ще може підробляти адреси! Тому деякі додають криптовалюти та часові позначки до переписаної адреси. Щоб це було широкомасштабним, воно потребує глобального прийняття, якого там немає. Він також працює лише в тому випадку, якщо щось пересилається один раз, але не більше. Також відповіді є проблемою. Також пам’ятайте, що SPF - це техніка захисту власного домену від зловживань, і не більше того.

— Марк Стурмер

@ MarcStürmer " SRS - це рішення для усунення проблем переадресації SPF ": так, саме так воно і є. SPF, як відомо, порушує спрощену переадресацію; якщо ви не вважаєте, що SRS - ціна, яку варто заплатити, не рекламуйте запис SPF. " Проблема: B все ще може підробити адреси ": не до домену A чи будь-якого іншого домену, захищеного гідною записом SPF, або пошта буде відхилена відповідно до SPF; але крім цього, так, це може, і я не вважаю це проблемою. " SPF - це техніка захисту власного домену від зловживань, нічого більше ": Я згоден.

— MadHatter

@ MarcStürmer: "Це також працює лише в тому випадку, якщо щось пересилається один раз, але не більше". невірно. SRS працює повністю добре на декількох серверах переадресації. Він страждає лише в тому випадку, якщо в рядку є сервер без тегів. Але це та сама проблема, що і з будь-яким сервером без тегу взагалі, будь то перший чи пізній перехідний перехід. У світі SPF вам не потрібні SRS, вам просто потрібно взяти на себе відповідальність за переслану пошту і переконатися, що ви зможете доставити можливий відкат назад. SRS - це лише одна методика, яка робить це, google, наприклад, використовує щось інше.

— Адріан Заугг

Проблема полягає в тому, що за допомогою SRS порушує перевірку вирівнювання DMARC (тобто відправник конверта! = From:-Header) і змусить Gmail відхиляти повідомлення, якщо домен у From:заголовку є p=rejectу своїй політиці DMARC. Якщо ви також перезаписуєте повідомлення From:, пошта буде перевірена відповідно до правил вашого домену. Але перевірка DKIM не вдасться, і відправник, який відображається в поштовому клієнті, не працює.

— mbirth

@mbirth afaik, ти маєш рацію. Але я особисто розглядаю DMARC як повну катастрофу, не в останню чергу через те, що він в односторонньому порядку порушував списки розсилки, і (на мою посаду адміністратора великого списку спільнот) просто раджу людям не користуватися будь-яким провайдером, який публікує p=rejectполітику. Якщо SRS порушує DMARC, ну це дуже важко для DMARC.

— MadHatter

SRS, здається, є приємною ідеєю на папері, але не дуже добре працює на практиці відповідно до людей, які підтримують Heinlein Support (вони працюють середньою поштовою службою з понад 100000 акаунтами.)

Деталі є у їхній розмові, хоча німецькою мовою, чому: https://www.heinlein-support.de/sites/default/files/SPF-DKIM-Greylisting_FrOSCon_2012.pdf

Основна причина полягає в тому, що SRS є невеликим виправленням для серйозних проблем впровадження SPF в реальності, оскільки SPF не дуже добре охоплює деякі випадки поширеного використання електронної пошти. Для SRS це має сенс, хоча його потрібно розгорнути на великій базі серверів, що навряд чи колись станеться. Тому, поки він не буде розміщений на цій великій базі серверів, це зовсім не має сенсу.

Проблема великих постачальників пошти полягає в тому, що вони в даний час мають дійсно велику базу користувачів, і вони впроваджують все більше і більше методів (наступник для DMARC вже в стадії розробки), що робить це все складніше для нормального налаштування поштового сервера для надійного надсилання їм листів.

Якщо ви хочете, щоб ваша пошта краще доставлялася до великих постачальників пошти, таких як Gmail, Hotmail тощо, ви повинні впровадити принаймні DKIM та DMARC, а також встановити її на слабкий вихід в кращому випадку і, можливо, застосувати деякі механізми обмеження швидкості доставки пошти. творить чудеса для вас.

Ця проблема з великими провайдерами є причиною того, що сьогодні існують такі сервіси, як Mailchimp, Mandrill або Returnpath. Ці провайдери платять гроші Google & Co. для кращої якості доставки.

— Марк Стурмер
джерело

Проблема тут - SPF, а не SRS. Поки деякі провайдери використовують SPF, вам потрібно реалізувати SRS (або щось подібне), щоб переадресація працювала з усіма ними. Проблема із відтворенням списку в іншому, вам слід "розпакувати" адреси відправлених з тегом SRS для відтворення в списку (також, як теги BATV).

— Адріан Заугг

Я погоджуюся з кожним словом @MadHatter, Але важливий факт про Google!

Якщо ви надаєте послугу переадресації в gmail, є велика ймовірність, що ви надаєте SMTP-доступ і для того, щоб ваші користувачі gmail могли надсилати листи від gmail від імені збереженої вами адреси.

У такому випадку - gmail знає, що ви пересилаєте цей електронний лист, і не позначає ваших форвардів як спам, навіть якщо це не вдалося перевірити SPF.

Ви можете відправляти клієнтам листи з електронної пошти bill@microsoft.com. Повідомлення надійде до поштової скриньки без будь-якого попередження! (Microsoft має -all в записі spf)

Перевірено та перевірено. Приклад додається

це повідомлення надійшло у папку "Вхідні".

— так
джерело