Все это зависит от того, имеет ли сервер SMTP, Вы посылаете свои электронные письма через, актуальную запись MX. Много ISPs не повинуется TTL и делает их собственное, и я предполагаю, что это могло особенно иметь место для MX.
Я видел случаи до 72 часов, прежде чем MX будет обновлен, особенно с южноафриканским ISPs.
Если бы это все еще возвращается для всех после 24 часов, именно тогда я был бы более заинтересован.
- Обновление-
Я сделал nslookup на Вашем домене и получил следующее:
C:\Users\Mark>nslookup Default Server: bladedc1.live.local Address: 192.168.163.50 > set q=mx > ttanet.com Server: bladedc1.live.local Address: 192.168.163.50 ttanet.com primary name server = NS87.WORLDNIC.COM responsible mail addr = namehost.WORLDNIC.COM serial = 110011012 refresh = 10800 (3 hours) retry = 3600 (1 hour) expire = 604800 (7 days) default TTL = 3600 (1 hour) >
Похоже, что Ваш DNS не служит никаким записям MX вообще, однако Ваше вышеупомянутое, запись для mail.example.com ДЕЙСТВИТЕЛЬНО существует:
> set q=a > mail.ttanet.com Server: bladedc1.live.local Address: 192.168.163.50 Name: mail.ttanet.com Address: 206.188.207.108
И authoriative сервер имен установлен на:
> set q=ns > ttanet.com Server: bladedc1.live.local Address: 192.168.163.50 Non-authoritative answer: ttanet.com nameserver = ns87.worldnic.com ttanet.com nameserver = ns88.worldnic.com ns87.worldnic.com internet address = 205.178.190.44 ns88.worldnic.com internet address = 205.178.144.44
Мы видим записи с корректного сервера DNS?
- Обновление № 2--
Я полагаю, что вижу корректные детали теперь:
> ttanet.com Server: bladedc1.live.local Address: 192.168.163.50 ttanet.com MX preference = 10, mail exchanger = ttamail.ttanet.com ttamail.ttanet.com internet address = 67.78.188.51
Таким образом, это - просто проблема propgation/caching для Ваших конечных пользователей. Это определенно настраивается правильно.
Перепроверка, которую Ваша определенная версия ASP.NET позволяется в IIS следующим образом:
Это решило его для меня, надежда, это работает на Вас также.
У меня была та же проблема, решенная путем предоставления явных полномочий IIS_IUSRS в папке, где мое приложение.
Я все еще не имею, находят решение, но находят обходное решение.
Можно вручную изменить конфигурацию IIS в system32\intsrv\config\applicationHost.config. Просто вручную создайте (вставка копии) раздел в и.
В IIS в "Расширенных настройках" Пула (пулов) приложений под "Общим" существует установка "Enable 32-Bit Applications". Когда я установил это на Правда, эта ошибка ушла для меня.
У меня была та же проблема, вот мое решение.
У меня сработало разрешение 32-битных приложений в пуле приложений.
Похоже, что приложение, которое я запускал, было 32-битным
HTH
ИМХО ... Этот тест не имеет большого значения, если вы не хотите тестировать конкретного пользователя, и даже в этом случае он незначителен ... для добавления учетных записей пользователей в папки, чтобы этот тест работал (как другие заявили) маргинализирует вашу безопасность ... лучше не проводить этот тест, чем добавлять пользователей в папки и ставить под угрозу вашу безопасность любым способом, формой или формой ...
Пока ваш сайт работает ... это должно быть ваш тест ...
Это действительно похоже на ошибку в пользовательском интерфейсе IIS: при выборе «Пользователь приложения (пройти через аутентификацию)» веб-сайт ожидает, что браузер отправит учетные данные текущего пользователя, вошедшего в систему. Затем сайт загрузится, потому что для сайта включена «анонимная» аутентификация. Однако при тестировании через IIS MMC, кнопка «Test Settings ...» не представлены учетные данные для использования для доступа к каталогу, поэтому вы видите сообщение об ошибке «Invalid application path» в IIS MMC. Если вы нажмете «Обзор ...», то браузер по умолчанию на веб-сервере, обычно Internet Explorer, представит ваши учетные данные. В большинстве случаев вы можете игнорировать эту ошибку, ваш веб-сайт работает.