Komentarze i odpowiedzi, posortowane dla odmiany chronologicznie do strony:

1. nie, sprawdź różnicę - spróbuj się zatelnetować i zapodać HELO oraz EHLO. 2. dzięki, poprawiam

tego typu RBLe nie daje się w reject_rbl_client tylko wrzuca się je w konfiguracji spamassasina aby punktować. Jak klient jest w jednym RBLu to nic się nie stanie, jak juz jest w pięciu - to punkty przekraczają próg spamu.

ściągnij sobie zipa z moim konfigiem i zajrzyj do /etc/mail/cośtam

Na przyszłość napisz proszę na pl.comp.mail.mta, podając aktualny konfig postfixa i dokładne komunikaty błędów. te opcje są odpowiedzialne: reject_unknown_hostname, reject_non_fqdn_hostname,

najpierw musisz znaleźć te hosty, które maja nieprawidłowe helo - reject_warn + grep + czekać cierpliwie, potem wrzucić je na biała listę.

mam klientów na neostradzie (dul.sorbs), którzy by byli bardzo zawiedzeni nie mogąc wysłać poczty.

w trakcie przetwarzania smtpd_client_restrictions nie znamy nadawcy ani odbiorcy => greylisting nie będzie działał.

to ja może zauważę, że smtpd_sender_restrictions domyślnie kończy się na permit a powyższa reguła zacznie odrzucać wszystkie emaile przychodzące z zewnątrz do użytkownika naszego serwera. osobiście uważam, że to brak iptables -I FORWARD --dport 25 -p tcp -j DROP był przyczyną listowania w RBLach (o czym zresztą trąbię w innym miejscu na tej stronie) przemyśl proszę swoje stanowisko, a już na pewno swoją konfigurację.

użytkownicy serwera mogą przypadkowo trafić do RBLa, zatem umieszczenie sprawdzania RBLi w *client* jest zbyt wczesne (nie można ich uratować przez permit_sasl_authenticated, bo to jeszcze nie ten etap).

postfix to nie wróżka, on nie wie, czy ten klient, który się właśnie połączył a jakiś RBL go uwala z jakiegoś powodu to przypadkiem zamierza się uwierzytelnić czy też nie. On to będzie wiedział dopiero jak zaistnieje jakiś dialog pomiędzy nimi czyli dopiero na etapie smtpd_sender_restrictions. Zatem jeżeli jakis twój user ma szanse trafienia do RBLa to uwalanie po RBLach możesz zrobić dopiero jak już postfix będzie wiedział czy było uwierzytelnienie czyli co najmniej w smtpd_sender_restrictions.

ta polityka aby dawać RBLe w smtpd_recipient_restristions wzięła się stąd, że trzeba whitelistować adresy abuse@ i postmaster@, a postfix wie kto jest odbiorcą dopiero w smtpd_recipient_restrictions.

mutt pewnie nie przeprowadza sesji smtp tylko pcha mejla przez polecenie sendmail

reject_invalid_hostname Reject hostnames with bad syntax. windowsy mogą wysyłać bzdury, ale raczej to nie podpada pod "bad syntax"

nie, to jest w osobnej linii, jakby było to napisane w jednej linii to rzeczywiście by brakowało przecinka.

dać whitelistę z adresami IP przed reject_unauth_destination albo dać te adresy IP do mynetworks (bo permit mynetworks też jest przed RUD)

teoretycznie nie ma znaczenia - ja jednak mam SPF przed greylistngiem aby niepotrzebnie nie zapychać bazy danych greylistingu.

np. phpMyAdminem

smtp2-10.fr.grpleg.net powinien mieć rekord A. Najlepiej wskazujący na adres/y IP z którego serwer smtp nawiązuje połączenia. Dodatkowo w pliku strefy można wstawić rekord SPF dla tej nazwy: smtp2-10.fr.grpleg.net IN TXT "v=spf1....." PS. pytanie kwalifikuje się na pl.comp.mail.mta a nie tutaj

tak, ale dla mnie lepiej jest w logach widzieć, że ktoś się podszywa - wtedy jest to spamer - w odróżnieniu od przypadków złej konfiguracji serwera.

jest, szukaj hasła "policyd". Ale w tym momencie wytniesz wszystkie serwery z więcej niż jedną domeną na pokładzie czyli na przykład wszystkie hostingi. To już lepiej zainteresuj się sprawdzaniem SPFa dla nazwy podanej w EHLO

grupy dyskusyjne-> pl.comp.mail.mta

