Por que o cron usa o MTA para enviar e-mails, enquanto usamos o MUA para enviar e-mails?

Question

Eu observei as definições de MTA, MUA, MDA, por exemplo, link e link

• No Lubuntu, o cliente de e-mail padrão é o Sylpheed e muitos também usam o Thunderbird. Se eu estiver correto, tanto o Sylpheed quanto o Thunderbird são MUA.

• No link , Stephen mencionou que o cron usa o MTA (como postfix ou sendmail) para enviar as saídas de seus trabalhos como e-mails.

Minhas perguntas são:

• Por que o cron usa o MTA em vez do MUA para enviar emails? Se o cron pode usar o MUA para enviar e-mails, como?

• Por que usamos o MUA (Sylpheed ou Thunderbird) em vez do MTA para enviar e-mails? Se podemos usar o MTA para enviar e-mails, como?

• Quando instalamos o MUA (Sylpheed ou Thunderbird), o Sylpheed ou o Thunderbird precisam de um MTA instalado na máquina same para enviar emails?

Obrigado.

    

Answer 1

Na sua base, o correio no Unix é um fenômeno local. Os usuários no mesmo host podem enviar um ao outro sem a existência de nenhuma rede. (Os "endereços" são simplesmente nomes de usuários, sem @ .) Isso significa que o método de comunicação de uma mensagem do MUA para o MTA deve ser local. Normalmente, esse método é um canal para um programa chamado sendmail .

O correio local pode ser estendido para participar do sistema de correio da Internet, fazendo com que o MTA entenda endereços contendo o símbolo @ . O MUA ainda não precisa saber sobre a existência da rede; ele só precisa tratar endereços como strings opacas e deixar o MTA local descobrir quais precisam passar pela rede.

O MTA é obviamente o local certo para configuração de rede, porque há apenas um deles no sistema, mas vários MUAs podem estar em uso por diferentes usuários, ou até mesmo pelo mesmo usuário. Um único programa que manipula o material da rede para todos eles significa que a configuração não precisa ser feita mais de uma vez.

Os MUAs que injetam suas mensagens de saída em um servidor remoto destinam-se a permitir que sistemas "semelhantes a Unix" finjam funcionar corretamente sem um MTA. Esta configuração é uma rejeição do esquema tradicional das coisas. Ele corta o coração do sistema de e-mail - a capacidade de enviar uma mensagem a qualquer usuário local - e não fornece substituto adequado para ele.

Cron está agindo como um MUA, por isso não "usa um MUA", e está fazendo o que os Unix MUAs sempre fizeram, enviando e-mails sem ter ideia de que existe uma rede, contando com o MTA local para entender. E endereçar o destinatário pelo nome de usuário local é o único padrão razoável, já que as tarefas agendadas são executadas em nome de um usuário local e não há como saber qual endereço esse usuário pode ter em algum host remoto.

    

Answer 2

No cron e conexão MUA-MTA

Respostas práticas

Eu geralmente crio um alias de postfix para meus usuários do cron. Dessa forma, todas as mensagens de trabalho cron são entregues ao endereço de alias em minha tabela de pesquisa.

• Então, uma resposta prática é:

As mensagens do Cron podem ser enviadas para fora do servidor / domínio / máquina para qualquer endereço de e-mail arbitrário na Internet.

Além disso, o próprio cron pode ser configurado para usar qualquer MTA arbitrário mailer .

De minha árvore fonte do cron no Debian Buster:

cron-3.0pl1/config.h

45 #define MAILCMD _PATH_SENDMAIL                   /*-*/
46 /* #define MAILARGS "%s -i -FCronDaemon -odi -oem  %s"       /*-*/
47 #define MAILARGS "%s -i -FCronDaemon -B8BITMIME -oem  %s"        /*-*/
48          /* -i    = don't terminate on "." by itself
49                         * -Fx     = set full-name of sender
50           * -odi  = Option Deliverymode Interactive
51           * -oem  = Option Errors Mailedtosender
52           * -t    = read recipient from header of message
53           * -or0s = Option Readtimeout -- don't time out
54           * XXX: sendmail doesn't allow -or0s when invoked
55           * by joe user.  --okir
56           */
57
58 /* #define MAILCMD "/bin/mail"           -*/
59 /* #define MAILARGS "%s -d  %s"          -*/
60          /* -d = undocumented but common flag: deliver locally?
61           */
62
63 /* #define MAILCMD "/usr/mmdf/bin/submit"    -*/
64 /* #define MAILARGS "%s -mlrxto %s"      -*/

