Здравствуйте, Stanislaw K, Вы писали:
S>>Когда в Телеграм отправляешь сообщение — ты видишь получил пользователь или еще нет.
SK>Image: 2025_04_05_16_34_26_изображение.png
Ну йпрст. Ты понимаешь чем отличается прочтение от получения?
Когда ты отправил письмо — важно знать принял ли его пользователь или нет. Если не принял — требует авторизации — ты более и отправлять не будешь а лишь проверять статус авторизации или делать запрос на авторизацию.
Прочел или нет — это уже да, пользователь может настроить — его право.
S>>Или если сервер телеграма не доступен — видишь что отправка не состоялась. Разумно? Разумно.
SK>Телеграм — не почта. телеграм принципиально другой класс приложений. messenger. просто messenger и даже не instant кстати. И нет, он не гарантирует доставку.
Важно что ты видишь — доставлено или нет. Гарантии быть не может — но важно понимание было ли доставлено. И это все меняет.
Если ты не авторизован пользователем — то нужно сразу об этом знать а не пытаться что-то отправлять.
SK>Это твоя проблема. сервер получателя может находится за модемом 14400 и выходить на связь 2 раза в сутки по 30 минут. Или 1 раз в неделю.
Нет, это твоя шиза. Сейчас сервер за $5 имеет доступность 99.95.
Не примешивай свою шизу и веру в то что 2000-е вернуться к современным технологиям. И тогда почтовые сервера гигантов (MS) — были постоянно доступны и на этом деражалась инфраструктура.
SK>Или, чаще бывает, между датацентром с "твоим" почтовым сервером и датацентром с сервером получателя оборвалась оптическая магистраль. за секунду до того, как ты нажал кнопку send.
Ну и? Будет в статусе "не доставлено". Пользователь то все-равно не получит.
SK>Перестроение tcp/ip на новый маршрут через другую магистраль для второстепенного трафика занимает (несколько минут).
Вот через несколько минут и будет доставлено — в чем проблема?
SK>Высокоприоритетный трафик реального времени — несколько секунд, для "нормального" десятки секунд а почта по остаточному принципу. SK>Потому что никто не умрет, если письмо придет через 15 минут или даже через час.
Важно чтобы ты знал пришло оно на сервер назначения или нет а так же принято или не авторизовано.
SK>"vpn" тут совершенно не при чем. лишняя сущность, которая только вносит в твои рассуждения ненужную сумятицу. просто забудь.
Еще как причем. Если сервер в РФ и заблокирован в некой стране — то только VPN поможет доставить письмо.
S>>Если вы не можете зайти на сайт, который не доступен напрямую — вы что делаете? SK>Ничего не делаю.
Т.е. ты не знаешь как обойти блокировку до сих пор?
S>>Очередь никто не отменял — прока письмо в очереди — у тебя крутился. Если возможностей одного физического сервера не хватает — расширяйте инфраструктуру — Kubernetes для чего придумали? SK>Не для этого.
Про горизонтальное масштабирование что-нибудь слышал?
SK>>>4) очевидно, все пользователи будут сидеть в веб интерфейсе. S>>Не важно — вариантов доступа может быть много — и моб., и веб. Сейчас моб. и веб практически не отличаются — рендер то весь в браузере — а доступ к тем же JSON API.
SK>вот именно. не отличается.
И что ты хотел сказать?
SK>>>то есть оффлайновых почтовых клиентов не предусмотрено. я не смогу как сейчас, скачать письма, забраться в леса амазонки, прочитать, предаться размышлениям, написать письмо, а почтовый клиент автоматически отправит и получит письмо когда я вернусь в отель и подключу кабель в телефонную линию.
S>>С чего бы не предусмотрено? Сервер только API предоставляет — не важно какой клиент. И конечно каждый клиент, даже браузерный — кеширует нужные данные.
SK>браузер — не почтовый клиент.
Что мешает браузеру быть почтовым клиентом и напрямую подключаться к почтовым серверам? Думай.
SK>Вот я и спрашиваю — в чем проблема? зачем тебе это видеть? рано или поздно письмо будет доставлено.
Потому что время иногда решает вопрос жизни и смерти. Мне важно чтобы было доставлено за 10 минут, к примеру — и это все решает. А не когда-нибудь вообще.
Если не доставлено за 10 мин. — свяжусь другим способом.
S>>Как не значащую. Мне очень важно получено письмо или нет. Мгновенно или небольшая очередь — вопрос вторичный, можно и секунду-две подождать.
SK>твой получатель — тайный наркобарон, его почтовый сервер в вагоне поезда. поезд движется под землей. связь появляется когда поезд поднимается на поверхность и пропадает когда погружается. SK>ну или нет, у наркобаронов подводные лодки. SK>это еще хуже, потому что в высоких широтах за полярным кругом связи нет даже на поверхности. спутники маска не залетают.
И что? Твой почтовый сервер периодически будет связываться с его сервером и пытаться отправить. А какие еще варианты то?
Более того — нет необходимости даже барону держать сервер в кармане. Шифрование для чего? Пусть оставляет на 5-баксовом VPS с аптаймом 99.95. А уже когда он клиентом получит доступ к серверу — это его личное дело — твоя ответственность — его сервер получил И ПРИНЯЛ письмо.
SK>да вот эта информация о доставке/отправке — мусор. не несет никакой пользы.
А что несет пользу тебе? Т.е. ты из тех что жизнь тлен и воообще ни в чем нет смысла?
Письмо важное — тебе нужно знать авторизован ли ты, получено ли твое письмо. Это может решать вопрос жизни и смерти.
SK>Абсолютно. я не решаю вопросы жизни и смерти в реальном времени инструментами для этого не предназначенными. и тебе не советую.
Так вот когда есть данные что письмо доставлено и не отбраковано — то это переводит инструмент и его возможности на новый уровень. Даже если не получилось доставить — ты об этом знаешь и уже можешь пробовать второй вариант доставки, к примеру звонок.
SK>>>Ты, будь добр, опиши пошагово все сценарии работы твоей новой почтовой системы. как со стороны пользователя, так и со стороны серверов.
S>>То же самое что в Телеграме, только вместо Пашиных рук — протокол, который регулирует обмен между серверами. SK>с таким описанием — ничего не получится.
Здравствуйте, Stanislaw K, Вы писали:
S>>Сейчас такие письма попадают во входящие и нужно их вручную удалять. SK>Эта "проверка email" и есть та самая "авторизация в 150 байт", которую ты хочешь. уже имеешь. но не понимаешь этого.
Нет протокола. Если попало в спам — ты об этом не узнаешь. Можешь годами слать сообщения — но оно попадает в спам по той или иной причине — и ты даже не знаешь.
Должно быть так:
1. Отправляешь сообщение. Сразу получаешь отклик — авторизовано или нет.
2. Если не авторизовано — отправляешь запрос на авторизацию.
3. Если запрос на авторизацию удовлетворен — получаешь оповещение.
4. Можешь слать сообщение повторно и имеешь 100% гарантию доставлено оно или нет.
SK>Я вижу что многие люди кроме меня говорят тебе тоже самое что и я: всё то, что ты хочешь получить — уже существует и реализуется настройкой фильтров\правил обработки входящего.
Здравствуйте, Stanislaw K, Вы писали:
S>>Причем тут люди? Ты понимаешь концепцию доставки? Либо письмо принято и я должен об этом знать, либо отвергнуто — и я как отправитель должен об этом знать, чтобы не слать больше. SK>Начни отсюда https://www.ietf.org/rfc/rfc5321.txt
Я понимаю что старикам хотелось бы чтобы кто-то ковырялся в продуктах их жизнедеятельности. Но это так не работает.
Нам нужно "забывая заднее и простираясь вперед" а так же помнить что "не вливают также вина молодого в мехи ветхие".
Email для 80 и 90 был неплох, но сейчас все изменилось. Сейчас сервер с доступностью 99.95 — стоит 5 долларов в месяц а то и меньше.
Все изменилось.
Нужна скорость, мир ускорился. Если за 10 мин. не доставлено — нет смысла просто верить и ждать что оно придет когда-нибудь. Нужно сразу знать — доставлено или нет. Иногда секунды решают.
Так же ЭЦП уже ничего не стоит, процессорных мощностей сколько хочешь.
Но сейчас гораздо важнее — убрать мусор, сохранить чистоту и структуру. Чтобы вам не впихивали в важное — нечто маловажное и не обесценивали важное. Мусор должен быть отдельно.
Здравствуйте, Shmj, Вы писали:
SK>>Я вижу что многие люди кроме меня говорят тебе тоже самое что и я: всё то, что ты хочешь получить — уже существует и реализуется настройкой фильтров\правил обработки входящего.
S>Стоп, ты же сам вроде понял проблему: https://rsdn.org/forum/flame.comp/8941144.1
Здравствуйте, Stanislaw K, Вы писали:
SK>Основной недостаток в том, что вместо решения фундаментальной проблемы ты предлагаешь её замаскировать (т.е. добавить других проблем).
Ну вы согласны что проблема есть?
Давайте попробуем назвать эту проблему: проблема рекламных рассылок, которые замыливают глаз и мешают увидеть важные сообщения. Возможно даже более — сюда же проблема и прочих автоматических оповещений, как то даже оповещения о входе (которые вроде бы и важны пусть даже 2 недели, а потом не имеют смысла).
Я предложил решение такое:
Во-первых, исключить умные спам. фильтры и нечеткую логику обработки спама, чтобы даже 0.01% не было вероятности, что важное письмо попадет в спам и отправитель об этом не узнает. Если даже 0.01% есть — то значит вам постоянно придется просматривать спам-папку. Для этого нужно добавить авторизацию и прозрачный отказ в аторизации. Отправитель понимает что письмо не принято и если оно важное — то сделает запрос на авторизацию или даже позвонит человеку на телефон.
Во-вторых, добавить обязательные флаги для массовых рассылок а так же законодательную поддержку, если эти флаги не используются.
SK>>Основной недостаток в том, что вместо решения фундаментальной проблемы ты предлагаешь её замаскировать (т.е. добавить других проблем).
S>Ну вы согласны что проблема есть?
Здравствуйте, Shmj, Вы писали:
S>Вот самое банальное — почта. До сих пор нет нормального решения:
S>1. Децентрализованного, не чтобы какой-то Дуров себе свой протокол делал а потом продавал всем и ставил условия централизованно — это не подходит.
S>2. Авторизация отправителя. Т.е. чтобы не авторизованные отправители были в отдельной папке. Но чтобы туда нельзя было попасть по ошибке — т.е. без всяких анализов ИИ и текста — если ключ публичный ты не одобрил — все попадает туда. Тогда ничего случайно не попадет в спам.
S>3. Категоризация по темам на уровне отправителя, а не на уровне ИИ. Отправитель указывает что это за тип рассылки — в особенности интересует рекламные предложения. А так же указывает актуальность предложения, чтобы оно автоматически удалялось после истечения срока. Возможность отказаться от получения той или иной категории писем от отправителя (к примеру, от MS я не хочу получать акции, но хочу получать оповещения о доступе к моему аккаунту).
S>Вроде бы ничего сверх сложного в этом нет — но смогет ли человечество когда-либо к этому прийти?
Это разве проблемы???
IMHO не надо усложнять обычную почту. Там и так уже простому смертному сложно разобраться.
Для сокрытия содержания конфиденциального электронного письма — уже лет 20-ть как есть надёжные решения.
Если так интересно — копай в сторону PGP encryption...
Ну а усложнять отсылку сообщений типа:
С Днём Варенья тетя Валя, долгих Вам лет!
С уважением, Ваш племяш Лёша!
Здравствуйте, AlexGin, Вы писали:
AG> AG>Это разве проблемы???
AG>IMHO не надо усложнять обычную почту. Там и так уже простому смертному сложно разобраться. AG>Для сокрытия содержания конфиденциального электронного письма — уже лет 20-ть как есть надёжные решения. AG>Если так интересно — копай в сторону PGP encryption...
Так вы чего-то суть упустили. Проблема в том что важное перемешивается с неважным.
А обязательная авторизация — это только первый шаг, который поможет важное отделить от неважного.
Здравствуйте, AlexGin, Вы писали:
AG>Есть деловая переписка, есть деловая конфиденциальная и есть бытовая. AG>Зачем всё под общую (одну) гребенку?
Есть рекламные акции и предложения — а есть важные сообщения. Сейчас все в одну кучу, по сути.
S>>А обязательная авторизация — это только первый шаг, который поможет важное отделить от неважного.
AG>Ну так войти на обслуживание почтовым сервисом — нужна авторизация. Это уже есть (четверть века — уж точно)! AG>В чём я ошибаюсь?
Я имею в виду — пока вы не авторизовали отправителя — он не сможет ни одного письма вам отправить. Кроме запроса на авторизацию.
Так же нет смысла в новом мире в цепочках SMTP-серверов — один сервер может отправлять напрямую второму. Если второй не доступен — можно отправить чуть позже, но чтобы пользователь видел состояние — отправлено/в процессе/не авторизовано/авторизовано.
