Ticket #43 (closed требование: duplicate)

Opened 1 year ago

Last modified 1 year ago

Алгоритм работы CEmail

Reported by: teiko Assigned to: teiko
Priority: Блокирующий Milestone: EContact 2
Component: cemail Version: 0.1
Keywords: Cc:
Working_time: state: discussion
Time_estimation:

Description

  • Пользователь вводит адрес
  • После нажатия на кнопку, введенный адрес отправляется серверу на краткую проверку
  • Пользователю выводится прелоадер "Подождите, идет проверка данных..."
  • На сервере проверяются синтаксис и существование домена (довольно быстро)
    • Если адрес прошел эту первичную проверку, компонент ввода получает сообщение о том, что адрес верен
      • Если все поля верны, информация о пользователе отсылается на сервер
      • Введенный email добавляется в базу и проверяется дополнительно через SMTP-запрос на почтовый сервер (в фоновом режиме на Perl, долго, до 30 сек)
        • Если адрес верный, то A
        • Если адрес неверный, то B
    • Если не прошел, то поле обводится красным, пользователя просят ввести адрес повторно

Вопросы

  1. Что делать в случах A и B
  2. Что вообще делается с этими email'ами? Почему нельзя просто отослать информацию по всем адресам? Если они неправильные, то просто не придет информация.

Change History

01/03/08 22:39:53 changed by teiko

  • summary changed from Уточнение архитектуры CEmail to Алгоритм работы CEmail.

01/04/08 00:04:08 changed by Syndicus

В любом случае запрос адреса у пользователя прекращается (адрес утверждается как действующий) только после прихода результата проверки через SMTP. Отрицательный результат имеет причину, которую нужно отобразить пользователю в доп. окошке с вопросом, действительно ли он подтверждает существование адреса, или хочет его изменить ("Убедитесь что адрес ввёден правильно, или укажите другой адрес. На данный адрес письмо может быть не доставлено"). В случае непрохождения краткой проверки вопрос, думаю, неуместен. Глупо принимать адреса на несуществующих доменах.

(follow-up: ↓ 4 ) 01/04/08 00:05:56 changed by Syndicus

По вопрос №2 Наша проверка - абстрактная, и всё равно, что делается с адресами. Они могут добавляться в базу, по ним могут происходить действия. Случай "просто не придёт информация" плох тем, что мы об этом не узнаем, и будем считать, что письмо ушло, а оно может быть важным.

(in reply to: ↑ 3 ; follow-up: ↓ 5 ) 01/04/08 00:21:40 changed by teiko

Replying to Syndicus:

По вопрос №2 Наша проверка - абстрактная, и всё равно, что делается с адресами. Они могут добавляться в базу, по ним могут происходить действия. Случай "просто не придёт информация" плох тем, что мы об этом не узнаем, и будем считать, что письмо ушло, а оно может быть важным.

  1. Непонятно, что настолько важного может быть в адресе, и почему нельзя просто дополнительно предупредить пользователя о том, что эта информация важна для нас, и что адрес не будет никуда рассылаться. Или просить дополнительно проверить адрес - два поля или другим способом. Кроме того, можно попросить пользователя написать нам, если ему не пришло письмо, указав, например, номер запроса. Пользователи не такие уж и тупые, и им тоже можно доверять часть ответственности.
  2. Люди сейчас привыкли к быстрому интернету и без веских причин никто не будет сидеть и ждать, пока проверится его адрес.

(in reply to: ↑ 4 ; follow-up: ↓ 6 ) 01/04/08 00:41:28 changed by Syndicus

Replying to teiko:

1. Непонятно, что настолько важного может быть в адресе, и почему нельзя просто дополнительно предупредить пользователя о том, что эта информация важна для нас, и что адрес не будет никуда рассылаться. Или просить дополнительно проверить адрес - два поля или другим способом.

Например нас адрес почты служит паролем к странице отгрузки товара, и высылается товар на этот адрес, и стоит он достаточно много денег, чтобы люди звонили и спрашивали где их письмо, а я должен ползать по логам почтовика и выяснять, где же письмо :) Естественно проверку надо делать в том случае, если адрес важен. Нельзя же игнорировать невведённый адрес в форме, которая предназначена исключительно для запроса адреса :) Про дополнительную проверку я написал в 53-м тикете.

