defin

defin
Рейтинг
148
Регистрация
11.12.2006
gruz_:
найди/купи в сети сканы паспорта, потом смени в панели данные на паспортные, и потом проси секретный код для переноса и высылай им скан паспорта

После смены данных владельца у домена, включается автоматическая блокировка на перенос к другому регистратору в течение 2 месяцев.

Уже дали инет )))

Но реально у Рег.ру не работало ничего, даже DNS сервера начали отваливаться, т.к. реестр зоны RU не отдавал для reg.ru никаких DNS

Видимо сбои в ТЦИ были.

З.Ы. Вот так, отрубаем реестр - всё, все российские сайты в дауне когда стухнет время жизни кэша. Иногда, получается, полезно ставить высокий ttl у зоны ))

Зачетно Рег.ру отметил аккредитацию ))) Аж сам не работает.

nslookup -type=a reg.ru a.dns.ripn.net

Server: a.dns.ripn.net

Address: 193.232.128.6#53

*** Can't find reg.ru.: No answer

Как уже отметили выше, все равно резолв домена зависит в большей степени от конечного провайдера. И если в столице и крупных городах провайдеры почти не кэшируют (или кэшируют на минимальное время) данные, то вот в глубинке могут кэшировать и на три дня, в течение которых сайт будет открываться все еще со старого IP. Так же этим страдают мобильные операторы... У них чуть ли не 72 часа кэш держится. Тут даже если зона на DNS уже обновилась и у вас сайт открывается по новому IP - не факт, что у других тоже самое...

Второй главный момент - это настройка TTL в зоне на DNS. В большинстве случаев она по умолчанию равна 86400 секунд (сутки). Это время в течение которого кэширующий сервер может не обновлять данные, т.е. время жизни кэша. Нужно поставить его на минимальное значение, скажем 600 секунд, чтобы DNS опрашивались не раз в сутки, а раз в 10 минут.

Статья 154 НК РФ:

При получении налогоплательщиком оплаты, частичной оплаты в счет предстоящих поставок товаров (выполнения работ, оказания услуг) налоговая база определяется исходя из суммы полученной оплаты.

Письмо было разослано НауНетом пока. Вы с НауНетом работаете как партнер?

Himiko:
Может всё-таки уточнить у gmail, что ему не нравится?

А Вы думаете он так и скажет прям )))

Ну согласитесь, письма с нового чистого сервера, хорошего IP и сразу в СПАМ на таком известном сервисе как GMAIL - это ненормально... Причем что все настройки со стороны DNS сделаны.

Может и правда что-то с самим почтовым сервером? Что он не отвечает на проверки...

Himiko:

defin, Тоже вам всё объясняли, если я верно понял, с каким вопросом вы обращались.

Я могу тут привести историю диалога, но боюсь Вам будет стыдно...

проверил отправкой в gmail - ни прямой, ни обратной зоны. Получатель смотрит по mydomain и видит xxx.ru, проверяте обратную зону - и не видит ничего. Проверяет MX'ы, и не видит xxx.ru - все, письмо в спам

Специалист даже не удосужился сделать nslookup и посмотреть есть ли зоны и что там и усиленно меня убеждает что их нет. Даже заголовки у письма видимо не смотрел, где Гугл все пишет черным по белому, что всё есть. После того, как я привел ему содержание через эту команду, меня уже поставили в игнор.

По поводу проверки - проверять нужно на адрес @gmail.com а не на свою почту по технологии Google Apps - там у них проверки минимальные, поэтому туда доходит всё.

Я тоже проверил на Apps - пришло, а на 3 ящика Gmail.com - везде в СПАМе.

Ну раз пошла такая пьянка - тоже выскажу свое "фи".

Заказал оптимизацию и безопасность. Что то там настроили, что-то обновили. После этого все письма с сервера стали падать в СПАМ у получателей (думаю не стоит говорить, что ДО все было нормально). Исправить не смогли, тупо в чате никто не отвечал долгое время в диалоге.

Что говорить - лог диалога с их сайта тоже попадает в СПАМ. Как так - письма с сайта администраторов помечаются как спам? ))))

Вот что вычитал:

Постфикс, например, при реверсной проверке проверяет адрес отправителя не через головной (или какой угодно MX), а он коннектится и проверяет отправителя на том хосте, который пытается ему отправить письмо.

--

Вот может в этом и проблема... Сервера Гугла пытаются проверить отправителя коннектом к серверу, а он его посылает...

Всего: 304