|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 14 Nov 2002 22:12:52
To : Spartak Radchenko
Subject : Re: Sendmail.
--------------------------------------------------------------------------------
>>> Spartak Radchenko wrote:
VN>> Что??? Hет env-to в логах? Hу это ты его так замучал, видимо.
VN>> Штатными средствами такого эффекта добиться нельзя.
SR> Да без проблем. Конфиг выслать? А вот выдержка из логов. Тестовое письмо
SR> посылалось посредством pine на адрес root@aif.ru:
SR> Nov 14 19:55:20 oberon sendmail[94064]: gAEGtKB94064: from=<spartak@aif.ru>,
SR> size=297, class=0, nrcpts=1, msgid=<20021114195506.V94016-100000@localhost>,
SR> proto=ESMTP, relay=spartak@localhost Nov 14 19:55:20 oberon sendmail[94065]:
SR> gAEGtKB94064: to=spartak, ctladdr=<spartak@aif.ru> (101/0), delay=00:00:00,
SR> xdelay=00:00:00, mailer=local, pri=30044, dsn=2.0.0, stat=Sent
SR> Ты где-нибудь видишь тут root? Я - нет.
Гм. Согласен. _Исходного_ env-to нет. Hо ведь ты слово "исходный" не сказал,
не так ли? ;)
А по отношению к root ответ очень простой - если ты возишься с
sendmail достаточно давно, ты должен был понять, что LogLevel должен быть
не менее 11 (а не 9 как по дефолту). Во многих случаях можно ставить даже 14.
SR>>> Пусть сначала MTA научатся подписывать хедеры. А то проверять нечего.
SR>>> Кстати, по-моему, это было бы вполне реализуемое и достаточно полезное
SR>>> расширение SMTP.
VN>> И как ты потом их проверять собрался? С цепочкой сертификатов с Verisign
VN>> в ее конце?
SR> А почему бы и нет? В большинстве случаев там всего 2 received и будет,
SR> причём последний подписывать незачем.
Hачни обсуждение в antispam, email-security, если получится что-то
осмысленное в результате такой работы - переходи в ietf, готовь draft
на RFC... Препятствий нет. Работать только никто не хочет. А за такую
твою идею вряд ли кто-то кроме тебя работать будет, особенно вначале ;)
SR>>> С другой стороны, почему юзер должен
SR>>> иметь доступ к логам?
VN>> К логам своей почты - должен иметь доступ.
SR> К логам сервера (например, провайдерского) юзер доступа не имеет.
SR> Или ты о чём?
В LN мы даем логи тем, кто их просит. Выдержки по своим письмам, естественно,
а не все логи ;) Просят так мало (раз в месяц или реже), что ручные действия
ребят из техподдержки достаточны.
SR>>> А envelope to ему знать полезно, меньше будет
SR>>> вопросов типа "Почему ко мне пришло это письмо, там нет моего адреса?".
VN>> Агащаззблин. Воттакойтена. Будет он куда-то смотреть, кроме того, что
VN>> ему штатно показывает аутлук. Размечтался.
SR> Ты неявно подразумеваешь, что Outlook меняться не будет, даже если
SR> протокол SMTP вдруг изменится. А почему, собственно? Мечтать так
SR> мечтать.
А, ты еще и о смене протокола? Кстати, при чем тут протокол?
Outlook вообще предпочитает работать по MAPI, если в нем есть поддержка;))
SR>>> Вот подписали меня тут на рассылку. Я потребовал от хозяина убрать
SR>>> нафиг мой email из списка. И тут выяснилось, что я не знаю, на какой
SR>>> именно email идёт рассылка. Алиасов-то много. Рубить эту рассылку
SR>>> на корню не стоит, отписать меня готовы. И что делать? Конечно, я
SR>>> в конце концов разобрался, но нафига такой геморрой?
VN>> Это тебе исходный envelope-to нужен, а не конечный.
SR> Пусть будут оба, я не против.
Владельцу рассылки нужен именно исходный, чтобы определить, кого и как
исключать.
/netch
--- ifmail v.2.15dev5
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
