Чтобы точно разобратся где проблема - в php или mysql попробуйте вставить большой текст SQL функцией:
insert into t1 (text_field) values (repeat('a', 6000));
а потом посмотрите, что реально вставилось:
select length(text_field) from t1;
Внедрите свою систему хотя бы у средненького провайдера на пару десятков тысяч юзеров (где есть и физики и корпоратив), тогда и будет о чем говорить. Ну и посмотрите как уникальные антиспам фичи, внедеренные повсеместно и ставшие стандартом, обходится спаммерами за пару месяцев экспериментов. Это обычная война брони и снаряда и пока не будет подорвана экономика спама бороться технически трудно. И что делать с юзерами, которые используют кпк/мобилы и не всегда имеют возможность видеть графику (капчу) или корпоративщики, не имеющие доступа к вебу (а только к к почте) ... да мало ли нюансов, которые выльются в головную боль службы поддержки.
Кроме того, Вашу систему можно будет неплохо DOSить - тупо создавая письма с несуществующих адресов, чтобы забить Вашу же очередь доставки письмами с капчами.... Или (что хуже) попытатся Вам отправить 100К писем с адресами из mail.ru - и Ваша система создаст честно 100к чаллендж-респонзов и будет их пихать на mail.ru - 20мин - и Вы в блэк-листе по превышению лимита кол-ва писем с одного IP. Еще и можно и в ORBL загреметь.
Это Вы реально не работали с мало-мальски серьезной почтовой системой.
Идея с подтверждающей капчей уж давно была известна, однако никто из крупных почтовых систем ее не внедрил ... наверное есть серьезные причины на это.
p.s. Так как дискуссия скатилась к "сам дурак" ... и ни одного ответа на свои вопросы не услышал, то не вижу смысла дальше в ней участвовать.
Вы сначала ее поднимите хотя бы для 10к ящиков, а потом уж говорите. Если каждый юзер будет иметь хотя бы 100 подтвержденных адресов (которые прошли проверку капчей), то ваша база подтвержденных адресов будет уже составлять 100x10к=1м. Я поэтому и спрашивал -как хранится этот список?. Т.е. придется еще БД поднимать. Или у Вас он текстовом файлике лежит ? :)
А в нынешней ситуации для почтового сервера для 10к юзеров нужен один не очень мощный сервер - однопроцессорный от 3Гц, 2 Гига памяти и 200 гигов хард (постфикс, ассасин, антивирус). А для Вашей идеи придется поднимать второй - с БД.
Кроме того, Вы так и не объяснили как защитится от спама, если спамер украл валидные адреса? Все схема к черту. Скажу больше - спамер может писать from/to один и тот же адрес - с высокой вероятностью этот адрес будет валидным, так как когда юзер настраивает почту, то обычно шлет сам себе письмо.
Знаете, существующая схема грей-листов получше будет - спамеру по крайней мере нужно повторить попытку отправки письма с того же IP в указанный период ... т.е. комп из ботнета должен быть в апе - а не факт, что это так будет.
В принципе кому-то под проект как короткое дополнительное имя пойдет.
Кстати, кто с Украины - там есть несколько неплохих доменов ua*.com - хватайте :)
Ну php можно заменить на perl/с (но это уже CGI), а mysql на postgres, oracle. Хотя mysql 5.x сильно подтянулся к "взрослым" RDB, сильно расширен SQL (процедуры, views, triggers), да и расширяемость улучшена (репликации, кластер). И все это бесплатно.
Апач - скорее всего не заменить, если брать *nix платформу
Я лишь возразил, что Ваша система неудобна и неприменима для служб от несколькич тысяч ящиков ...
Ну сделать кучу реальных адресов - это 2 бакса за домен в .info. Недорого, чтобы прогнать одну рассылку, правда? Кстати уже сейчас многие почтовики проверяют наличие адреса в домене отправителя, тем не менее это обходится.
Если Вы привяжете Ваш все на капчу проверки отправителя, то во-первых это удлиняет время доставки письма. Обычному юзеру придется отправить письмо, подождать респонз, подтвердить его и только потом письмо будет доставлено. Хотя это только для первого письма.
А что мешает спамеру скидывать полученную капчу куда-нить на порногалерею и получать код оттуда? Ведь сейчас так работают некоторые спамилки по дорам.
Кроме как только спамер утянет Ваш inbox/outbox, то автоматически получит:
- валидные для Вас адреса для поля from
- ваш адрес как валидный для поля to
Думайте хотя бы на шаг вперед. Как только Ваша идея будет внедрена повсеместно, спамеры придумает ответное решение.
Я может и не знаю спамерских программ, но собственно имею опыт работы с несколькими десятками тысяч ящиков в провайдерской конторе и могу сказать, что однозначно определить спам по внешним признакам трудно. То, что работает на 50 ящиков уже не будет работать на 50к. Просто у Вас было очень нестандартное решение, про которое спамеры не знали или не хотели связыватся в силу малости юзеров.
Кстати, чисто технические вопросы:
Список валидных адресов для каждого юзера - индивидуальный или общий для почтового сервера?
Как и где хранится это список?
Ну а что мешает спамеру поднять почтовик и отвечать на challenge-response?
На самом деле подорвать спам можно только с экономической стороны ... на всякое технический изыск найдется решение. Ведь принципиально спамер не отличается от обычного пользователя. Ну может только в кол-ве отсылаемых писем.
Работа по белым спискам уже не выход. Современные спамеры собирают адреса с помощью троянов, сграбливая поле To: из папки Исходящие и From: из Входящих. Ничто не помешает спамеру иметь общую базу адресов состоящую из пары адресов - email_to, email_from - т.е. для каждого письма спамер будет представлятся индивидуально в поле From: .
Более реально бороться со спамом - это иметь для каждого email адреса сертификат по типу SSL, который стоит денег (пусть 1-2 у.е. в год) и счетчики отправок (годовой, месячный, суточный, часовой). Например, почтовый сервер принимает письмо с адреса vasya@hotmail.com. Сначала проверяет, что валидность приложенного сертификата для этого адреса. Если нет - то спам. Если ОК, то запрашивается счетчик отправок - если за сутки с этого адреса было сделано более 1к писем - то нафиг его.
В данном случае спаммер может купить сертификаты, но это сделает невыгодным рассылку, так как на 1М адресов придется купить как минимум 1к сертификатов - а это уже затраты. А рассылать с левых адресов - смысла нет.
Ну а для легальных рассылок сертификат должен стоить других денег.
Вообще я имел в виду только растровые изображения и брать только матрицу пикселов из графического файла. В данном случае один и тот же рисунок, сохраненный в разных форматах разными программами без потерь будет иметь одну и ту же матрицу пикселов, приведенную к 24 битной или 48 битной основе.
Поэтому и контрольные суммы совпадут.
В данном понятии одинаковые растровые рисунки - это рисунки сопадающие по-пиксельно.
При чем тут программы, плагины фотошопа?
А разрешение - это вообще параметр для печати фактически.
