Как уже верно подметили ваше — срочно меняйте регистратора. GoDaddy известен тем что часто блокирует домены «за спам», что имхо является нонсенсом, т.к. спам отправляется с IP-адресов а не с доменных имен.
После блокировки домена они у вас начнут требовать выкуп за разблокировку от 50$ и письменные обещания что вы больше не будете рассылать спам.
Что касается SPF — это не поможет, т.к. рассылать спам это не мешает, и далеко не все принимающие почту серверы используют проверки по SPF, а те что использует — не всегда используют для отправки почты в спам.
Это было сказано не в защиту, а в качестве возможного объяснения его поведения. То что он не прописал такие условия в договоре и так поступает — ну, мне бы тоже не понравилось.
Да все очень просто на самом деле. Они скорее всего перепродают (реселлят) выделенные серверы в разных дата-центрах. Многие так работают. И возможно именно у датацентра burst такие условия (т.е. если нет оплаты — сразу же до свидания). Соответственно может они ничего и не могли просто поделать в этом случае. У некоторых зарубежных ДЦ вообще если планируешь отказаться от услуг надо предупреждать за календарный месяц, и за него они тоже снимают оплату, хотите вы пользоваться ним или нет.
Скорее всего эту ошибку выдает сайт мерчанта а не сайт банка. Кроме того мерчантам запрещено сохранять информацию такую как номер карты и другие ее реквизиты (исключение составляет четыре последние цифры номера карты). Так что даже если эти данные будут украдены — пользы от этого никакой.
Грейлистинг конечно штука интересная, но часто бывает что большие почтовые службы (например google), каждый раз пытаются доставить одно и то же письмо с разных smtp-серверов. И получается каждый раз такое письмо натыкается на грейлистинг и так и не доходит.
Я у себя сделал так — если в домене отправителя указаны записи SPF, то письма минуют грейлистинг. Если же не указаны, то срабатывает грейлистинг, а в причине ошибки указывается просьба настроить SPF для пропуска этой проверки.
На клиенте (в случае Windows) должен стоять eToken PKI Client, чтобы система корректно распознавала подключаемые смарт-карты. Больше никаких дополнительных настроек не требуется.
На сервере — никакого дополнительного ПО не нужно. Только разрешить аутентификацию по ключу и добавить публичный ключ в список авторизованных.
Да. Там при каждом начале работы нужно ввести пин-код. Если даже злоумышленник завладеет брелком, то без знания пин-кода не сможет его использовать, а при определенном количестве неверных попыток токен заблокируется. Плюс сам eToken предусматривает возможность «вторичной идентификации с ключом RSA» — т.е. в дополнение к пин-коду, создается пароль для каждого конкретного закрытого ключа, который запрашивается при каждом использовании.
Насколько мне известно, это будет работать под *NIX если скомпилировать ssh-клиент с поддержкой смарт-карт — см. www.opensc-project.org/, но лично я не делал этого.
Закрытый ключ понадобится если вы захотите сделать его резервную копию. При генерации на етокене его забекапить не получится.
После блокировки домена они у вас начнут требовать выкуп за разблокировку от 50$ и письменные обещания что вы больше не будете рассылать спам.
Что касается SPF — это не поможет, т.к. рассылать спам это не мешает, и далеко не все принимающие почту серверы используют проверки по SPF, а те что использует — не всегда используют для отправки почты в спам.
Я у себя сделал так — если в домене отправителя указаны записи SPF, то письма минуют грейлистинг. Если же не указаны, то срабатывает грейлистинг, а в причине ошибки указывается просьба настроить SPF для пропуска этой проверки.
www.nestor.minsk.by/sr/2006/02/sr60201.html
На сервере — никакого дополнительного ПО не нужно. Только разрешить аутентификацию по ключу и добавить публичный ключ в список авторизованных.
Закрытый ключ понадобится если вы захотите сделать его резервную копию. При генерации на етокене его забекапить не получится.