Comments 21
Поскольку URL-адрес отображается после доставки, шлюз безопасности электронной почты не может найти и проверить вредоносный url, поскольку на момент доставки его нет. Для этого потребуется интерпретация CSS файлов, а это выходит за рамки функциональности существующих систем безопасности электронной почты.
С текстом все ясно, а вот про ссылки не совсем.
Есть возможность средствами css изменить атрибут элемента (ссылка в данном случае)?
Насколько я понял, на момент доставки урл уже должен присутствовать в письме, только меняются его настройки видимости. Следовательно спам фильтры определят вредоносный адрес.
клиент электронной почты покажет ссылку с возможностью клика
Поскольку URL-адрес отображается после доставки, шлюз безопасности электронной почты не может найти и проверить вредоносный url, поскольку на момент доставки его нет.
я о том, что вот эти два предложения вместе несовместимы, тут обязательно оговорка, что урл будет некликабельным(составлен из отдельных символов-элементов) и только тогда его пропустит «шлюз безопасности».
Не хватает картинки с CSS в описании преобразования HTML в методе Matrix Exploit. Из описания понятно, что в письме в HTML-коде одна позиция (один символ) представлена набором div-ов с уникальными ID, внутри которых по одному символу, в CSS, соответственно, часть этих ID'ов получает "display=inline". Трюк интересен, особенно если сервер динамически генерирует CSS, и его было бы весело использовать для какой-нибудь непрямой генерации уникальных ID, не перехватываемых одним куском (надо сопоставить два куска информации, прямо как в "Кортике").
Также непонятен толком способ превратить порезанное на символы письмо в HTML-код "<a href="BadSite/BadURI">", вроде как чисто CSS'ом это не поменять. Или в письме стоит динамическая ссылка на какой-то элемент загружаемого CSS?
клиент электронной почты покажет ссылку с возможностью клика (например, в случае с Apple Mail), либо, по крайней мере, будет содержать текст с URL-адресом.пользователь копирует текст и вставит в строку браузера
То есть серьезно, если я из дивов соберу строку "http://site.com/dir" клиент Apple Mail соберет из неё активный элемент? Ваууу, юзабилити! :D
А копировать адрес из письма — довольно рискованная затея, на неё даже пользователи толком не попадаются уже.
Не надо использовать HTML в письмах! Электронная почта + HTML это дорога в ад!
Во всех клиентов есть соответствующие настройки. Если письмо не конвертируется, просто стираем.
Письма обычно пишу, когда нужно изображения приложить, цветом выделить, пошагово что-то описать с картинками, типа иди сюда, там будет то-то, сделай там это и т.п. Если просто 17 картинок к письму приложить, то непонятно получится.
Потому что письмо это документ, а разговор это "бла-бла-бла".
Ну, отправите Вы мне прекрасный ХТМЛ документ, пошаговый, с картинками. А я все равно, прочитаю его как текст отдельно, а картинки отдельно. Потому что настройки клиента у меня такие. И придется вам писать текст так, чтобы понятнее был, иначе нам не понять друг друга. :)
Электронная почта — асинхронный способ общения, а телефон — синхронный, у них разные сценарии использования. Звонок — это способ решать вопросы _срочно_, он как минимум отрывает собеседника от его текущего занятия (если не запланирован). Не говоря уже о том, что электронная почта — основной способ доставки автоматизированных сообщений.
> или SMS написать
Не всегда. СМС дороже, не имеет многих фич e-mail (цитирование, шифрование), его сложнее вводить, контакт (номер телефона) значительно реже доступен посторонним.
Use The Bat HTML viewer = Checked, Download embedded = Never.
И лучше Menu\Preferences\Viewer-Editor\: Plain Text Viewer везде.
А вот как защищаться в Mozilla Thunderbird я сообразить не могу…
А иначе это приводило бы к раскрытию IP-адреса получателя письма при загрузке обычных картинок.
Из более-менее опасного риска вижу обход анти-спам фильтров — когда легитимное письмо с Matrix техникой сперва вайтлистится почтовыми серверами, и потом подменяется содержимое без изменения тела письма.
Но опять-таки большинство режет загрузку ресурсов в внешних источников, перезакачивая их к себе.
— Можно ли ссылаться на CSS-файл из письма и если да, то куда лучше вставлять линк?
— Можно ли? Да. Стоит ли? Нет. Вероятнее всего, почтовый клиент заблокирует внешние ссылки <...> спам-фильтры это не любят.
Было бы очень «здорово», например, узнавать о прочтении письма без отправки запроса на подтверждение — используя уникальные имена а-ля «styles-usertoken.css»
В кои-то веки я согласен с MS. Простой вопрос к Mimecast: а какого собственно поведения от аутлука <с включенной галочкой «разрешён доступ к внешнему html контенту»> по отношению к письму с таким контентом они ожидают? Клиент должен кэшировать всё внешнее содержимое и смотреть, не изменилось ли оно? А как отличить легальное изменение от нелегального?
Простой эксплойт даёт злоумышленникам возможность изменить содержимое письма после отправки