Replying to teiko:

Кроме того, можно попросить пользователя написать нам, если ему не пришло письмо, указав, например, номер запроса. Пользователи не такие уж и тупые, и им тоже можно доверять часть ответственности.

Да, вот попросить написать нам (желательно с другого адреса), это хороший вариант.

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

1. Адрес в нормальном случае проверяется секунды 3-4, разве нет? 2. А долго ждать и не надо, у нас таймаут есть. 3. Кому надо - подождёт, что же делать.

(in reply to: ↑ 5 ) 01/04/08 00:48:33 changed by teiko

Replying to Syndicus:

Replying to teiko:

1. Непонятно, что настолько важного может быть в адресе, и почему нельзя просто дополнительно предупредить пользователя о том, что эта информация важна для нас, и что адрес не будет никуда рассылаться. Или просить дополнительно проверить адрес - два поля или другим способом.

Например нас адрес почты служит паролем к странице отгрузки товара, и высылается товар на этот адрес, и стоит он достаточно много денег, чтобы люди звонили и спрашивали где их письмо, а я должен ползать по логам почтовика и выяснять, где же письмо :)

А если у человека с одного адреса заказано несколько товаров от нескольких людей? И нельзя ли сразу сообщить пользователю пароль, прямо на страничке, а не через email?

Естественно проверку надо делать в том случае, если адрес важен. Нельзя же игнорировать невведённый адрес в форме, которая предназначена исключительно для запроса адреса :) Про дополнительную проверку я написал в 53-м тикете. Replying to teiko:

Кроме того, можно попросить пользователя написать нам, если ему не пришло письмо, указав, например, номер запроса. Пользователи не такие уж и тупые, и им тоже можно доверять часть ответственности.

Да, вот попросить написать нам (желательно с другого адреса), это хороший вариант.

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

1. Адрес в нормальном случае проверяется секунды 3-4, разве нет? 2. А долго ждать и не надо, у нас таймаут есть. 3. Кому надо - подождёт, что же делать.

01/04/08 01:08:39 changed by Syndicus

Варианты использования мы можем обсудить отдельно, постановку задачи это не отменяет. Я привёл существующую у нас схему работы для иллюстрации ситуации, в которой cemail был бы полезен. Варианты "как организовать работу так, чтобы cemail стал не нужен" не обсуждаются :)

А сообщать пользователю пароль на страничке - это чтобы этот пароль получил кто угодно и потом им успешно пользовалось полмира? :)

Мы не сообщаем пароль по почте, сам адрес почты является паролем.

И нам конечно же всё равно от скольки людей заказан товар на email, мы общаемся с владельцем e-mail.

01/04/08 14:09:46 changed by teiko

Хорошо, будем делать. Но предвижу следующие трудности:

  1. Все адреса на mail.ru определяются как валидные. При этом игнорировать этот домен считаю неправильным, так как им пользуется огромное число народу, в том числе и серьезные люди. Наверняка существует еще масса подобных доменов.
  2. На некоторых доменах можно вообще не дождаться ответа, например, на сервисе email-validator мы так и не дождались проверки адреса с yandex.ru
  3. На том же сервисе проверка адресов проверяется довольно долго, от 15 секунд. Долго проверялся, например, atermath@atermath.com и teiko@etersoft.ru (сейчас они уже в кэше). У нас, думаю, быстрее проверяться не будет.

P.S. Можешь не отвечать, но эти вопросы остались у меня в голове: По поводу того, что адрес почты является паролем - разве нельзя отправить письмо с чужого адреса? Какая выгода, для чего это кому-то делать - узнавать пароль - чтобы получить заказ на себя? А оплата? Где везде так делают? Везде отправляют письмо со ссылкой, нажатие на которую подтверждает существование email'а, пользователи к этому привыкли и им не нужно сидеть ждать на сайте.

01/06/08 09:59:43 changed by teiko

  • status changed from new to closed.
  • resolution set to duplicate.