Я экспериментировал с моим интерфейсом WiFi, который также имеет carrier
псевдофайл :/sys/class/net/wlan0/carrier
. (примечание: я использовал nmtui
для включения/выключения беспроводных сетей).
Похоже, есть три состояния:
./carrier
не читается (например, когда интерфейс отключен в Network Manager). ./carrier
содержит "1" (когда интерфейс активирован и подключен к сети WiFi)./carrier
содержит "0" (когда интерфейс активирован и не подключен к сети WiFi)
if ! cat /sys/class/net/wlan0/carrier > /dev/null; then
echo "Not connected to any network"
elif [ "$(head -c1 /sys/class/net/wlan0/carrier)" -eq 1 ]; then
echo "Connected to a wireless network"
elif [ "$(head -c1 /sys/class/net/wlan0/carrier)" -eq 0 ]; then
echo "Not connected to a wireless network"
else
echo "Unknown/Unhandled state"
fi
«разрешить, только если установлено» намного сложнее, чем связанное «запретить, если set"; "deny if set" просто отклоняет сообщение, когда заголовок имеет определенное значение. «Разрешить, только если установлено» вместо этого должно быть отмечено соответствующие сообщения как разрешенные, но потом также где-то еще запрещают все другие сообщения. Еще одна сложность для «разрешить, только если установлено» возможность системных сообщений (например. те из cron ), которые также могут понадобиться быть разрешенным, и в этом случае общего отказа будет недостаточно. Все же еще одна проблема заключается в том, позволяют ли ваши системы удаленную ретрансляцию; если так и если набор правил создан неправильно, вы можете превратить свои серверы в открытые реле для всех, кто устанавливает соответствующее поле заголовка. Это может быть плохо, и если вы где-нибудь не уберете тестовый заголовок, он будет виден всем, кто может читать сообщения из вашей системы.
Одним из методов может быть проверка в конце заголовков, имеет ли X-Test
был замечен; если нет, отклоните сообщение. Это приведет к сбою системных сообщений которые не имеют установленного заголовка, но не должны превращать систему в open relay, так как различные другие наборы правил должны по-прежнему применяться для определения права ретрансляции. Таким образом, в sendmail.mc
добавьте что-то вроде:
LOCAL_RULESETS
Kstorage macro
HX-Test: $>CheckTestHeader
SCheckTestHeader
R$* $: $(storage {xtestsetp} $@ OK $) $1
Scheck_eoh
R$* $: < $&{xtestsetp} >
R$* $: $(storage {xtestsetp} $) $1
R< $+ > $@ OK
R$* $#error $: 553 Missing Header
и перестроить sendmail.cf
, перезапустить sendmail
, отправить тестовые сообщения с и без тестового заголовка.
Эти прогоны «много пробелов» должны быть заменены одной или несколькими вкладками. символов, так как Sendmail — одна из тех неудачных программ, которые предписывает использование значительных пробелов (безумие, я знаю, но вот и мы ).
Дополнительную информацию об этом примере см. в разделе 5.1.4.6 документа Sendmail. op.pdf
мануал, из которого более-менее списано вышеизложенное.
Также обратите внимание, что описанное выше следует использовать только на сервере исходящей почты. конфигурации, так как он будет отклонять входящую почту, которая не имеет требуемый заголовок.
@thrig еще раз спасибо за ваши предложения. Я должен понять, как пишутся правила, и поэтому занял это время. Я изменил набор правил, заданный (, так как мне нужно разрешить заголовок, а не остановить ), поэтому в sendmail.mc добавляются следующие строки, и я получаю желаемый результат. Мне еще предстоит проверить это на нашей предварительной -prod ферме, но это дало мне некоторое представление о том, как двигаться дальше.
Я создал небольшой скрипт на Python, который помогает мне создавать нужные мне заголовки и отправлять их. Приведенный ниже набор правил разрешает заголовок «X -Test», что является моим требованием, поскольку моя таблица рассылки отклоняет любые другие электронные письма на основе доменов, перечисленных ранее. Appreicate если вы обратная связь с любыми недостатками.
ЛОКАЛЬНЫЕ _НАБОРЫ ПРАВИЛ Макрос хранилища HX -Тест :$>CheckTestHeader
Счекктестхеадер R$ *$ :$ (хранилище {xtestsetp} $@ OK $ )$1 R< $+ > $@ ОК