94 ответов в этой теме

[Borka]

Это с чего бы это?

У вас есть список публичных почтовых релаев?

А мне он зачем?

Несколько лет назад было засилье сусликов (ntos.exe, если кто помнит), которые детектились как Trojan.Proxy, задачей которых было поднять на клиентской машине почтовый сервер опен релей. С одной стороны - рассылает сам, с другой пересылает от других.

Только человек с альтернативными умственными способностями будет принимать с такого компа почту.

А он этого не знает.

[Полимер]

Borka, Борис, посмотри личку.

[Borka]

Угу, только что увидел уведомление. Так удобно...

ЗЫЖ Так?

[Полимер]

ЗЫЖ Так?

Лучше текстом из лички и в code, спасибо.

[basid]

Оптимизм это, конечно, хорошо. "Но есть ньюанс".
Две (независимые) сети 192.168.0/24, 192.168.10/24, почтовый сервер 192.168.10.1, концентратор, обслуживающий 192.168/16.
На концентраторе, в пакете с адреса 192.168.0.2 меняем source-IP на 192.168.10.33 и пересчитываем контрольные суммы. В ответном пакете проделываем обратную замену и снова пересчитываем контрольные суммы.
"Внимание, вопрос!" Что будет записано в логах почтового сервера и служебном заголовке Recieved?

P.S. "Упрощено до безобразия" - не значит "Невозможно".

[Полимер]

Василий А. Сидоров,
В логе принимающего сервера будет внешний IP отправляемого сервера, все остальное не волнует.

[basid]

Василий А. Сидоров,
В логе принимающего сервера будет внешний IP отправляемого сервера, все остальное не волнует.

Угу. Поддельный IP.

P.S. Не, SMTP-Auth, конечно, рулит и всё такое, но опираться на IP-адрес при вынесение приговора - я бы поостерёгся.

[Полимер]

Василий А. Сидоров,
В логе принимающего сервера будет внешний IP отправляемого сервера, все остальное не волнует.

Угу. Поддельный IP.

P.S. Не, SMTP-Auth, конечно, рулит и всё такое, но опираться на IP-адрес при вынесение приговора - я бы поостерёгся.

Вы не понимаете о чем пишете. Если бы можно было менять IP отправителя, то инет встал.

[basid]

Это вы не понимаете. Или никогда не видели сетку за NAT-ом.

P.S. Думаю, что люди профессионально занимающиеся маршрутизацией и прочими DPI могут и не так огорошить.

[pig]

Ну, NAT-то снаружи видится СВОИМ публичным адресом. А если он IP отправителя поставит 87.242.72.150 вместо своего 212.114.19.21 - кто получит ответный пакет?

[Полимер]

Это вы не понимаете. Или никогда не видели сетку за NAT-ом.

P.S. Думаю, что люди профессионально занимающиеся маршрутизацией и прочими DPI могут и не так огорошить.

Чтобы знать основы инета, не нужно быть профессионалом.

[HHH]

А я об чем? Поздно пить боржоми, письмо принято провайдером. Хороший отсеет махровый спам, спорный положит в подозрительные. А определять спам доктором на основании только содержания письма не имеет смысла.
ЗЫ. Хоститесь у нормальных провайдеров и проблем со спамом не будет или пользуйтесь вебмордой.

Моя организация отказалась от услуг такого сервера провайдера и подняла собственный почтовик именно из-за того, что провайдер начал бороться со спамом.
Этот почтовик находится на xDSL линии и проблем с доставкой почты от нас и к нам никогда не было

По RFC почтовик *обязан* принять письмо, если оно адресовано его пользователю. Даже если я с GPRS его телнетом отправлять буду. Не?

Сообщение было изменено HHH: 19 Октябрь 2011 - 20:30

[--VovanGrup--]

RFC пора переписывать)

[Полимер]

По RFC почтовик *обязан* принять письмо, если оно адресовано его пользователю. Даже если я с GPRS его телнетом отправлять буду. Не?

Смотря от кого:
1. Если вы c MUA авторизовались на нем, т.е. это ваш сервер, то да и не важно кому письмо.
2. Если это MTA и он не нарушает правил и письмо для вашего сервера, то да.
3. В других случаях нет.

[Borka]

Тут, наверное, вопрос про обязан попытаться принять. То есть минимум соединение будет установлено. А потом уже можно (и нужно) смотреть.

[HHH]

Смотря от кого:

Я, признаться, RFC читал давненько, но что-то мне подсказывает - вы не правы На отправителя там ограничений не накладывается

[Полимер]

Смотря от кого:

Я, признаться, RFC читал давненько, но что-то мне подсказывает - вы не правы На отправителя там ограничений не накладывается

RFC прописан для взаимодействия между MTA, взаимодействие MUA и MTA, говорят в RFC не определен.
Ну, если рассуждать логически, с какого бодуна мой сервер будет принимать почту с неизвестного компа?
PS. У меня прием почты снаружи не отличается, будь то MTA или MUA, т.е. для ВСЕХ MUA вход закрыт(они не пройдут проверку по правилам RFC). К сожалению, так устроен мой MTA - проверка reverse lookup проходит до авторизации. Для своих юзеров, которые хотят работать с почтой снаружи, настраиваю вебклиент.

[a1822]

А в чём дао неприёма подозрительной почты? Стопроцентной уверенности, что это спам, не бывает. Более того, зная обычаи больших начальников и закон подлости в целом, скажу: самое судьбоносное письмо ВСЕНЕПРЕМЕННО придёт на ваш почтовый сервер с динамического небекресолвящегося айпишника из блеклистнутого диапазона.

Я лично принимаю всю почту, идущую на валидные адреса. То, что распознаётся как спам, складываю в папочку "спам" и автоматически удаляю через две недели. Юзеры знают: если что-то должно прийти, но долго не приходит, надо поискать в спаме. Четыре года, полёт нормальный.

[HHH]

RFC прописан для взаимодействия между MTA, взаимодействие MUA и MTA, говорят в RFC не определен.
Ну, если рассуждать логически, с какого бодуна мой сервер будет принимать почту с неизвестного компа?

Если бы еще был способ отличить MUA от MTA, было бы совсем хорошо.

Когда я говорил про частичную подделку тех. информации, я имел в виду именно вставку нескольких фейковых received для маскировки истинного отправителя.

В общем, предлагаю завязывать, т.к. всё равно каждый при своём останется

a1822, +1 поступаю аналогично.

Сообщение было изменено HHH: 20 Октябрь 2011 - 09:27

[Полимер]

Я лично принимаю всю почту, идущую на валидные адреса.

Я берегу своих пользователей. Несколько недоразумений, которые были за 10 лет, быстро устранялись.