chodzi o to, że musisz adres IP tego sprzętowego antyspama whitelistować, np. dodać go do $mynetworks.

Fakt, opcja wygląda na przeznaczoną do likwidacji. Zapoznaj się z:
reject_unknown_sender_domain,
reject_non_fqdn_sender,

bo w smtpd_helo_restrictions odrzuciłoby połączenie od userów - rzadko który czytnik wysyła poprawne EHLO. Nawet gdybyś miał tak, że dany serwer nie obsługuje użytkowników a tylko i wyłącznie inne serwery to nie jest to słuszne posunięcie - bo nie pozwoli się skontaktować z twoim adresem postmaster@.

odradzam. Odsieje zbyt dużo serwerów SMTP bez skonfigurowanego revDNSa lub z błędnie skonfigurowanym revDNSem. Ponadto odsieje własnych użytkowników, którzy będą się łączyli z jakiejś sieci, która też nie ma poprawnych revDNSów.

pliki *.db powinny być tworzone komendą postmap

puste pole from oznacza wiadomość od postmastera o losach wiadomości (najczęściej, że nie dotarła) i jest to normalne. Jedyne co może być nienormalne, to powód dlaczego nie dotarła.

moim zdaniem nie powinieneś tego robić, dla przykładu ktoś może pisać do siebie aby zostawić sobie jakieś przypomnienie. Już lepiej by było sprawdzać czy Return-path jest takie same jak From: (ale tak samo śliskie)
Odpowiadając na pytanie: http://www.postfix.org/header_checks.5.html i składnia if-a + zmienne $1

inny vacation?

są 2 skrajności:
1) nawalić wszystko w smtpd_recipient_restrictions, pozostałe łańcuchy zostawiając puste
2) ustawić smtpd_deley_reject na "no" i odrzucać połączenie na jak najwcześniejszym etapie. Niektórzy wstawiają np CBLa w smtpd_client_restrictions.

sposób 1) pozwala na przyjęcie emaila do postmaster@ - w przypadku jakby ktoś na drugim końcu druta chciał się dowiedzieć za co jest blokowany.

sposób 2) oszczędza zasoby. Ale wymusza też zastosowanie permit_sasl_authenticated wszędzie tam, gdzie coś mogłoby uwalić lokalnego usera.

Ja stosuję coś pośrodku, czyli źle skonfigurowane serwer staram się uwalać w smtpd_recipient_restrctions a windowsy z wirusami - jak najwcześniej się da.

check_helo_mx_access jest po to, aby w przypadku spamruna z ustawioną domeną nadawcy np. lemat.priv.pl właściciel mógł zmienić rekordy DNS na 127.0.0.1 i chwilowo wyłączyć ją, zapobiegając backscatterowi.

powiem brutalnie: chcesz zjebać swój system poczty. Przywilej kombinowania z RFC zostaw teoretykom.

zapasowy musi mieć komplet danych z primary: listę domen, listę userów, listę aliasów. Taką kopię wszystkiego można zrobić albo rsyncem, albo *sqlem master-slave, albo ldap.

o ja pierdolę, przeczytaj z łaski swojej dokładnie to, co mam na stronie i kliknij jeden jedyny link opisujący co to jest *.rbl.tld

1) tak to jest to samo, musiało mi umknąć przy zmianie konfiguracji przy postfixie 2.3
2) szczerze mówiąc nie wiem dokładnie czym te 2 opcje się różnią - dlatego daję je obie w przypadku jakby jedna zawierała coś, czego druga nie ma.

1) jak masz fakeMX to nie możesz robić greylistingu, a ja uważam greylisting za bardziej skuteczną metodę filtrowania spamu.
2) nie znam statystyk pokazujących czy ta metoda jest skuteczna -

smtpd_helo_restriction = permit_mynetworks, check_helo_access hash:/etc/postfix/helo_chcecks, permit

musiałbyś napisać własny content filter...

przepis na konfigurację jest aktualny

zapraszam na pl.comp.mail.mta, gdzie podasz swój konfig i/lub przykład listu, który przechodzi przez filtry.

smtpd_client_event_limit_exceptions

smtpd_client_restrictions jest sprawdzane jak tylko klient się podłączy i nawet jeszcze nie zdąży przesłać jednego bajta a tym bardziej loginu i hasła. Dlatego permit_sasl_authenticated w smtpd_client_restrictions nie ma sensu. permit_sasl_authenticated ma sens dopiero w smtpd_sender_restrictions i wszystko to, co jest zależne od tego czy user jest zautoryzowany czy nie (np. RBLe) trzeba przenieść za permit_sasl_authenticated. Chyba, że jest to RBL o wysokiej wiarygodności a ty usiłujesz dać userowi do zrozumienia, że ma wirusa i fora ze dwora. WP.pl kiedyś tak zrobiło z CBLem.

