Регистрация...

Eserv Forum / E4 / Mail / Адрес отправителя после перенаправления (форвардинга) меняется

wikipost // (v1)
Продукты и услуги Скачать Документация Купить Поддержка Форумы Партнёрам Статьи О компании
После запуска собственного SMTP-сервера, провайдер по нашей просьбе делает перенаправление почты с нашего п/я, находящегося у провайдера, к нам на сервер. При этом к письму дописываются соотв. заголовки, и при получении такого письма фильтры с черными списками FROM не срабатывают, т.к там стоит уже наш адрес п/я, с которого делалось перенаправление. Вот, напр.
For: clear_admin@aori.co.ru For: sekr@aori.co.ru Received-SPF: pass Received: from [194.186.47.94] (port=51394 helo=cgp.gldn.net) by aori.co.ru (acSMTP/4.24.4776) with ESMTP id 58081.0.1467036 (envelope-from <aori@co.ru>) for <sekr@aori.co.ru>; Thu, 23 Sep 2010 17:50:59 +0400 X-AttachExt: jpg X-DSPAM-Result: Innocent X-DSPAM-Processed: Thu Sep 23 17:44:33 2010 X-DSPAM-Confidence: 0.5319 X-DSPAM-Probability: 0.0019 Received: from <aori@co.ru> by backend2.cgp.gldn.net (CommuniGate Pro RULES 5.2.19) with RULES id 521934402; Thu, 23 Sep 2010 17:44:32 +0400 X-Autogenerated: Redirect Sender: <aori@co.ru> To: sekr@aori.co.ru Date: Thu, 23 Sep 2010 17:44:32 +0400 Message-ID: <redirect-521934402@backend2.cgp.gldn.net> X-Original-Return-Path: showroom@pois.tv X-Real-To: aori@co.ru X-DNSWL-Status: None X-AttachExt: jpg X-DSPAM-Result: Innocent X-DSPAM-Processed: Thu Sep 23 17:44:32 2010 X-DSPAM-Confidence: 0.5046 X-DSPAM-Probability: 0.0016 Received: from aa013msr.fastwebnet.it ([85.18.95.73] verified) by frontend3.cgp.gldn.net (CommuniGate Pro SMTP 5.2.19) with ESMTP id 286599574 for aori@co.ru; Thu, 23 Sep 2010 17:44:26 +0400 Received-SPF: none receiver=frontend3.cgp.gldn.net; client-ip=85.18.95.73; envelope-from=showroom@pois.tv Received: from ROSS (1.11.238.42) by aa013msr.fastwebnet.it (8.5.016.6) id 4C9914DE00A7086E; Thu, 23 Sep 2010 15:44:14 +0200 From: "Showroom" <showroom@pois.tv> X-Original-To: "Showroom" <showroom@pois.tv> Subject: Zona Centro collection X-Original-Date: Thu, 23 Sep 2010 15:44:12 +0200 X-Original-Message-ID: <2FC07113DDFF40A2ABF0EDAD840DD026@ROSS>

В данном случае адрес showroom@pois.tv лежит в черном FROM-списке, и в магните POPFile, но это не срабатывает, т.к. по журналам письмо приходит от aori@co.ru — т.е. от нашего п/я:
2010-09-23 17:50:25;194.186.47.94;@;58081;924;IN;MAIL FROM:<aori@co.ru> SIZE=1160430
Существует какой-н. способ решения такой проблемы? Делать фильтры прямо в настройках самого п/я возможности нет, т.к. этим управляет провайдер и такие настройки не предоставляет.
 
