Як можна протестувати резервний / вторинний MX-сервер?

Я хочу створити вторинний MX-сервер за допомогою Postfix, але мені цікаво, який найкращий спосіб перевірити це перед введенням у виробництво (додавши його запис MX)?

Один із можливих способів - це протестувати його з абсолютно іншим доменним іменем, тобто придбати домен на зразок "fake-test-domain.com" та встановити його зону DNS ТОЛЬКО на цьому резервному MX-сервері.

Якимось простішим способом я можу просто змусити поштовий сервер надсилати повідомлення на цей сервер, перш ніж воно буде вказане в DNS?

Я не думаю, що я можу використовувати файл хостів у системі відправки, оскільки це не буде імітувати запис MX, правда?

— томаструктор
джерело

Ви можете просто включити вторинний MX. Поки він має нижчий пріоритет у записах MX, його доставка не буде здійснена, і ви можете протестувати як згадується @EEAA. BTW: будьте уважні, що резервні поштові сервери - це пастки для спаму. І якщо ви не налаштуєте підтвердження одержувача, ви отримаєте безліч повідомлень про відмов для тих, хто використовує спамери з адреси адреси. Ви можете налаштувати ручну або автоматичну систему, яка керує правилами iptables для доступу до порту 25. Більшість серверів, що відправляють, мають триденний час відстрочки, тому легко вручну відкрити резервний порт MX 25 лише тоді, коли це необхідно.

— Halfgaar

Я б запитав, чому ви думаєте, що вам потрібен вторинний MX?

— joeqwerty

@Halfgaar, якщо вторинний MX-сервер неправильно налаштований, це може призвести до втрати пошти, якщо навряд чи відправник не може підключитися до основного сервера MX з будь-якої причини (включаючи проблему з підключенням в їх кінці). Принаймні, якщо вона ще не була додана в DNS, тоді перехідна проблема з основним не призведе до втрати пошти - відправник просто поставить в чергу чергову пошту та повторить спробу пізніше.

— thomasrutter

@joeqwerty Насправді я думаю про переміщення поштового сервера на іншу машину, яка передбачає налаштування старого сервера для ретрансляції на новий сервер під час поширення DNS (навіть при низьких значеннях TTL, деякі роздільники кешуватимуть протягом 30 хвилин і більше) . Оскільки мені потрібно буде докласти зусиль, щоб це ретрансляція працювала правильно, я подумав, що можу створити резервну конфігурацію сервера MX. І це буде досвід навчання. Це було лише для того, щоб дати трохи відомостей про те, чому.

— thomasrutter

Просто скористайтеся сеансом телнету, щоб перевірити доставку електронної пошти. Як приклад,

# telnet host.domain 25
Trying host.domain...
Connected to host.domain.
Escape character is '^]'.
220  ESMTP
HELO example.com
250
MAIL FROM:<user@example.com>
250 ok
RCPT TO:<user2@example.com>
250 ok
DATA

To: user2@example.com
From: user@example.com
Subject: a test message

Test message body.
.
250 ok

— EEAA
джерело

+1 - Кожен, хто адмініструє SMTP-сервер, але не може запустити протокол "від руки" в TELNET, не має бізнесу, що адмініструє SMTP-сервер.

— Еван Андерсон

@EvanAnderson Це хороший загальний принцип, поки справа не стосується тестування STARTTLS або будь-якого AUTH, окрім PLAIN. Але так у цьому випадку ви абсолютно праві.

— thomasrutter

@thomasrutter Я звичайно тестую STARTTLSвручну, використовуючи openssl s_client -starttls smtp -connect .... Але я погоджуюся з тим, що методи аутентифікації, що не належать PLAIN, є проблематичними.

— MadHatter

Коли telnet недостатньо або занадто виснажливий, я використовую SWAKS

наприклад:

 cat email-content.txt | 
 swaks --body - --helo localhost.localhomain --server mail.example.com:25 \
  --auth-user fred --auth-password flintst1 -tls \
  --h-Subject Pebbles  --to wilma@example.org
  --from 'fred@example.biz'

— користувач313114
джерело

sudo apt install swaksпрацював над ubuntu

— Донн Лі