podobnie twój plik access (chociaż patrz dalej) - wymaga przesłania adresu nadawcy i jego sprawdzenia w pliku a to jest robione/sprawdzane w smtpd_sender_restrictions

muszą być albo przecinki albo znaki nowej linii - jakiś rozdzielacz musi być aby postfix się nie pogubił w regułach dwuczłonowych.

sbl-xbl.spamhaus.org zawiera w sobie cbl.abuseat.org, niepotrzebnie robisz 2 zapytania i obciążasz i swój system i te RBLe

"bo szef nie zgadza sie" - podaj adres swojego serwera to zrobię twojemu szefowi jesień średniowiecza ze skrzynki... powiedz mu, że sprzątaczka może wysłać emaila w jego imieniu do księgowości nakazującego wypłatę jej premii za 10 lat w przód... i możesz moją wypowiedź mu pokazać po fakcie...
pewnym workaroundem jest zrobienie popbeforesmtp. A to, że jeden szef nie chce kliknąć nie oznacza, że nie możesz mieć zainstalowanego sasla - no przecież to działa niezależnie.

skoro nie masz sasla to permit_sasl_authenticated w ogóle jest bez sensu - no bo przecież nie masz sasla

twój /etc/postfix/access powinien zawierać adresy IP lub revDNSy bo check_client_access oznacza klienta czyli adres IP lub revDNS.
jeżeli miałby zawierać adresy email to musiałby to być check_sender_access, ale w tym momencie to tworzysz open-relaja i w tym momencie to nie tylko twój szef będzie miał przesrane, ale ty osobiście też. Mieszkasz niedaleko, bo tylko w Łodzi...

następnym problemem jest to 450tka w komunikacie, zajrzyj do artykułu błędy w konfiguracji postfixa ->Właściwe 55X na właściwym miejscu

widzisz, przyszedłeś tu z jednym problemem a wyszedłeś z pięcioma, opłacało się? ;)

po pierwsze "not logged in" oznacza że user nie jest zalogowany. Czyli albo nie zaznaczył w outlooku "ten serwer wymaga uwierzytelnienia" albo twój serwer nie ma sasla. I zanim zaczniesz grzebać przy smtpd_sender_login_maps musisz rozwiązać ten problem.

jakby to było "not owned" to byłby problem właśnie z tabelą smtpd_sender_login_maps

w smtpd_sender_login_maps w lewej kolumnie masz adresy email, w prawej kolumnie masz wszystkie loginy, które mogą używać tego adresu email rozdzielone przecinkami i/lub spacjami

i teraz nie wiem, co u ciebie jest loginem, domyślam się, że masz konta systemowe - wobec tego loginem nie jest adres email tylko samo username np. "wlodek", czyli tabela wygląda tak:

wlodek@domena.pl wlodek
w.nowak@domena.pl wlodek
wlodzimierz.nowak@domena.pl wlodek

jak zrobisz grep "not owned" mail.info to masz na tacy podane jaki email i jaki login są sparowane, zazwyczaj jest tak, że userzy mają tylko jedną linię w pliku - tylko jeden adres email jest używany do poczty wychodzącej. Outlook chyba nie pozwala na więcej - trzeba by tworzyć osobne konto/tożsamość.

na pl.comp.mail.mta była o tym dyskusja...
samym postfixem nie da się, można to spróbować zrobić w spamassassinie:

Received: from quad.localnet (quad.lemat.priv.pl [192.168.0.11])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
(Authenticated sender: ja@mojadomena.tld)
by poczta.lemat.priv.pl (Postfix) with ESMTPSA id 6242441CDC
for < ja@mojadomena.tld >; Tue, 20 Mar 2012 19:33:00 +0100 (CET)
From: Lemat < ja@mojadomena.tld >

najpierw należy wykryć takie From, które zawiera twoją domenę lokalną

header __LOCAL_FROM From =~ /\@mojadomena.tld/

następnie takie Received, które zawiera twoją nazwę serwera i "Authenticated sender" (trzeba włączyć smtpd_sasl_authenticated_header = yes)

header __LOCAL_AUTH Received =~ /Authenticated sender: [^@]+\@mojadomena.tld\) by poczta.lemat.priv.pl/