Комментарии к этой версии (27.09.2010 11:02) [~matveeva] 6d75afed
АвторДатаТекстtags
ac27.09.2010 16:16
Есть ведь в SMTP-фильтрах возможность анализировать любое поле заголовка.
wikipost
matveeva27.09.2010 16:37
Точно! Забыла!
wikipost
tbmos01.10.2010 10:26
При отправке письма из webmail в клиенте не отображается от кого(пустое поле),а в заголовке письма From: =?Windows-1251?B?IA==?= <emark@tbmos.ru>, в других случаях,в почтовом клиенте в поле "от" пишется просто =?Windows-1251?B?IA=,а от web@ все нормально пишется в клиенте,что web(заголовок From: web <web@tbmos.ru>)Подскажите в чем может быть проблема,как поправить?
wikipost
ac01.10.2010 11:27
=?Windows-1251?B?IA==?= — это MIME-кодированный пробел, его просто не видно при отображении в клиенте. Найдите этого пользователя emark в списке, укажите его реальное имя.
wikipost
tbmos01.10.2010 12:42
ред: 02.10.2010 09:53
У пользователей которые были конвертированны из eserv/3 при установки eserv/4,я не могу указать реальное имя в списке пользователей ,у вновь созданного пользователя проблем нет.Возможно это обойти или придется всех заводить вновь?
wikipost
ac02.10.2010 16:58
Обойдем в следующей сборке acWEB.
wikipost
ac07.10.2010 06:41
Дошел до исправления этой проблемы и... не могу её найти. В каком месте вы не можете указать реальное имя пользователя? Если выбрать учетную запись emark, потом в свойствах учетной записи нажать на поле с номером его контакта, откроется карточка контакта (так?), и там есть поля "Имя", "Отчество", "Фамилия". В конкретно этом случае они видимо пустые, но это не должно мешать их менять — щелкнуть по пустым полям и ввести текст. На каком этапе не срабатывает?

А пока я сделаю для случая "пробельных" имён ту же обработку, что и для отсутствующих имён (при формировании From).
wikipost
tbmos07.10.2010 09:47
Рядом с квадратом изображения в свойствах вновь созданной учетной записи есть поля ввиде троеточия измнений ФИO,в конвертированных при установке из eserv3 отсутствуют ,нажатие на номер контакта — никакой реакции.
wikipost
ac07.10.2010 11:00
А сам номер контакта там не пустой? Если на число наводите указатель мышки — срабатывает как на ссылку?
wikipost
tbmos07.10.2010 11:34
Если на значение(номер контакта есть) то да срабатывает как на ссылку но значение полей ФИО не дает менять.
wikipost
ac08.10.2010 15:39
Все равно не пойму. Вот нажимаете вы на номер-ссылку — карточка контакта при этом открывается? Что в ней? На что вы в ней жмёте для изменения ФИО?
wikipost
tbmos08.10.2010 16:04
ред: 08.10.2010 16:48
Нажимал на значение полей Ф И O, только сейчас обратил внимание поставив новую версию acweb/4 что теперь поля стали открываться для редакторования но у логинов один и тот же номер контактов — 1 , и вписанное значение в поле сразу появляется у всех логинов(которые были из eserv/3)
. выбираю пользователя-открывается его карточка-нажимаю на номер контакта -открывается меню операций с контактом -дальше в свойствах допустим имя жму на поле значение теперь стало открыватся поле для ввода значения имя раньше этого не происходило.
wikipost
ac08.10.2010 18:15
tbmos пишет: у логинов один и тот же номер контактов — 1

Они у вас в E3 были без имён (там ведь в его родном формате имена предусмотрены), или это E4 при импорте имена потерял?

tbmos пишет: дальше в свойствах допустим имя жму на поле значение теперь стало открыватся поле для ввода значения имя раньше этого не происходило.

В этой части интерфейса уже практически год никаких изменений.
wikipost
tbmos08.10.2010 22:59
ред: 11.10.2010 21:49
"E3 были без имён" — да к сожелению(не надо было),отсюда скорее всего и все проблемы,я логины за выходные дни пересоздам и закроем эту проблему.
wikipost
matveeva14.10.2010 13:48
ред: 14.10.2010 13:50
Возвращаясь к исходному вопросу. Сделала фильтр на заголовок From:
Стадия протокола header Заголовок From ..\FromBlack.txt Выполнить runInternal с параметрами CloseConnection FALSE

