freebsd 6.2 собственно хочется чтобы ошибки вроде #5.1.1 Sorry, no mailbox here by that name. приходили по русски (чтобы манагеры всякие понимали о чем речь)....
погуглил пояндексил и поопенеетил не наткнулся... щас полезу в маны кумыла но если кто знает куда ткнуть ткните плиз )
Нужно править исходники. Где - не помню. Сделай поиск файлов, содержащих "Sorry, no mailbox here" и т.д.
ee /var/qmail/bin/qmail-local попробовал поправить и он отвалился )
естессно перед правкой скопировал его в нужное место а потом оттуда восстановил и все заработало
исходники нужно править, а потом пересобирать qmail.
>freebsd 6.2 собственно хочется чтобы ошибки вроде #5.1.1 Sorry, no
>mailbox here by that name. приходили по русски (чтобы
>манагеры всякие понимали о чем речь)....
>погуглил пояндексил и поопенеетил не наткнулся... щас полезу в маны кумыла но
>если кто знает куда ткнуть ткните плиз )А с каких пор в протоколе SMTP разрешено использовать символы, не входящие в US-ASCII (то бишь с кодами больше 127). В RFC 2821 ЧЕТКО СКАЗАНО СЛЕДУЮЩЕЕ (в разделе 2.4):
Commands and replies are composed of characters from the ASCII
character set [1]. When the transport service provides an 8-bit byte
(octet) transmission channel, each 7-bit character is transmitted
right justified in an octet with the high order bit cleared to zero.
More specifically, the unextended SMTP service provides seven bit
transport only. An originating SMTP client which has not
successfully negotiated an appropriate extension with a particular
server MUST NOT transmit messages with information in the high-order
bit of octets. If such messages are transmitted in violation of this
rule, receiving SMTP servers MAY clear the high-order bit or reject
the message as invalid. In general, a relay SMTP SHOULD assume that
the message content it has received is valid and, assuming that the
envelope permits doing so, relay it without inspecting that content.
Of course, if the content is mislabeled and the data path cannot
accept the actual content, this may result in ultimate delivery of a
severely garbled message to the recipient. Delivery SMTP systems MAY
reject ("bounce") such messages rather than deliver them. No sending
SMTP system is permitted to send envelope commands in any character
set other than US-ASCII; receiving systems SHOULD reject such
commands, normally using "500 syntax error - invalid character"
replies.Eight-bit message content transmission MAY be requested of the server
by a client using extended SMTP facilities, notably the "8BITMIME"
extension [20]. 8BITMIME SHOULD be supported by SMTP servers.
However, it MUST not be construed as authorization to transmit
unrestricted eight bit material. 8BITMIME MUST NOT be requested by
senders for material with the high bit on that is not in MIME format
with an appropriate content-transfer encoding; servers MAY reject
such messages.И ТОЧКА. Ибо это есть СТАНДАРТ.
о_О спасибо огромное этого делать не буду... и буду тыкать(в керио например можно поставить русский репорт отчет... слава богу эту дрянь не использую)
есть ли какой то выход из положения для манагеров (кроме учить английский) ?
как вариант сделать им html с расшифровками на корпоративном сайте... а еще идеи?
>есть ли какой то выход из положения для манагеров (кроме учить английский)Увы, в рамках протокола SMTP иного варианта нет. А насчёт расшифровки, лежащей на корпоративном сайте идея дельная.
P.S. Во всём мире английский язык принят как стандартный язык общения пилотов с наземными службами. И ничего, учат наши пилоты, летающие по международынм линиям английский.
Давайте немного разберем ситуацию. При отправке письма есть отсылающий MTA и принимающий. Если принимающий по какой либо причине не может принять письмо он выдает ошибку на подобии описанной вами. Этот ответ действительно должен быть в ascii и желательно на английском. А вот передающий MTA должен создать так называемый bounce-back, то есть письмо(в отличии от сообщения smtp сессии), в котором в вежливой и доступной пользователю форме сообщается о проблеме, а заодно приводится ответ принимающего MTA.
Внимание вопрос, что из этого вы хотите сменить: ответ своего MTA в smtp сессии при приеме или письмо об ошибке своего MTA при неудавшейся передаче?
письмо об ошибке своего MTA при неудавшейся передаче
Угу боунс-бэк! порекомендуете чтонить?
похоже вот эту дрянь надо где то поискать )))
Hi. This is the qmail-send program at mail.newhost.ru.
I‘m afraid I wasn‘t able to deliver your message to the following addresses.
This is a permanent error; I‘ve given up. Sorry it didn‘t work out.это есть в qmail-send... думаю его тоже через исходники пересобирать...
но это только шапка...
гуглить умею и не пренебрегаю
>похоже вот эту дрянь надо где то поискать )))
>Hi. This is the qmail-send program at mail.newhost.ru.
>I‘m afraid I wasn‘t able to deliver your message to the following
>addresses.
>This is a permanent error; I‘ve given up. Sorry it didn‘t work
>out.
>
>это есть в qmail-send... думаю его тоже через исходники пересобирать...
>но это только шапка...
>гуглить умею и не пренебрегаютоже таким вопросом заинтересовало
http://www.opennet.me/openforum/vsluhforumID1/79710.html
скажу не нашел :(
в общем можно только отправителя и т.п. поменять(как я докопал)
если вы что нить выкопали с пере сборкой пожалуйста отпишитесь