i stworzyć metę:

meta LOCAL_FROM_UNAUTH __LOCAL_FROM && ! __LOCAL_AUTH

coś w ten deseń (nie testowałem, nie wiem czy działa, możesz zostać królikiem)
można spróbować z użyciem X-Spam-Relays-Trusted, tam jest ustandaryzowane

tak, przed check_sender_access trzeba wstawić check_client_access z adresem IP tego serwera LUB (niepolecane) w check_sender_access dodać linijkę:
user@domena DUNNO

trzeba przeanalizować treść całego emaila i wszystkie nagłówki received - czy występuje w nich nasz serwer. Problem jest w tym, że takie nagłówki można fałszować/dodawać. I spamerzy już to robią.

Sender Rewrite Scheme

przed regułką sprawdzającą (odrzucającą po) EHLO dać wyjątek w postaci adresu IP.

sprawdziłem, body_checks działa na całym emailu i działa też na załączniku txt

jeżeli załącznik zakodowany jest np. do base64 to body_checks nie działają, trzeba to robić przez spamassassina, który najpierw odkoduje do plain-tekstu a potem przeszuka

nie da się, od tego jest spamassassin i amavis

Używając wszystkiego co widać na mojej stronie.

google: "lemat spamassassin"

Ostatnio zrobiłem i sprzedałem i skonfigurowałem soft (skrypty) limitujący ilość emaili od danego user do powiedzmy 100/h.
A Wam przyda się po prostu Regulamin oraz admin, który nie boi się wypieprzać spamerów. W Regulaminie trzeba zawrzeć klauzulę wymuszającą na kliencie słoną opłatę za spowodowanie niestabilnego działania usługi.

zapytaj na pl.comp.mail.mta, bo ja się też z takim komunikatem nie spotkałem. Nie masz przypadkiem jakiegoś znaku specjalnego w emailu nadawcy? np. paweŁ.us@coŚtam.pl ?

Hmm, żaden z serwerów DNS dla twojej domeny a-n.pl nie odpowiada.

wtedy zaglądamy do źródła emaila i oglądamy sobie nagłówek dodany przez smtpd_sasl_authenticated_header = yes (w połączeniu z reject_sender_login_mismatch)

query=SELECT cośtam FROM tabelka WHERE '%s' REGEXP kolumna

eeee, jak na moje zwrot zawsze następuje do nadawcy (do adresu kopertowego). Czyżby twoi userzy wysyłali z webmaila i nadawcą był apacz? No to trzeba skonfigurować webmaila aby uzywał loginu i hasł użytkownika do autoryzacji.

sender_canonical ?

Jedyne co mogę zaproponować to to, abyś w jakiś sposób, może np. aliasem albo canonicalem skierował wszystko to, co idzie na noreply@nazwa.domeny do twórców tej aplikacji. Bo ewidentnie zjebali robotę. Postfix sam z siebie widzi tylko adresy kopertowe nadawcy i odbiorcy. Czyli nie widzi nagłówka "Reply-To". Zatem postfix sam z siebie nie dostarczy zwrotki do adresu wskazanego w "Reply-To"

już to kiedyś robiłem przez policyd.
jeżeli znasz się trochę na programowaniu to polecam przerobić policyd-lemat2
zgłoś się do mnie na priv

wysłać:
cd /var/mail/cośtam/cur
for i in *; do cat $i | sendmail jakieś opcje nowe@konto.example; done

musisz stworzyć konstrukcję:


smtpd_recipient_restrictions =
# zamiast permit_sasl_authenticated
check_client_access hash:/etc/postfix/dozwolone_do_logowania.hash

plik /etc/postfix/dozwolone_do_logowania.hash zawiera sieci, np.

.pl permit_sasl_authenticated
1.2.3.4 permit_sasl_authenticated
127.0.0.1 permit_sasl_authenticated

i tylko te sieci wymienione explicite w tym pliku będą mogły używać logowania
Oczywiście operację powtarzasz dla portu 465 i 587 (-o w master.cf)
Pamiętaj też o webmailu aby dać odpowiednie "Allow from" w apaczu

na postfixie nie da się, bo exchange dodaje nagłówek od kogo otrzymał emaila. I wstawi tam twojego postfixa a nie serwer nadawcy. To na exchange musiałbyś usunąć pierwszy nagłówek received.

a ja mam wcześniej whitelistę serwerów, które mi forwardują pocztę...

albo masz gdzieś głupią literówkę albo brak postmapa albo twój klient poczty nie wysyła loginu i hasła.