Получила письмо, которое имеет в заголовке From отправителя из списка FromBlack.txt, а фильтр не сработал:
Subject: DRC by Charlotte Eskildsen Spring Summer 2011 fashion show From: GUFFANTI OLEG <guffantishowroom@gmail.com> Content-Type: multipart/mixed; boundary=0016361e8286c2e35f049290bab8
вот журнал:
2010-10-14 14:03:21;194.186.47.93;@;573;1836;IN;MAIL FROM:<aori@co.ru> SIZE=3856933 2010-10-14 14:03:23;194.186.47.93;@;573;1836;OUT;250 aori@co.ru OK 2010-10-14 14:03:23;194.186.47.93;@;573;1836;IN;RCPT TO:<sekr@aori.co.ru> ...

Что-то не так сделала?
wikipost
ac14.10.2010 14:02
FromBlack.txt расположен прямо в корне E4? Как именно там записана строка, которая должна была сработать? В acSMTP.log что-нибудь про этот фильтр написалось?
wikipost
matveeva14.10.2010 15:06
ред: 14.10.2010 15:08
ac пишет: FromBlack.txt расположен прямо в корне E4?
Да. И другой фильтр, отличающийся только анализируемым заголовком:
Стадия протокола mailfrom MAIL FROM ..\FromBlack.txt
отрабатывает на все 100!
ac пишет: В acSMTP.log что-нибудь про этот фильтр написалось?
Нет. А там разве про фильтры пишется? Не, все спокойно. Только параметры загрузки. Вот конец его:
[Temp] : Temp[noname2] S" *@mynewdomain.tld" S@ ; 40 Ok SNMP:starting... acSMTP/4.24 SNMP server: 25 :
wikipost
matveeva14.10.2010 15:19
ac пишет: Как именно там записана строка, которая должна была сработать?
Что-то забыла ответить... Так и записана. Целиком
guffantishowroom@gmail.com
На отдельной строке. И записана правильно, т.к. эти отправители (чтоб им всем!) еще и на другие адреса рассылают письма — на наши корпоративные. Которые приходят сразу к нам на сервер, и на них напускается другой фильтр, про который я выше упомянула. И прекрасно все срабатывает:
2010-10-14 14:08:25;209.85.216.178;@;587;436;IN;MAIL FROM:<guffantishowroom@gmail.com> 2010-10-14 14:08:25;209.85.216.178;@;587;436;FILTER;guffantishowroom@gmail.com;;;FromBlacklList;mailfrom
wikipost
ac14.10.2010 17:46
Использовать один и тот же список для анализа конверта и заголовков — хорошая идея, но в заголовке "From:" адрес ведь записан иначе:
matveeva пишет:
From: GUFFANTI OLEG <guffantishowroom@gmail.com>

"guffantishowroom@gmail.com" с ней не совпадает. Если надо, чтобы совпало, добавьте маски — *guffantishowroom@gmail.com*.
wikipost
ac14.10.2010 17:58
matveeva пишет: А там разве про фильтры пишется?

При ошибках.
wikipost
matveeva14.10.2010 20:26
ред: 14.10.2010 20:28
А почему тут не смайлика, стучащего себя по лбу
Точно, дело в этом! Так и надо делать. Замылился глаз уже. Спасибо в очередной раз.
wikipost
matveeva19.10.2010 08:02
Что-то опять не получается.
Есть письмо с заголовком:
From: "Showroom" <showroom@pois.tv>

Есть фильтр:
Название FromBlacklList_Redirect Включен? да Стадия протокола header Заголовок From ..\FromBlack.txt Правило Выполнить runInternal с параметрами CloseConnection FALSE

Есть строка в ..\FromBlack.txt
*showroom@pois.tv*

