🚀 go-pugleaf

Lemat <#@lemat.priv.pl> pisze:
> W dniu 11.03.2020 o 22:48, Andrzej A. Filip pisze:
>> Lemat <#@lemat.priv.pl> pisze:
>>> Cześć,
>>>
>>> Mam taką konfigurację sendmaila:
>>>
>>> Kmailertable dbm /etc/mail/mailertable
>>>
>>> # not local -- try mailer table lookup
>>> R$* <@ $+ > $*          $: < $2 > $1 < @ $2 > $3        extract host name
>>> R< $+ . > $*            $: < $1 > $2                    strip trailing dot
>>> R< $+ > $*              $: < $(mailertable $1 $) > $2   lookup
>>> R< $~[ : $* > $*        $>MailerToTriple < $1 : $2 > $3         check --
>>> resolved?
>>> R< $+ > $*              $: $>Mailertable <$1> $2                try domain
>>>
>>>
>>> i w pliku mailertable wpisy:
>>>
>>> domena.cośtam error:5.7.1:550 nie ma jak dostarczyc
>>>
>>>
>>> problem mam ze zrozumieniem funkcjonalności, z tego co czytam to ma to
>>> działać jak transport_maps postfixa czyli dopasować adres odbiorcy do
>>> tego co stoi po lewej stronie i przekierować ją do tego, co stoi po
>>> prawej stronie.
>>>
>>> ALE okazuje się, że działa to też na adres nadawcy i w przypadku
>>> takiego wpisu z "error" nie przyjmuje mi takiej poczty.
>>>
>>> Jak najlepiej mieć listę domen, adresów email lub nazw.userów@ aby
>>> email był przyjmowany do kolejki a następnie przekierowywany do
>>> /dev/null
>>> Dotyczy to też DSNów, idących do nadawcy pasującego do takiej listy.
>>
>> Spróbuj DISCARD w access table.  Tyle że jeden z odbiorców z discard
>> innym odbiorcom wysyła tego maila do kosza  [chyba że dorzucisz an to R
>> linie do compat_check]. access table nie działa po adresach email
>> odbiorców bez FEATURE(blacklist_recipients). [A]
>>
>> A po co ci to?  [Jakiś spamtrap?]  IMHO rzadko kiedy discard jest
>> najlepszą opcją.
>>
>> [A] http://etutorials.org/Server+Administration/Sendmail/Part+II+Administration/Chapter+7.+How+to+Handle+spam/7.5+The+access+Database/
>>
>
> Dostałem w spadku system robiący za wewnętrzny relay.
> Nie filtruje to spamu. Nie przechowuje skrzynek userów. Działa tylko i
> wyłącznie jako rozrzutnik gnoju po LANie.
> Odbiera on pocztę od wielu serwerów lokalnych i albo dostarcza do
> smarthosta albo do serwerów zdefiniowanych w mailertable.
>
> Problemem jest kolejka emaili, przeważnie DSNów, które nie mogą zostać
> zwrócone do serwera, który je nadał.
>
> Czyli mam tak:
> przychodzi email root@serwer.domena.com -> user2@domena.com i zostaje
> zakolejkowany
> user2 nie istnieje, DSN jest wysyłany do nadawcy
> root@serwer.domena.com, który nie odbiera poczty, kolejka zapycha się
> takimi DSNami.
>
> Chciałbym aby emaile root@serwer.domena.com -> user@domena.com, gdzie
> odbiorca istnieje nadal były dostarczane.
> DSN  <> -> root@serwer.domena.com aby był skierowany do /dev/null od
> razu jak powstanie.
> Jak na razie ustawiłem:
> O Timeout.connect=30s
> O Timeout.queuereturn=1d
> O Timeout.queuereturn.dsn=30m
> no i te wpisy w mailertable, które mi zepsuły "normalną" pocztę.
>
> Szacuję, że połowa emaili przetwarzanych przez ten system jest
> niedostarczalna.
> Na relayu nie mam listy istniejących użytkowników w @domena.com ani
> tym bardziej w istniejących @subdomena.domena.com.
> Nie mam też oryginalnego pliku *.mc z którego została skompilowana
> konfiguracja.
> Co więcej mam mocno ograniczone możliwości przebudowania tego serwera
> (bo inaczej od razu bym postawił postifxa, na którym się znam)
>
> Z linku, który podałeś, wynika, że bym musiał jeszcze dorobić delay_checks

Możesz inaczej: osobna kolejka w sendmailu na bounce albo szerzej na
maile które stoją w kolejce głównej kilka godzin.

a) Zobacz czy twój sendmail ma wkompilowane  _FFR_BOUNCE_QUEUE
[FFR - For Future Release ]

echo "" | /usr/sbin/sendmail -bt -d0.14

Pewnie nie ma ale sprawdzić nie zaszkodzi.
Jak nie ma to przejdź do punktu "b".

b) użyj qtool.pl (powinno być w dystrybucji/pakietach sendmaila) do
przerzucania maili z kolejki głównej do dodatkowej
Tą kolejkę dodatkową możesz obrabiać sendmail-em startowanym z cron-a
z opcją "-O QueueDirectory=queuedir"

To jest tylko "pośredni środek zaradczy" a znając ciebie rozwiązanie
końcowe pewnie będzie z przejściem na postfixa :-)

-- 
Andrzej A. Filip