1) sprawdzanie EHLO musi być za permit_sasl_authenticated gdyż/ponieważ klient pocztowy może wysłać różne ciekawe rzeczy na przykład windowsową nazwę kompa lub numer IP.

2) RBLe muszą być za permit_sasl_authenticated gdyż/ponieważ luser może odziedziczyć po kimś zblacklistowane IP neostrady.

3) w dokumentacji postfixa jest to cienko opisane co robią tak naprawdę obie funkcje - przydałyby się przykłady jakie EHLO jest poprawny w jednej a niepoprawny w drugiej. Stąd też ja wychodzę z założenia, że jeszcze jeden check nawet jak nie pomoże - to nie zaszkodzi.

Gratulacje, właśnie odkryłeś Amerykę, że protokół SMTP umożliwia podszywanie się. Potrzebne ci SPF.

header_checks i body_checks nie działają jeżeli masz włączony content-filter taki jak np. amavis

policyd-lemat3

('*','*','all@[domena]','REJECT','nie masz uprawnien'),
('*','[domena]','all@[domena]','DUNNO',''),

jest u mnie w zipie z konfiguracją

no to robisz dodatkową kolumnę w bazie danych i ją ma zwracać zapytanie. Możesz też złączyć kolumnę username i tą dodatkową, tak aby utworzyć listę adresów.

dovecot wspiera sieve, nie pamiętam czy w archaicznej wersji 1 też.

mylisz się, check_sender_access sprawdza sendera a jest to reguła w łańcuchu smtpd_recipient_restrictions który jest uruchamiany jak w sesji dojdzie do "rcpt to".

Na pocieszenie powiem Ci, że jest to nagminny błąd rozumowania, także w wielu oficjalnych poradnikach.

fragment konfiguracji dovecota:

password_query = SELECT username as user, password, CONCAT('::1,',allow_nets) as allow_nets FROM mailbox WHERE (username='%u' AND active = 1

gdzie kolumna allow_nets zawiera listę sieci dozwolonych.

Podana przez Ciebie strona przedstawia proces instalacji a nie konfiguracji antyspamowej. U mnie jest to cały dział o podszywaniu, który odpowiada na twój problem.

w logach masz sendera kopertowego
w programach pocztowych masz sendera nagłówkowego

to tak jak z listem papierowym: na kopercie możesz mieć innego nadawcę/odbiorcę niż na papierze listowym w środku.
wrzuć do header_checks

/^From:/ WARN
i zobacz co będziesz miał od tej pory w logach


Jeżeli chcesz się pozbyć problemów z phishingiem "your account has been hacked"

zainstaluj opendkim, opendmarc
umieść w DNSie info, że podpisujesz 100% listów

w opendmarc.conf albo zrób:

RejectFailures true

albo w spamassassnie podnieś punktację:
score FREEMAIL_FORGED_FROMDOMAIN
score HEADER_FROM_DIFFERENT_DOMAINS
score DKIM_ADSP_DISCARD

zobacz wszystkie rule w /usr/share/spamassassin/*

Gdy przyjdzie email zawierający twoją domenę w nagłówku From to opendkim stwierdzi, że wiadomość nie jest podpisana (a powinna) i będzie można ją odrzucić lub wypunktować.

bo kolejność reguł ma znaczenie, sprawdzanie helo ma nastąpić po sprawdzeniu autoryzacji.

Teoretycznie każdą regułę można umieścić w każdym łańcuchu. Nie będzie to powodowało błędów składniowych.
ALE łańcuchy są uruchamiane gdy nastąpił odpowiedni etap w sesji SMTP. Czyli na przykład w smtpd_client_restrictions nie ma sensu sprawdzać niczego na podstawie odbiorcy, bo na tym etapie odbiorca nie jest jeszcze znany (chyba, że jest delay_reject).

Do tematu należy podchodzić niezwykle ostrożnie. Spamerzy fałszują adres nadawcy i gdybyś odbijał taki spam to trafisz do backscatterer.org.

Standardowo robi się to tak:

Amavisa ustawia się jako proxy-filter,
$final_spam_destiny = D_REJECT;

%smtp_reason_by_ccat = (
CC_VIRUS, 'id=%n, %x see http://www.lemat.priv.pl/spam/',
CC_BANNED, 'id=%n, %x see http://www.lemat.priv.pl/spam/',
CC_UNCHECKED, 'id=%n, %x see http://www.lemat.priv.pl/spam/',
CC_SPAM, 'id=%n, %x see http://www.lemat.priv.pl/spam/',
CC_SPAMMY, 'id=%n, %x see http://www.lemat.priv.pl/spam/',
CC_BADH.",2", 'id=%n, %x see http://www.lemat.priv.pl/spam/',
CC_BADH, 'id=%n, %x see http://www.lemat.priv.pl/spam/',
CC_OVERSIZED, 'id=%n, %x see http://www.lemat.priv.pl/spam/',
CC_CATCHALL, 'id=%n, %x see http://www.lemat.priv.pl/spam/',
);

I na tej stronie www podajesz już szerszą informację.

Amavis ma też opcję wysyłania wiadomości email:

$final_spam_destiny = D_BOUNCE;

I odpowiedni config do tego:

# cat /etc/amavis/conf.d/30-template_localization
use strict;

# l10n (localization) of the AMaViSd-new DSN templates
# Override or change as necessary

# Select notifications text encoding when Unicode-aware Perl is converting
# text from internal character representation to external encoding (charset
# in MIME terminology). Used as argument to Perl Encode::encode subroutine.
#
# to be used in RFC 2047-encoded header field bodies, e.g. in Subject:
#$hdr_encoding = 'iso-8859-1'; # (default: 'iso-8859-1')
#
# to be used in notification body text: its encoding and Content-type.charset
#$bdy_encoding = 'iso-8859-1'; # (default: 'iso-8859-1')

# Default template texts for notifications may be overruled by directly
# assigning new text to template variables, or by reading template text
# from files. A second argument may be specified in a call to read_text(),
# specifying character encoding layer to be used when reading from the
# external file, e.g. 'utf8', 'iso-8859-1', or often just $bdy_encoding.
# Text will be converted to internal character representation by Perl 5.8.0
# or later; second argument is ignored otherwise. See PerlIO::encoding,
# Encode::PerlIO and perluniintro man pages.
#
# $notify_sender_templ = read_text('/var/amavis/notify_sender.txt');
# $notify_virus_sender_templ= read_text('/var/amavis/notify_virus_sender.txt');
# $notify_virus_admin_templ = read_text('/var/amavis/notify_virus_admin.txt');
# $notify_virus_recips_templ= read_text('/var/amavis/notify_virus_recips.txt');
# $notify_spam_sender_templ = read_text('/var/amavis/notify_spam_sender.txt');
# $notify_spam_admin_templ = read_text('/var/amavis/notify_spam_admin.txt');

# If notification template files are collectively available in some directory,
# you can use read_l10n_templates which calls read_text for each known
# template. Name the files as above, and include a file named "charset" with
# the charset used in the files. This is how Debian ships l10n templates.
#
# syntax: read_l10n_templates(); OR
# read_l10n_templates(, );
#
read_l10n_templates('en_US', '/etc/amavis');


# ls /etc/amavis/en_US/
charset template-auto-response.txt template-dsn.txt template-problem-feedback.txt template-release-quarantine.txt template-spam-admin.txt template-spam-sender.txt template-virus-admin.txt template-virus-recipient.txt template-virus-sender.txt


ALE ja nie polecam tej drugiej opcji.

komunikat "Sender address rejected: not logged in" oznacza, że reject_sender_login_mismatch działa, bo to dokładnie jest ta opcja która jest powodem tego komunikatu. To tak będąc dokładnym.

Szklana kula mi mówi, że chcesz osiągnąć efekt przeciwny, to znaczy masz serwer A, który wysyła emaile do innego serwera B, z nadawcą będącym userem z serwera B.

No to na serwerze B przed reject_sender_login_mismatch musisz dodać np. check_client_access i na liście adres IP serwera A.

Albo jeszcze jedna możliwość - nie masz na porcie 25 włączonego SASLa

jedyne, co mi przychodzi do głowy to:

1) check_CLIENT_access wymaga pliku z adresami IP lub revDNSami a ty tam wstawiłes adresy email/domeny nadawcy, albo zmień dane w pliku albo użyj check_SENDER_access,
2) różnica w nazwach, które pojawiają się w logach i ta, które jest w pliku.
3) reverseDNS nie spełniający pętli zwrotnej - nazwa nie pasuje do IP z którego była wzięta, no ale jak na moje to w logach by było unknown[1.2.3.4], sprawdź check_reverse_client_hostname_access?

SOA#1 u mnie działa

header_checks = pcre:/etc/postfix/header_checks.pcre

/^From: jakieś wyrażenie regularne/ REJECT