И письмо этим фильтром не ловится, хотя должно. Вот журнал:
2010-10-18 19:00:55;194.186.47.92;@;416;3168;IN;MAIL FROM:<aori@co.ru> SIZE=909418 2010-10-18 19:00:57;194.186.47.92;@;416;3168;OUT;250 aori@co.ru OK 2010-10-18 19:00:57;194.186.47.92;@;416;3168;IN;RCPT TO:<sekr@aori.co.ru> 2010-10-18 19:01:28;194.186.47.92;@;416;3168;OUT;250 sekr@aori.co.ru OK, ExDelivery:Local, a=L 2010-10-18 19:01:28;194.186.47.92;@;416;3168;IN;DATA 2010-10-18 19:01:28;194.186.47.92;@;416;3168;SPOOL;..\DATA\mail\spool\aori@co.ru!416!376465578!1.eml 2010-10-18 19:01:28;194.186.47.92;@;416;3168;OUT;354 send the mail data, end with . 2010-10-18 19:01:31;194.186.47.92;@;416;3168;FILTER;aori@co.ru;sekr@aori.co.ru;;clear_admin_big_letter;dataend 2010-10-18 19:01:31;194.186.47.92;@;416;3168;OUT;250 OK message accepted for delivery (alias or copy) 2010-10-18 19:01:31;194.186.47.92;@;416;3168;ARCHIVE;aori@co.ru;safemail@aori.co.ru;ExDelivery:Archive 2010-10-18 19:01:31;194.186.47.92;@;416;3168;INDEX;2812 2010-10-18 19:01:31;194.186.47.92;@;416;3168;DELIVERY;clear_admin@aori.co.ru; 2010-10-18 19:01:32;194.186.47.92;@;416;3168;INDEX;861 2010-10-18 19:01:32;194.186.47.92;@;416;3168;DELIVERY;sekr@aori.co.ru;ExDelivery:Local 2010-10-18 19:01:32;194.186.47.92;@;416;3168;INDEX;2268 2010-10-18 19:01:32;194.186.47.92;@;416;3168;IN;QUIT 2010-10-18 19:01:33;194.186.47.92;@;416;3168;OUT;221 Goodbye.
Здесь срабатывает другой фильтр, добавляющий получателя при превышении размера письма. Но отвергающий фильтр " FromBlacklList_Redirect" тоже должен был сработать? Я что-то опять забыла?
wikipost
pig19.10.2010 18:11
Упомянутая строка в списке случайно не самая первая?
wikipost
matveeva20.10.2010 07:45
pig пишет: Упомянутая строка в списке случайно не самая первая?
Не, в середине. Первая у меня пустая.
wikipost
ac20.10.2010 16:43
Моя ошибка — значения полей заголовков письма не проверялись по файлу, ожидалась inline-маска. Исправление: http://www.eserv.ru/download/acSMTP4_2010-10-20.rar
wikipost
matveeva21.10.2010 09:07
Уфф.. А то я уже весь мозг сломала — что не так сделала. ))
wikipost
matveeva21.10.2010 09:43
ред: 21.10.2010 10:43
После замены acSMTP почта не отправляется. В логе ошибки:
EXCEPTION! CODE:C0000005 ADDRESS:005BBE9E WORD:fgets USER DATA: 02050654 THREAD ID: 00000E98 HANDLER: 0235EF4C ** Exception time: Thu, 21 Oct 2010 10:27:30 +0400 ** Thread number/reuse/id:44 0 3736 ** API Calls: GetTickCount sqlite3_finalize STACK: (3) 7FFAF000 0000026C 00000000 00000000 0060041D 00000004 [00000000] RETURN STACK: 0235EF24 : 005BC00C FGETS 0235EF28 : 005D1435 ReadData1 0235EF2C : 00553294 (LocalsExit) 0235EF30 : 00000014 0235EF34 : 02360AAC 0235EF38 : 02360A9C 0235EF3C : 00000000 0235EF40 : 02360A7C 0235EF44 : 00000084 0235EF48 : 00555194 CATCH 0235EF4C : 0235EF5C 0235EF50 : 0235FFB4 0235EF54 : 005D17F7 ReadData 0235EF58 : 00555194 CATCH 0235EF5C : 0235EF7C 0235EF60 : 0235FFB4 0235EF64 : 00600674 smtp\DATA 0235EF68 : 005B57C2 EvalRules 0235EF6C : 005B5DD9 EvalRules 0235EF70 : 00000009 0235EF74 : 005D28B8 DATA 0235EF78 : 00555194 CATCH 0235EF7C : 0235EFB0 0235EF80 : 0235FFB4 [...] 0235EF98 : 005D1D3A SetPreferredDns: 0235EF9C : 005BC8EA DoCommand 0235EFA0 : 00553294 (LocalsExit) 0235EFA4 : 00000004 0235EFA8 : 005D1D3A SetPreferredDns: 0235EFAC : 00555194 CATCH 0235EFB0 : 0235EFF0 0235EFB4 : 0235FFB8 0235EFB8 : 00568181 EVALUATE-WITH 0235EFBC : 00000006 0235EFC0 : 00000000 0235EFC4 : 00000000 0235EFC8 : 02051AA0 0235EFCC : 00000000 0235EFD0 : 00000000 0235EFD4 : 00000000 END OF EXCEPTION REPORT

