|
ru.unix
- RU.UNIX ----------------------------------------------------------------------
From : Artem Chuprina 2:5020/400 15 Dec 2004 17:03:37
To : Valentin Davydov
Subject : Re: postfix q
--------------------------------------------------------------------------------
Valentin Davydov -> Artem Chuprina @ Wed, 15 Dec 2004 09:36:24 +0000 (UTC):
>> >> >>>> VA> smtpd продолжает принимать data от клиента, если объём
>> >> >>>> VA> превысил message_size_limit, ожидая точки. Можно ли (и
>> >> >>>> VA> как) сделать, чтобы он отвечал кодом 5xx (возможно, с
>> >> >>>> VA> разрывом коннекта) не дожидаясь точки? Hасколько это
>> >> >>>> VA> будет соответствовать стандартам и общепринятой
>> >> >>>> VA> практике?
>> >> >>>>
>> >> >>>>Если он ответит кодом 5xx и разорвет коннект, к нему
>> >> >>>>ломанутся опять.
>> >> >>
>> >> >>VD> И получат 552 сразу же на DATA.
>> >> >>
>> >> >> а там уже другое письмо, хотя sender and recipient те же
>> >>
>> >> VD> А нехрен было слать первое.
>> >>
>> >>... а на том конце сервер таки отработал 5xx в первый раз, несмотря на
>> >>грубое нарушение протокола (be liberal in what you accept),
>>
>> VD> 552 - это storage exhausted. Вполне логичная реакция на перегрузку
>> VD> трафиком. Какой именно пункт rfc821 нарушен?
>>
>>Грубое нарушение протокола - это 5xx не в очередь
VD> Hу, пусть не на DATA, а на RCPT TO. Здесь-то уж 552 разрешено явно.
Да нет, в первый раз. В процессе получения данных по превышении лимита.
>>и разрыв коннекта в первый раз.
VD> If the connection is closed prematurely the receiver should
VD> act as if a RSET command had been received (canceling any
VD> pending transaction, but not undoing any previously
VD> completed transaction), the sender should act as if the
VD> command or transaction in progress had received a temporary
VD> error (4xx).
Hе по отдельности, а вместе. Просто разорвать коннект, конечно, можно,
но это 4xx по определению.
>> >>вернул
>> >>письмо пославшему, и тот его честно порезал на кусочки... И это как раз
>> >>кусочек шел...
>>
>> VD> Типа, если 10 мегов мусора порезать на 100 кусков мусора по 100
>> VD> килобайт, он от этого мусором быть перестанет? IMHO, юзеров,
>> VD> которые пишут письма в Microsoft Paint и посылают в виде bmp 48
>> VD> бит на пиксель, надо учить.
>>
>>А если это не Microsoft Paint, а AutoCAD, и все 10 мег там по делу?
VD> Если надо по делу, пиши администратору, можем хоть 100 гиг
VD> персонально для вас зарезервировать, за отдельную плату,
VD> естественно.
И это в сообщении со вторым 552 прямо вот так и сказано? И каково
гарантированное время реакции?
>>С какого перепугу (а ты это делаешь явно с перепугу, по нервному тону
>>видно) ты полагаешь, что если письмо большое, то это непременно
>>мусор?
VD> Опыт. Человек не в состоянии за разумный промежуток времени
VD> сгенерить больше нескольких сотен килобайт содержательной
VD> информации, если письмо большое - значит, там либо нули незначащие,
VD> либо он эту информацию откуда-то из Интернета вытянул, либо ещё
VD> что-нибудь в том же духе.
Естественно вытянул. Сэр готов предоставить сервис по отделению
картографической подложки от пользовательских изменений в AutoCAD и
предоставления возможности адресату выкачать (ни разу не свободно
распространяемую) подложку отдельно? Hа машине пользователя? Если нет
- то за отдельные деньги сэр будет объяснять, почему он письмо по частям
не принял, и две недели тормозил с подъемом лимита.
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: ran@jabber.ran.pp.ru
--- ifmail v.2.15dev5.3
* Origin: Leninsky 45 home network (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
