E-mail -- сжатие тела писем

[Bermuda]

E-mail -- сжатие тела писем

Кому-то может показаться шуткой, но меня действительно заинтернесовала тема сжатия сообщений электронной почты. Насколько я помню в RFC об этом ничего не сказано, но меня не покидает надежда, что в будущем многие почтовые клиенты будут иметь возможность отображать сжатую инфомацию.
Насколько я знаю для web есть два решения:
- сжимать сам HTML путем удаления "ненужных" символов
- gzip -- сжатие на уровне протокола HTTP

Первое не годится для электронной почты, так как удаление даже одного переноса строки может привести к тому, что почтовое сообщение не будет доставлено. О сжатии на уровне SMTP протокола я тоже ничего не слышал.

Поделитесь опытом?

В поиске ничего схожего не нашел :-(

 

[hoster]

На сколько я знаю, на счет сжатия сообщений в RFC полная тишина (и правильно), потому что на серверной части сжать можно что угодно и как угодно, а вот на счет клиентской возникнут проблемы. Хоть на физическом уровне, хоть на транспортном уровне сжимать сообщение ОПАСНО, т.к. клиент (а их в природе мильён) ТОЧНО не декодирует сообщение. Как я понимаю, речь идет об экономии траффика, если речь идет о конкретной задачи, в конкретных условиях, то проше создать "свое программное обеспечение", т.е. "своего клиента".

 

[Фанат]

Первое не годится для электронной почты

а второе, типа - ГОДИТСЯ?
поясни-ка, будь добр, какое имеет отношение "протокола HTTP" к отправке емейлов?

и передвиньте эти теории в оффтопик, плиз.

 

[Bermuda]

Автор оригинала: Фанат
а второе, типа - ГОДИТСЯ?
поясни-ка, будь добр, какое имеет отношение "протокола HTTP" к отправке емейлов?

Да, конечно поясню. Я написал:

- gzip -- сжатие на уровне протокола HTTP

Меня интересовал вопрос есть ли аналог для SMTP.

О сжатии на уровне SMTP протокола я тоже ничего не слышал.

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

 

[Макс]

полазь по CPANу.
У перла очень много модулей, которые оптимизирует рассылки.
Там вроде были какие-то типы упаковки, но особо не интересовался

 

[Bermuda]

Автор оригинала: hoster
Как я понимаю, речь идет об экономии траффика, если речь идет о конкретной задачи, в конкретных условиях, то проше создать "свое программное обеспечение", т.е. "своего клиента".

Речь идет об оптимизации почтовой рассылки. Наш клиент RACC (http://www.racc.es/ -- королевский автомобильный клуб Испании в Каталунии) имеет 160 тысяч подписчиков и по четвергам желает рассылать свой информационный белютень (справку я привожу дабы не кричали "Спамеры пошли прочь"). Так вот, 160 тысяч сообщений. На текущий момент я достиг скорости рассылки 4 сообщения в секунду. Нетрудно посчитать, что рассылка такого количества писем займет чуть более 11 часов. В то же время наш почтовый сервер способен принимать от PHP-скрипта до 20 сообщений в секунду. Разница налицо. Пытаюсь убрать все узкие места, в частности узким местом является простой процессора при отправке письма SMTP серверу. Если бы было сжатие, то можно было бы уменьшить время отправки письма за счет увеличения нагрузки на процессор. Даже небольшой выигрыш в данном случае может сократить время рассылки белютня на 2-3 часа.

 

[Фанат]

SMTP сервер поставить поближе?

 

[Bermuda]

Автор оригинала: Фанат
SMTP сервер поставить поближе?

Ближе некуда -- Localhost. Гы, задумался, а не кидать ли письма прямо в spool почтового сервера? Надо попробовать

 

[Фанат]

узким местом является простой процессора при отправке письма SMTP серверу

так я и не понял смысла этой фразы, если

почтовый сервер способен принимать от PHP-скрипта до 20 сообщений в секунду

 

[Макс]

Bermuda
у вас SMTP или ESMTP ?
ESMTP например через pipelineng позволяет оптимизировать отпрвку писем : http://optimal.odessa.ua/Docs/RFC/rfc1854.html

 

[confguru]

Bermuda

Причем тут PHP? Только идиоты используют ПХП для рассылки
> 30 000 писем...
Все делается по другому..
и намного быстрее..

 

[xlex]

Автор оригинала: admin
Bermuda

Причем тут PHP? Только идиоты используют ПХП для рассылки
> 30 000 писем...
Все делается по другому..
и намного быстрее..

По другому - это как?
Как вообще правильно делать рассылку? Ведь у этого форума тоже есть уведомление о получении сообщения, а значит - рассылка, и сделано всё на ПХП...

Может через BCC: передавать письмо, а почтовый сервер пусть сам разбирается что к чему?

 

[Фанат]

xlex
купи себе очки

для рассылки
> 30 000 писем...

 

[Bermuda]

Автор оригинала: Фанат
так я и не понял смысла этой фразы, если

или сделал вид, ага

Есть несколько несвязанных узких мест.
1. Парсинг писем.
2. Сохранение статистики в БД.
3. Простой процессора при отправке писем серверу.

Так вот, если первые два свести к нулю, то сервер способен принимать до 20 писем в секунду, однако я думаю, что это тоже не предел, так как даже в этом случае теряем время на подключение, отправку и прочее. В это время процессор простаивает.

-~{}~ 25.05.04 09:27:

Автор оригинала: admin
Bermuda

Причем тут PHP? Только идиоты используют ПХП для рассылки
> 30 000 писем...
Все делается по другому..
и намного быстрее..

Ну, другого ответа я и не ожидал Сознаю свою ошибку: я не указал полностью все условия. Что же, дополнение: на PHP написано MVC приложение. Есть классы, классы имеют методы, эти методы нужно использовать в построении приложения или можно создавать новые. В рамках этого приложения и нужно делать рассылку. Такое уж ТЗ

-~{}~ 25.05.04 09:30:

Автор оригинала: Maxim Matyukhin
Bermuda
у вас SMTP или ESMTP ?
ESMTP например через pipelineng позволяет оптимизировать отпрвку писем : http://optimal.odessa.ua/Docs/RFC/rfc1854.html

У нас ESMTP. Спасибо, гляну. А еще мне вчера скащали про какой-то inject для qmail (у нас qmail).

 

[xlex]

Автор оригинала: Фанат
xlex
купи себе очки

Неактуально - ты опаздал лет так-этак на пять.

Кроме того, по-моему, я задал вопрос и предложил _возможное_ решение.

Ожидаемый ответ: ответ на мой вопрос и _обоснованное_ отклонение/принятие моего решения.

Ваши предложения и варианты услышать можно?

Лично для меня вопрос не праздный - вскоре встанет вопрос об отправке 1-2'000 сообщений в день. Кроме как оптимизации адресов (например, отправка сообщений одному серверу во время одной сессии а не нескольких) и работа через сокеты - у меня других идей нет...

 

[Фанат]

Ваши предложения и варианты услышать можно?

можно

1-2'000

отправляй скриптом.
будут проблемы - доложишь.

 

[valyala]

узким местом является простой процессора при отправке письма SMTP серверу

Если это - узкое место, то запускай сразу несколько процессов для отправки писем. Раздели поровну весь список мылов между всеми процессами - и пусть трудятся одновременно. Чем больше процессов, тем быстрее разошлются письма.

 

[Bermuda]

Автор оригинала: valyala
Если это - узкое место, то запускай сразу несколько процессов для отправки писем.

Я пробовал, минусом является то, что каждый дочерний процесс труднее контролировать чем один. Это ведь не просто спам-рассылка где главное отправить и не важно какими путями. Тут еще считается статистика, парсятся темплеты и т. д.