Является ли имя домена электронной почты именем хоста почтового сервера (например.) Postfix [закрыто]
El problema podría ser este enlace:
lrwxrwxrwx 1 root root 23 Jun 4 13:09 /etc/localtime -> /usr/share/zoneinfo/UTC
Si este enlace estaba presente antes del comando cp /usr/share/zoneinfo/Europe/Berlin /etc/localtime, lo que realmente sucedió fue que el contenido del archivo /usr/share/zoneinfo/Europe/Berlinsobrescribió el archivo /usr/share/zoneinfo/UTC.
Eso haría que cualquier cosa que realmente use el contenido del archivo /etc/localtimeuse la zona horaria CET/CEST, pero cualquier cosa que busque la zona horaria simplemente verificando el nombre del archivo vinculado informaría la zona horaria como "UTC".
Para arreglarlo:
apt-get --reinstall install tzdata
ln -sf /usr/share/zoneinfo/UTC /etc/localtime
update-initramfs -u
Tenga en cuenta el último comando :después de cambiar la zona horaria predeterminada del sistema, debe actualizar su initramfs, para asegurarse de que también los procesos que se inician temprano en la secuencia de arranque del sistema usarán la definición de zona horaria correcta.
Это большой и сложный вопрос, но я попытаюсь объяснить основы. Здесь действительно два вопроса :как заставить ваш сервер получать почту для доменного имени и как разрешить клиентам отправлять через него исходящую почту ("ретранслируя" ).
Получение почты :Собственное имя почтового сервера часто отличается от имени домена (s ), для которого он получает почту, и не обязательно имеет к ним какое-либо отношение. Например, johndoe@example.com может обрабатываться mail.example.com или сервером gmail под google.com.
Здесь есть два важных момента :Чтобы почта, адресованная @example.com, отправлялась на yourserver.example.net, вам нужна запись MX в записи DNS для example.com.Вот актуальная информация для stackexchange.com:
$ dig -t mx stackexchange.com
[...]
;; ANSWER SECTION:
stackexchange.com. 300 IN MX 5 alt2.aspmx.l.google.com.
stackexchange.com. 300 IN MX 1 aspmx.l.google.com.
stackexchange.com. 300 IN MX 10 alt3.aspmx.l.google.com.
stackexchange.com. 300 IN MX 10 alt4.aspmx.l.google.com.
stackexchange.com. 300 IN MX 5 alt1.aspmx.l.google.com.
[...]
...поэтому почта, адресованная @stackexchange.com, будет отправлена на любой из этих серверов google.com (номер непосредственно перед именем сервера является приоритетным, поэтому aspmx.l.google.com будет опробован сначала, затем alt1 и alt2, затем alt3 и alt4 ).
Другая часть получения почты заключается в том, что ваш сервер должен осознавать, что он должен принимать сообщения, адресованные этим доменам, и помещать их в почтовые ящики (, а не пытаться пересылать их на другой сервер ). В postfix это можно сделать, добавив их в список mydestinationв main.cf или настроив их как виртуальные домены. См. здесь .
Ретрансляция исходящей почты :Самое важное здесь — не допустить, чтобы спамеры использовали вас в качестве «открытого ретранслятора» для пересылки нежелательной почты. Самый простой вариант здесь — :не предоставлять услугу ретрансляции. В зависимости от вашей ситуации у ваших клиентов уже могут быть отличные способы отправки исходящей электронной почты, и в этом случае вы можете просто пропустить головную боль и риск. Если вам нужно разрешить ретрансляцию, вам нужен какой-то способ отличить надежных клиентов от спамеров. Вы можете сделать так, чтобы клиенты аутентифицировали и/или доверяли отправителям на основе IP-адреса, с которого они приходят. Аутентификация клиентов, как правило, лучше (, но, пожалуйста, не позволяйте им отправлять пароли открытым текстом! ). Доверенные IP-адреса следует использовать только в случае необходимости, потому что, если спамер может нарушить работу устройства в доверенной сети (или даже просто перенаправить SMTP-трафик с одного ), он может использовать вас в качестве открытого ретранслятора.
Конечно, это еще много чего, но, надеюсь, это даст вам основы.
Да, еще кое-что :хотя домен электронной почты может отличаться от имени сервера, клиенты будут использовать фактическое имя сервера в своих конфигурациях отправки/получения.