• Então, uma segunda resposta prática:

O Cron pode ser compilado para usar qualquer MTA arbitrário

Resposta teórica

Como afirmado nos comentários e outras respostas, cron está agindo como um MUA. Ele não tem a base de código para lidar com o envio de mensagens em lugar algum, exceto um MTA predeterminado, localizado em sua própria máquina lógica. É útil notar que a máquina lógica pode, na verdade, não ser a mesma máquina física.

Ao usar o MTA para enviar e-mails

Conectando-se diretamente a um MTA através de sua porta SMTP

Um email pode ser enviado diretamente através de um MTA, conectando-se ao seu SMTP.URL:port e trabalhando através de qualquer autenticação manualmente.

telnet example.com 25

Geralmente funcionará se alguém tiver desbloqueado o acesso à porta 25 por meio do ISP de conexão. E você receberá uma mensagem semelhante a esta:

Trying xxxx:xxxx::xxxx:xxxx:xxxx:xxxx...
Trying xxx.xxx.xxx.xxx...
Connected to example.com.
Escape character is '^]'.
220 mail.example.com ESMTP Postfix (Debian/GNU)

Mas ... a maioria dos ISP bloqueia a conexão da porta 25. E esse método de envio de e-mail é complicado, portanto, em geral, um MUA bem projetado como sylpheed ou thunderbird é usado.

Por que os ISPs bloqueiam a porta SMTP padrão: 25

A maioria dos usuários da Internet se conecta à rede de longa distância (WAN) por meio de um provedor de serviços de Internet (ISP). Esses ISPs geralmente bloqueiam portas comuns que são utilizadas para executar serviços da Internet, como HTTP (80) SMTP (25) e vários outros possíveis.

Em geral, os ISPs têm um Contrato de Termos e Condições com seus clientes que impede a execução de um serviço de Internet de sua rede. Existem pelo menos dois motivos para esta política geral do ISP:

1. Serviços de Internet consomem largura de banda.
Os
2. ISPs atuam como uma barreira mínima para muitos spammers de e-mail ou serviços maliciosos da Web.

Os ISPs também geralmente colocam em blacklist seus próprios pools de endereços IP dinâmicos. Assim, é muito provável que qualquer serviço de e-mail executado a partir de um endereço IP dinâmico do ISP seja rejeitado ou colocado diretamente na pasta "spam" de qualquer grande provedor de e-mail.

Bloqueio de IP na lista negra

IP lista negra é muito simples e eficaz. É usado na configuração do MTA para rejeitar imediatamente os e-mails recebidos provenientes de um domínio na lista negra.

/etc/postfix/main.cf

...
smtpd_client_restrictions = ...
                            reject_rbl_client cbl.abuseat.org
                            reject_rbl_client pbl.spamhaus.org
                            reject_rbl_client sbl.spamhaus.org
                            reject_rbl_client bl.blocklist.de
...

Exemplo de um dos meus registros reais do servidor:

Oct 14 04:45:23 xxxx postfix/smtpd[17679]: NOQUEUE: reject: RCPT from xxxxx.xxxx.xxxx.jp[xxx.149.xxx.xxx]: 554 5.7.1 Service unavailable; Client host [xxx.149.xxx.xxx] blocked using sbl.spamhaus.org; https://www.spamhaus.org/sbl/query/SBL319039; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<xxxx.xxx.xxx.jp>

Eficácia do bloqueio de portas e RBLs na Era dos Botnets

Essas políticas foram mais eficazes antes da idade atual dos servidores da Web sob demanda. Na minha experiência, os spammers e os agentes maliciosos simplesmente mudaram de serviços conectados ao provedor de serviços de Internet para botnets e servidores de comando e controle (C & C) sob demanda.

A maioria dos ataques de spam ou força bruta contra meus próprios servidores começa com um probe C & C geralmente executado a partir de um endereço IP do Amazon EC2. Seguido por uma série de botnets vindos de endereços em países distantes em algum lugar.

ISPs que não bloqueiam portas

Não sei se algum ISP dos EUA permite todas as portas. No entanto, tenho visto alguns ISPs europeus que simplesmente entregam aos consumidores a mangueira de incêndio da Internet sem portas bloqueadas e sem filtros.

Então, eu não tenho uma resposta para este, exceto "Verifique com seu ISP".