Нужна помощь, чтобы исправить мой скрипт bash

В cron и MUA -Подключение MTA

Практические ответы

Обычно я создаю постфиксный псевдоним для своих пользователей cron. Таким образом, все письма о заданиях cron доставляются на псевдоним адреса в моей таблице поиска.

• Таким образом, практический ответ таков::

Сообщения Cron можно отправлять с сервера/домена/машины на любой произвольный адрес электронной почты в Интернете.

Более того, сам cronможет быть сконфигурирован для использования любого произвольного почтовика MTA.

Из моего исходного дерева cron в 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"      -*/

• Итак, второй практический ответ:

Cron можно скомпилировать для использования любого произвольного MTA

Теоретический ответ

Как указано в комментариях и других ответах, cronдействует как MUA. У него нет кодовой базы для фактической отправки сообщений куда-либо, кроме заранее определенного агента передачи сообщений, расположенного на его собственной логической машине. Полезно отметить, что логическая машина может фактически не совпадать с физической машиной.

Об использовании MTA для отправки электронных писем

Прямое подключение к MTA через его SMTP-порт

Электронное письмо можно отправить напрямую через MTA, подключившись к его SMTP.URL:portи выполнив любую аутентификацию вручную.

telnet example.com 25

Обычно работает, если доступ к порту 25 разблокирован через подключающегося интернет-провайдера. И вы получите сообщение, похожее на это:

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)

Но... большинство интернет-провайдеров блокируют соединение через порт 25. И этот метод отправки электронной почты является громоздким, поэтому обычно используется хорошо спроектированный MUA, такой как sylpheedили thunderbird.

Почему интернет-провайдеры блокируют стандартный порт SMTP :25

Большинство пользователей Интернета подключаются к глобальной сети (WAN )через интернет-провайдера (ISP ). Эти интернет-провайдеры обычно блокируют общие порты, которые используются для запуска интернет-служб, таких как HTTP (80 )SMTP (25 )и несколько возможных других.

Как правило, у интернет-провайдеров есть соглашение об условиях со своими клиентами, которое запрещает запуск интернет-услуг из их сети. Есть по крайней мере две причины для такой общей политики интернет-провайдера:

1. Интернет-службы потребляют пропускную способность.
2. Интернет-провайдеры действуют как минимальный барьер для многих спамеров электронной почты или вредоносных веб-служб.

Интернет-провайдеры также обычно заносят в черный список свои собственные пулы динамических IP-адресов. Таким образом, любые почтовые службы, работающие с динамического IP-адреса интернет-провайдера, с большой вероятностью будут либо отклонены, либо помещены непосредственно в папку «спам» любого крупного почтового провайдера.

Блокировка IP из черного списка

Черный список IP-адресов очень прост и эффективен. Он используется в конфигурации MTA для немедленного отклонения входящей почты, исходящей из домена, занесенного в черный список.

/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
...

Пример из одного из моих реальных журналов сервера:

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=<yuuki429@xxxx.xxx.xxx.jp> to=<xxx@example.com> proto=ESMTP helo=<xxxx.xxx.xxx.jp>

Эффективность блокировки портов и RBL в эпоху ботнетов

Эти политики были более эффективными до появления -веб-серверов по требованию. По моему опыту, спамеры и злоумышленники просто перешли от служб, подключенных к интернет-провайдерам, к ботнетам и -по запросу к командным и управляющим (C&C )серверам.

Большинство атак спама или грубой силы против моих собственных серверов начинаются с проверки C&C, которая обычно запускается с IP-адреса Amazon EC2. Затем последовала серия ботнетов с адресов где-то в далеких странах.

Интернет-провайдеры, которые не блокируют порты

Я не уверен, разрешают ли какие-либо интернет-провайдеры в США все порты. Тем не менее, я видел некоторых европейских интернет-провайдеров, которые просто раздавали потребителям пожарный шланг Интернета без заблокированных портов и фильтров.

Итак, у меня нет ответа на этот вопрос, кроме «Проверьте у своего интернет-провайдера».