У меня возникла ужасная проблема с отправкой электронных писем с учетной записи электронной почты общего хостинга godadddy (CPANEL) на любой учетная запись электронной почты, размещенная Network Solutions. Я часами разговаривал по телефону, получая техническую поддержку от godaddy и Network Solutions. У меня есть два открытых тикета с Network Solutions для двух разных адресов электронной почты, и я открою третий для третьего адреса электронной почты. Насколько я могу судить, электронная почта, отправленная с этой учетной записи godaddy, легко достигает всех остальных адресов. Для учетной записи godaddy существует правильная запись spf (она нравится Gmail). А некоторые письма (самые важные) даже имеют DKIM-подписи. Gmail не очень любит подписи DKIM, но принимает почту. А те, на которые я вводил билеты с помощью netsol, не имеют подписи DKIM. Но почта, отправленная на адреса netsol, не доставляется. Они не попадают в спам и не отскакивают. Они просто переходят в / dev / null.
Я не буду разглагольствовать о том, насколько некомпетентным был ответ netsol, но первый из билетов был открыт 3 августа, и он все еще открыт, и проблема сохраняется. Единственное видимое действие с их стороны, которое я видел, — это то, что они отправили электронное письмо на мою учетную запись netsol с поддельным адресом отправителя учетной записи godaddy. Но я мог видеть в заголовках, что он исходил с сервера netsol, поэтому он и прошел.
С другой стороны, техническая поддержка godaddy была чрезвычайно полезной, и в конце концов мне удалось уговорить агентов службы поддержки вынуть соответствующие записи из их исходящих журналов сервера. Агент, с которым я говорил о третьем адресе netsol, не хотел отправлять фактические записи журнала сервера, но он подтвердил мне, что они эквивалентны тому, что мне дали для первых двух, которые, по сути, были одинаковыми.
Итак, вот (тщательно обработанная версия) взаимодействия с сервером, где 1.2.3.4 — это IP-адрес Godaddy MTA, а 5.6.7.8 — IP-адрес Netsol MTA.
20210812 09:29:10.177 core sid="id1" id="id1id2"
ip="1.2.3.4" action="PERMERR" dstmta="5.6.7.8" age="61" code="553"
reason="553 5.3.0 198.71.225.36 Your message was rejected for possible spam/virus
content.Please ask your email provider to visit http://emailadmin.registeredsite.com
for resolution.rn" account="rsvp@godaddy-example.com""
fwd="0" bounce="false" mailfrom="rsvp@godaddy-example.com" fromdomain="godaddy-example.com"
recipient_list="rich@netsol-example.com" todomain="netsol-example.com"
subject="Sad news" subject_hash="f35ba6823f3a91025f0a495ed7de3b59" script="" script_ip=""
20210812 09:28:09.658 core sid="id1" id="id1id2"
ip="1.2.3.4" action="ACCEPT" reason="CLEAN" account="rsvp@godaddy-example.com"
fwd="0" mailfrom="rsvp@godaddy-example.com" fromdomain="godaddy-example.com"
recipient_list="rich@netsol-example.com" todomain="netsol-example.com" subject="Sad news"
subject_hash="f35ba6823f3a91025f0a495ed7de3b59" script="" script_ip=""
Кто-нибудь может объяснить, почему это привело к тому, что почта была брошена на пол? Или как может быть, что netsol не сможет решить проблему в течение 10 дней? У меня не было этих журналов 3 августа, но я дал им метку времени, идентификатор сообщения, а также адреса отправки и получения электронной почты. Очевидно, что строка «Тема» не вызывает подозрений, а тело сообщения состояло из одного предложения, в котором говорилось, что мой дед скончался накануне в 17:00. Маловероятно, что он будет распознан как спам. Итак, мой единственный вывод заключался в том, что он должен быть основан на IP-адресе сервера godaddy. Я проверил IP-адрес на mxtoolbox.com, и он был внесен в пару черных списков, но не очень плохих (SORBS SPAM, который взимает плату за исключение из списка, Godaddy игнорирует, но они активно стараются держаться подальше от Spamhaus ). И я попытался повторно отправить его после того, как оказалось, что его нет в черных списках, но он все еще не был доставлен. Я также проверил это на http://emailadmin.registeredsite.com несколько раз, и он никогда не показывался как заблокированный. И, конечно, они говорят, что блокировка приводит к отказу.
Разве это не требование SMTP, чтобы сообщения доставлялись или возвращались? Кто-нибудь знает конкретное значение параметра «nobounce» в записи об отклонении 553? Это говорит о том, что сервер netsol не отправляет отказов, или это говорит серверу godaddy не отказываться от него? Должен ли сервер godaddy в любом случае выдавать рикошет в ответ на 553 от netsol? В любом случае, это все еще проблема netsol для отбрасывания сообщений, но мне было бы полезно, если бы godaddy отправил отскок в этой ситуации.
РЕДАКТИРОВАТЬ: Дополнительная информация с собственным вопросом:
Я взял IP-адрес конкретного сервера «netsol», который отправил ответ 553, и отправил его в инструмент ARIN WHOIS-RWS. В нем говорилось, что адрес принадлежит Cloudflare (то есть в блоке CIDR 172.64.0.0/13, который ARIN напрямую выделил Cloudflare, Inc). Это что-нибудь значит? Netsol имеет множество принадлежащих ей IP-адресов. Означает ли тот факт, что у этого MTA есть адрес, принадлежащий Cloudflare, что-нибудь о возможной передаче Netsol услуги MTA Cloudflare? И, возможно, netsol не контролирует напрямую сервер, и это одна из причин задержки с его исправлением ?? Или Cloudflare, скорее всего, просто «сдает в субаренду» IP-адрес netsol, который фактически владеет и управляет сервером? Netsol предоставляет услуги электронной почты дольше, чем существует Cloudflare, но с годами, похоже, он стал гораздо менее техническим и более ориентированным на маркетинг и бизнес-сделки (IMO). И после этого фиаско у меня становится гораздо меньше шансов остаться с netsol после более чем 20 лет работы с ними.