Вернула пока предыдущий вариант.
wikipost
ac21.10.2010 16:17
Это после срабатывания указанного фильтра, или вообще для всех соединений? Я до запуска этой версии в обновления погонял её на нашем сервере (и сейчас там), всё нормально... Похоже, что именно этот фильтр — не нравится серверу закрытие сокета прямо во время приёма письма. Сейчас перепроверю.
wikipost
ac21.10.2010 16:35
Да, CloseConnection посреди сессии приводит к неожиданному для fgets обнулению указателя. Неправильную я рекомендацию про CloseConnection выдал, но теперь должна нормально обрабатываться и такая ситуация. http://www.eserv.ru/download/acSMTP4_2010-10-21_1.rar

Учтите только, что такой обрыв сеанса может приводить (и должен приводить в случае с правильным MTA) к тому, что отправитель будет снова и снова пытаться отправить это письмо, нагоняя вам трафик. Это только спамеры делают обычно одну попытку. Поэтому в идеале проверку заголовка надо отложить до стадии "письмо принято", и там уже не CloseConnection делать, а выдавать отказ, как для спама.
wikipost
matveeva22.10.2010 09:14
ред: 22.10.2010 09:46
ac пишет: отправитель будет снова и снова пытаться отправить это письмо, нагоняя вам трафик
А разве стадия "письмо принято", не увеличит трафик? Там-то дело до тела не доходит, на заголовках все обрывается, а здесь письмо будет целиком приниматься? А некоторые особо одаренные отправители шлют очень тяжелые письма. А в этом списке у меня 90% точных спамеров и остальные 10% — одаренные, которые нам не нужны. Часть из них я уже и в черный список IP положила, у которых он постоянный.
Надо, наверное, делать, как в случае с IP из RBL:
550 5.7.1 Your IP [180.180.229.73] is blocked by BRBL RBL.
. Это же на уровне заголовков. У меня был вариант фильтра:
"smtpReply" "550 5.7.1 {CLIENT}, your IP is in my BlackList.
Но что-то в нем не заработало, я его отключила. То ли сессия не прерывалась, а продолжалось письмо приниматься... Не помню.
wikipost
ac22.10.2010 16:31
На этапах MAIL FROM, RCPT TO, т.е. когда письмо еще не начинало передаваться, отказы 5xx обычное дело и нормально обрабатываются всеми MTA и спамерами. А внутри DATA — это уже "транзакция", которая либо целиком проходит, либо целиком не проходит. Если там обрыв, то для отправителя это то же самое, как если бы он вообще еще ничего не пытался отправлять. И отправитель не ждет никаких ответов на заголовки внутри письма, они вообще собственно к SMTP-сессии не относятся.

Если дело дошло до стадии DATA, то тут уже поздно думать об экономии трафика. Обрыв сэкономит трафик текущей сессии, но может привести к сотне таких оборванных сессий (попыток доставки одного и того же письма), что в сумме будет больше однократного полного приёма письма.
wikipost
matveeva22.10.2010 20:31
ac пишет: Если дело дошло до стадии DATA
А у меня в этих фильтрах с CloseConnection указаны стадия headers. Это же до DATA?
wikipost
ac23.10.2010 07:04
Нет, headers (From, To, Date, Subject, Message-ID, Content-Type и т.д.) после (внутри) DATA. До DATA только HELO, MAIL FROM и RCPT TO — это не заголовки (никак не отражаются в письме), а сессионный конверт. MAIL FROM и "From:" могут не совпадать, например.
wikipost
matveeva25.10.2010 09:31
Ясно, спасибо.
wikipost
Работает на Eserv/5.05567 (10.02.2020)