info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
sendmail podkręcenie zabezpieczeń
6 views
Skip to first unread message
LFC
Apr 1, 2020, 3:00:02 AM4/1/20
to
Serwer w mojej firmie służył do poczty korporacyjnej, więc działał sobie
na porcie 25 i jako tako to funkcjonowało.
Teraz w związku z akcją "siedź w domu" zarząd sobie zażyczył, żeby mógł
odbierać i wysyłać również pocztę w domu.
Z odbiorem nie ma problemu bo port 995, natomiast wysyłka na ogół nie
była możliwa ponieważ niektórzy ISP blokują port 25, a sieci
dynamicznego IP są w dnsbl.
W związku z tym aktywowałem sendmailowi port 587 i dodałem opcję
`delay_checks', `friend', a do access dopisałem:
Spam:adr...@domena.com.pl
...
I działa, ale widzę, że choć w sendmail.mc dałem Family=inet dla demona
przy obu portach to i tak zaczęły mi włazić hosty ipv6.
Zablokowałem INPUT dla ipv6, ale widzę w mquee i w logach jakieś hosty
ze świata np z Ukrainy przedstawiają się jako nasza domena i pakuja spam
aż miło. Jak to ukrócić?
Myślałem o opcji rela based_on_MX, ale wtedy każdy cwaniak, który sobie
wpisze w domenę nasz serwer jako MX bedzie mógł relayowac do woli.
Jakies sugestie?
LFC
na porcie 25 i jako tako to funkcjonowało.
Teraz w związku z akcją "siedź w domu" zarząd sobie zażyczył, żeby mógł
odbierać i wysyłać również pocztę w domu.
Z odbiorem nie ma problemu bo port 995, natomiast wysyłka na ogół nie
była możliwa ponieważ niektórzy ISP blokują port 25, a sieci
dynamicznego IP są w dnsbl.
W związku z tym aktywowałem sendmailowi port 587 i dodałem opcję
`delay_checks', `friend', a do access dopisałem:
Spam:adr...@domena.com.pl
...
I działa, ale widzę, że choć w sendmail.mc dałem Family=inet dla demona
przy obu portach to i tak zaczęły mi włazić hosty ipv6.
Zablokowałem INPUT dla ipv6, ale widzę w mquee i w logach jakieś hosty
ze świata np z Ukrainy przedstawiają się jako nasza domena i pakuja spam
aż miło. Jak to ukrócić?
Myślałem o opcji rela based_on_MX, ale wtedy każdy cwaniak, który sobie
wpisze w domenę nasz serwer jako MX bedzie mógł relayowac do woli.
Jakies sugestie?
LFC
Piotr Lechowicz
Apr 1, 2020, 7:32:41 PM4/1/20
to
W dniu 2020-04-01 o 08:55, LFC pisze:
> i dodałem opcję `delay_checks', `friend', a do access dopisałem:
> Spam:adr...@domena.com.pl
> ...
> I działa, ale widzę, że choć w sendmail.mc dałem Family=inet dla demona przy obu portach to i tak zaczęły mi włazić hosty ipv6.
A potrzebujesz wogóle dostępu do usług po IPv6?
Na interfejsie publicznym serwera masz włączone IPv6? Może wystarczy wyłączyć?
> Zablokowałem INPUT dla ipv6,
Jeżeli wyciąłeś ruch IPv6 na firewallu, to jaki cudem ten ruch dociera do serwera SMTP?
> ale widzę w mquee i w logach jakieś hosty ze świata np z Ukrainy przedstawiają się jako nasza domena i pakuja spam aż miło. Jak to ukrócić?
> Myślałem o opcji rela based_on_MX, ale wtedy każdy cwaniak, który sobie wpisze w domenę nasz serwer jako MX bedzie mógł relayowac do woli.
> Jakies sugestie?
>
Żaden cwaniak nie ma szans "relayować" przez twój serwer, o ile mu w konfiguracji tego nie umożliwisz!
relay_based_on_MX to właśnie taka furtka.
O ile kojarzę, to masz już milter-regex?
Żeby zabezpieczyć swój serwer, spróbuj:
ME = ( helo /^10\.10\.10\.10$/ or helo /^localhost$/ or helo /^poczta\.example\.com$/ or helo /^mail\.example\.com$/ )
REALLY_ME = ( connect /localhost/ /127\.0\.0\.1/ or connect /^poczta\.example\.com$/ /10\.10\.\10\.10/ )
discard
$ME and not $REALLY_ME
Zastosowane w przykładzie dane serwera SMTP:
poczta.example.com to podstawowa, a mail.example.com to dodatkowa nazwa FQDN serwera - jeżeli jest skonfigurowana
10.10.10.10 to adres IP ustawiony w rekordzie A dla poczta.example.com (zwykle adres publiczny serwera SMTP)
Ustaw to na początku konfiga, zaraz po wyjątkach na zaufane lub uwierzytelnione hosty.
Żeby umożliwić weryfikację dla innych serwerów przeczytaj
https://serverfault.com/questions/415533/how-to-stop-people-from-using-my-domain-to-send-spam
i zainteresuj się tematem SPF http://www.openspf.org/ (chociaż pasywnie) oraz DKIM https://pl.wikipedia.org/wiki/DomainKeys_Identified_Mail
> LFC
>
> Serwer w mojej firmie służył do poczty korporacyjnej, więc działał sobie na porcie 25 i jako tako to funkcjonowało.
> Teraz w związku z akcją "siedź w domu" zarząd sobie zażyczył, żeby mógł odbierać i wysyłać również pocztę w domu.
> Z odbiorem nie ma problemu bo port 995, natomiast wysyłka na ogół nie była możliwa ponieważ niektórzy ISP blokują port 25, a sieci dynamicznego IP są w dnsbl.
> W związku z tym aktywowałem sendmailowi port 587
I dobrze, wysyłanie przez MSA z obligatoryjnym szyfrowaniem i uwierzytelnieniem to w zasadzie jedyne sensowne rozwiązanie.
> Teraz w związku z akcją "siedź w domu" zarząd sobie zażyczył, żeby mógł odbierać i wysyłać również pocztę w domu.
> Z odbiorem nie ma problemu bo port 995, natomiast wysyłka na ogół nie była możliwa ponieważ niektórzy ISP blokują port 25, a sieci dynamicznego IP są w dnsbl.
> W związku z tym aktywowałem sendmailowi port 587
> i dodałem opcję `delay_checks', `friend', a do access dopisałem:
> Spam:adr...@domena.com.pl
> ...
> I działa, ale widzę, że choć w sendmail.mc dałem Family=inet dla demona przy obu portach to i tak zaczęły mi włazić hosty ipv6.
Na interfejsie publicznym serwera masz włączone IPv6? Może wystarczy wyłączyć?
> Zablokowałem INPUT dla ipv6,
Jeżeli wyciąłeś ruch IPv6 na firewallu, to jaki cudem ten ruch dociera do serwera SMTP?
> ale widzę w mquee i w logach jakieś hosty ze świata np z Ukrainy przedstawiają się jako nasza domena i pakuja spam aż miło. Jak to ukrócić?
> Myślałem o opcji rela based_on_MX, ale wtedy każdy cwaniak, który sobie wpisze w domenę nasz serwer jako MX bedzie mógł relayowac do woli.
> Jakies sugestie?
>
relay_based_on_MX to właśnie taka furtka.
O ile kojarzę, to masz już milter-regex?
Żeby zabezpieczyć swój serwer, spróbuj:
ME = ( helo /^10\.10\.10\.10$/ or helo /^localhost$/ or helo /^poczta\.example\.com$/ or helo /^mail\.example\.com$/ )
REALLY_ME = ( connect /localhost/ /127\.0\.0\.1/ or connect /^poczta\.example\.com$/ /10\.10\.\10\.10/ )
discard
$ME and not $REALLY_ME
Zastosowane w przykładzie dane serwera SMTP:
poczta.example.com to podstawowa, a mail.example.com to dodatkowa nazwa FQDN serwera - jeżeli jest skonfigurowana
10.10.10.10 to adres IP ustawiony w rekordzie A dla poczta.example.com (zwykle adres publiczny serwera SMTP)
Ustaw to na początku konfiga, zaraz po wyjątkach na zaufane lub uwierzytelnione hosty.
Żeby umożliwić weryfikację dla innych serwerów przeczytaj
https://serverfault.com/questions/415533/how-to-stop-people-from-using-my-domain-to-send-spam
i zainteresuj się tematem SPF http://www.openspf.org/ (chociaż pasywnie) oraz DKIM https://pl.wikipedia.org/wiki/DomainKeys_Identified_Mail
> LFC
>
LFC
Apr 3, 2020, 12:00:02 AM4/3/20
to
W dniu 2020-04-02 o 01:31, Piotr Lechowicz pisze:
>> I działa, ale widzę, że choć w sendmail.mc dałem Family=inet dla
>> demona przy obu portach to i tak zaczęły mi włazić hosty ipv6.
> A potrzebujesz wogóle dostępu do usług po IPv6?
> Na interfejsie publicznym serwera masz włączone IPv6? Może wystarczy
> wyłączyć?
I to mnie właśnie zdziwiło,bo mam zdisablowane ipv6.
sendmail był ustawiony w konfigu dla Family=inet, a więc ipv4, a mimo to
z opcją delay_checks przyjmował również ipv6.
>
>> ale widzę w mquee i w logach jakieś hosty ze świata np z Ukrainy
>> przedstawiają się jako nasza domena i pakuja spam aż miło. Jak to
>> ukrócić?
>> Myślałem o opcji rela based_on_MX, ale wtedy każdy cwaniak, który
>> sobie wpisze w domenę nasz serwer jako MX bedzie mógł relayowac do woli.
>> Jakies sugestie?
>>
> Żaden cwaniak nie ma szans "relayować" przez twój serwer, o ile mu w
> konfiguracji tego nie umożliwisz!
Cyrk się zaczął dziać, jak ustawiłem sendmailowi w konfigu opcję
`delay_checks', która jeżeli dobrze zrozumiałem ma opóźniać testy
sendmaila do momentu autoryzacji, po poprawnej autoryzacji usera nie
powinny być robione. Efekt był taki, że nie dośc, że pakowały się hosty
po ipv6, to jeszcze różne ruskie i ukraińskie spam serwery przedstawiały
się jako moja domena i pakowały spam rzekomo od us...@domena.com.pl i to
fikcyjnego usera na adresy ze świata.
Potrzebowałem tego żeby umożliwić faktycznym userom z naszej domeny
wysyłanie poczty ze swoich domowych internetów, bo bez tego sendmail z
pomocą rbl spamhausa pokazywał im fucka DSN 550 5.7.1 relaying denied
Musi być jakiś sposób, skoro serwery publiczne jakoś funkcjonują
wyłączyć sprawdzanie w dnsbl, ale po tym, co widzę w logu byłby to
strzał samobójczy, bo na jeden użyteczny link przypada mniej więcej 3, 4
albo więcej spamhaus.
Wytrułem wczoraj błąd w konfiguracji, zła ścieżka do pliku key przez co
certyfikat sendmaila nie byl używny. Do tej pory nie miało to większego
znaczenia, bo w obrębie firmy poczta działała po porcie 25 z autoryzacją
bez szyfrowania otwartym tekstem. Przez to musiałem dziś pojechać do
firmy i poustawiać userom starttls w autoryzacji serwera poczty
wychodzącej, ale nie zmieniło to nic w relayingu z adresów domowych
(dynamicznych), dalej DSN 550 na każdym porcie - 25, 465, 587
Aż się boję spróbować ponownie delay_checks gdy serwer używa starttls.
LFC
>> I działa, ale widzę, że choć w sendmail.mc dałem Family=inet dla
>> demona przy obu portach to i tak zaczęły mi włazić hosty ipv6.
> A potrzebujesz wogóle dostępu do usług po IPv6?
> Na interfejsie publicznym serwera masz włączone IPv6? Może wystarczy
> wyłączyć?
>> Zablokowałem INPUT dla ipv6,
> Jeżeli wyciąłeś ruch IPv6 na firewallu, to jaki cudem ten ruch dociera
> do serwera SMTP?
Po blokadzie ip6tables problem ustał, ale i tak jestem zdumiony, bo
> Jeżeli wyciąłeś ruch IPv6 na firewallu, to jaki cudem ten ruch dociera
> do serwera SMTP?
sendmail był ustawiony w konfigu dla Family=inet, a więc ipv4, a mimo to
z opcją delay_checks przyjmował również ipv6.
>
>> ale widzę w mquee i w logach jakieś hosty ze świata np z Ukrainy
>> przedstawiają się jako nasza domena i pakuja spam aż miło. Jak to
>> ukrócić?
>> Myślałem o opcji rela based_on_MX, ale wtedy każdy cwaniak, który
>> sobie wpisze w domenę nasz serwer jako MX bedzie mógł relayowac do woli.
>> Jakies sugestie?
>>
> Żaden cwaniak nie ma szans "relayować" przez twój serwer, o ile mu w
> konfiguracji tego nie umożliwisz!
`delay_checks', która jeżeli dobrze zrozumiałem ma opóźniać testy
sendmaila do momentu autoryzacji, po poprawnej autoryzacji usera nie
powinny być robione. Efekt był taki, że nie dośc, że pakowały się hosty
po ipv6, to jeszcze różne ruskie i ukraińskie spam serwery przedstawiały
się jako moja domena i pakowały spam rzekomo od us...@domena.com.pl i to
fikcyjnego usera na adresy ze świata.
Potrzebowałem tego żeby umożliwić faktycznym userom z naszej domeny
wysyłanie poczty ze swoich domowych internetów, bo bez tego sendmail z
pomocą rbl spamhausa pokazywał im fucka DSN 550 5.7.1 relaying denied
Musi być jakiś sposób, skoro serwery publiczne jakoś funkcjonują
>
> Żeby umożliwić weryfikację dla innych serwerów przeczytaj
> https://serverfault.com/questions/415533/how-to-stop-people-from-using-my-domain-to-send-spam
>
> i zainteresuj się tematem SPF http://www.openspf.org/ (chociaż pasywnie)
> oraz DKIM https://pl.wikipedia.org/wiki/DomainKeys_Identified_Mail
>
poczytam,, bo słabo to wygląda, a nie mogę znaleźć rozwiązania. Móglbym
> Żeby umożliwić weryfikację dla innych serwerów przeczytaj
> https://serverfault.com/questions/415533/how-to-stop-people-from-using-my-domain-to-send-spam
>
> i zainteresuj się tematem SPF http://www.openspf.org/ (chociaż pasywnie)
> oraz DKIM https://pl.wikipedia.org/wiki/DomainKeys_Identified_Mail
>
wyłączyć sprawdzanie w dnsbl, ale po tym, co widzę w logu byłby to
strzał samobójczy, bo na jeden użyteczny link przypada mniej więcej 3, 4
albo więcej spamhaus.
Wytrułem wczoraj błąd w konfiguracji, zła ścieżka do pliku key przez co
certyfikat sendmaila nie byl używny. Do tej pory nie miało to większego
znaczenia, bo w obrębie firmy poczta działała po porcie 25 z autoryzacją
bez szyfrowania otwartym tekstem. Przez to musiałem dziś pojechać do
firmy i poustawiać userom starttls w autoryzacji serwera poczty
wychodzącej, ale nie zmieniło to nic w relayingu z adresów domowych
(dynamicznych), dalej DSN 550 na każdym porcie - 25, 465, 587
Aż się boję spróbować ponownie delay_checks gdy serwer używa starttls.
LFC
LFC
Apr 3, 2020, 10:40:02 AM4/3/20
to
W dniu 2020-04-02 o 01:31, Piotr Lechowicz pisze:
>
Zapis SPF mam wprowadzony do strefy DNS, ale w róznych artykułach zdania
były podzielone. jedni doradzali inni odradzali
Zapis jest taki
@ IN TXT "v=spf1 a ip4:IP_mojego_serwera -all"
W opisie spf dla centosa znalazłem:
@ IN TXT "v=spf1 a mx ip4:IP_mojego_serwera -all"
Nie mam doświadczenia w SPF i wlazłem na stronę generatora rekordów SPF,
który uznał że zapis jest OK, ale po dodaniu informacji, o tym, że maile
sa wysyłane z tego serwera który jest w zapisie mx domeny zasugerował
ten drugi zapis.
Tyle, że mam 2 widoki w dns zewnetrzny i wewnętrzny W wewnętrznym mam
tak samo, tylko 3 zapisy ip4 - dla dwóch sieci 192.168.2.0/24,
192.168.0.0/24 i serwera 192.168.0.1.
zatem sa pytania:
- Czy zmieniać w obu widokach?
- Czy spowoduje to jakieś zmiany w sieci wewnętrznej(nie chciałbym, bo
mam dośc po starttls - na ogól poszło gładko, ale znalazło się parę
przypadków, gdzie nie odpaliło się okno zatwierdzenia wyjątku
certyfikatu samopodpisanego sendmaila, albo okazało się, że hasło, które
pamięta user nie chce jakoś być akceptowane)?
- Czy będzie to mialo znaczenie dla wysyłki poczty z domowych internetów
po porcie 587, albo 465?
W opisie twierdzą, że oprócz tego zapisu w strefie dns nie trzeba nic
więcej konfigurować. Byłoby miło.
LFC
LFC
Apr 4, 2020, 7:20:02 AM4/4/20
to
W dniu 2020-04-03 o 16:32, LFC pisze:
>>
>>> Zablokowałem INPUT dla ipv6,
>> Jeżeli wyciąłeś ruch IPv6 na firewallu, to jaki cudem ten ruch dociera
>> do serwera SMTP?
>>
W sysctl.conf od dawna mam wpisane:
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.all.disable_ipv6 = 1
Chyba, że nie zrozumiałem zasady, ale 1 oznacza enabled, czyli jak dla
mnie reguła ma być aktywna, czyli wyłączyć ipv6.
Gdyby to oznaczało jednak, że jest włączone to tłumaczyło by czemu
właziły hosty po ipv6, ale i tak mi to skrzeczy, ponieważ
skonfigurowałem w sendmail.mc demony dla Family=inet, wiec nie powinny
słuchać po ipv6.
Dopiero REJECT na INPUCIE w ip6tables zatrzymał ten proceder.
Oprócz tego pakowały się hosty po ipv4 przedstawiając się jako domena.
Wszystko to się działo z opcją (`delay_checks', `friend') w sendmail.mc
która jak zrozumiałem miała wstrzymywać test dla określonych userów
wpisanych do acces z opisem Spam:adres@email FRIEND, którzy dokonaja
autoryzacji, a puszczała do relayowania również spamerskie hosty, które
przedstawiły się jako z domeny.
Po wywaleniu tej opcji wszystko wraca do normy, jest spokój ale nie da
się wysłać poczty z domowego internetu obojętne czy z portu 25, 587 czy
465, o ile nie jest to adres statyczny bo sendmail przy pomocy dnsbl
spamhaus wysyła hosta na drzewo jeszcze przed autoryzacją.
LFC
Piotr Lechowicz
Apr 5, 2020, 5:32:06 PM4/5/20
to
W dniu 2020-04-04 o 13:02, LFC pisze:
>
> Oprócz tego pakowały się hosty po ipv4 przedstawiając się jako domena. Wszystko to się działo z opcją (`delay_checks', `friend') w sendmail.mc
> która jak zrozumiałem miała wstrzymywać test dla określonych userów wpisanych do acces z opisem Spam:adres@email FRIEND, którzy dokonaja autoryzacji, a puszczała do relayowania również spamerskie hosty, które przedstawiły się jako z domeny.
> Po wywaleniu tej opcji wszystko wraca do normy, jest spokój ale nie da się wysłać poczty z domowego internetu obojętne czy z portu 25, 587 czy 465, o ile nie jest to adres statyczny bo sendmail przy pomocy dnsbl spamhaus wysyła hosta na drzewo jeszcze przed autoryzacją.
Ustawienie nasłuchu na porcie 587 z relay wyłącznie dla klientów po uwierzytelnieniu jest proste:
Sprawdź config SASLa:
[root]# cat /etc/sasl2/Sendmail.conf
pwcheck_method:saslauthd
i ustaw w sendmail.mc
dnl # The following allows relaying if the user authenticates, and disallows plaintext authentication (PLAIN/LOGIN) on non-TLS links
define(`confAUTH_OPTIONS', `A p')dnl
dnl # w 2 poniższych mechanizmy możesz ustawić w/g uznania
TRUST_AUTH_MECH(`DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
FEATURE(`no_default_msa')dnl
DAEMON_OPTIONS(`port=587, Name=MSA, M=Ea')dnl
oraz zostaw delay_checks bez kombinacji:
FEATURE(`delay_checks')dnl
a w access wyłącz wszystkie zbędne wpisy dotyczące relay poza:
To:twoja.domena.pl RELAY
oraz powyłączaj do testów wszystkie wpisy Spam:...
W takiej konfiguracji delay_checks przesuwa kontrolę dnsbl do momentu rcpt, a poprawne uwierzytelnienie klienta wyłącza ją wogóle.
Powyższe ustawienia zakładają, że masz już w sendmailu uruchomione szyfrowanie i ehlo na porcie 587 pokazuje 250-STARTTLS.
W kliencie ustawiasz port:587/szyfrowanie:StartTLS/uwierzytelnianie:włączone (w Mozilla Thunderbird: "normalne hasło").
>
> LFC
>
> W dniu 2020-04-03 o 16:32, LFC pisze:
>
>>>
>>>> Zablokowałem INPUT dla ipv6,
>>> Jeżeli wyciąłeś ruch IPv6 na firewallu, to jaki cudem ten ruch dociera do serwera SMTP?
>>>
> Nie zrozumieliśmy się.
> W sysctl.conf od dawna mam wpisane:
>
> net.ipv6.conf.default.disable_ipv6 = 1
> net.ipv6.conf.all.disable_ipv6 = 1
>
> Chyba, że nie zrozumiałem zasady, ale 1 oznacza enabled, czyli jak dla mnie reguła ma być aktywna, czyli wyłączyć ipv6.
Tak jest OK i taka konfiguracja wyłącza IPv6.
> W dniu 2020-04-03 o 16:32, LFC pisze:
>
>>>
>>>> Zablokowałem INPUT dla ipv6,
>>> Jeżeli wyciąłeś ruch IPv6 na firewallu, to jaki cudem ten ruch dociera do serwera SMTP?
>>>
> Nie zrozumieliśmy się.
> W sysctl.conf od dawna mam wpisane:
>
> net.ipv6.conf.default.disable_ipv6 = 1
> net.ipv6.conf.all.disable_ipv6 = 1
>
> Chyba, że nie zrozumiałem zasady, ale 1 oznacza enabled, czyli jak dla mnie reguła ma być aktywna, czyli wyłączyć ipv6.
>
> Gdyby to oznaczało jednak, że jest włączone to tłumaczyło by czemu właziły hosty po ipv6, ale i tak mi to skrzeczy, ponieważ skonfigurowałem w sendmail.mc demony dla Family=inet, wiec nie powinny
> słuchać po ipv6.
> Dopiero REJECT na INPUCIE w ip6tables zatrzymał ten proceder.
Jak chcesz wiarygodnej analizy to pokaż logi.
> Gdyby to oznaczało jednak, że jest włączone to tłumaczyło by czemu właziły hosty po ipv6, ale i tak mi to skrzeczy, ponieważ skonfigurowałem w sendmail.mc demony dla Family=inet, wiec nie powinny
> słuchać po ipv6.
> Dopiero REJECT na INPUCIE w ip6tables zatrzymał ten proceder.
>
> Oprócz tego pakowały się hosty po ipv4 przedstawiając się jako domena. Wszystko to się działo z opcją (`delay_checks', `friend') w sendmail.mc
> która jak zrozumiałem miała wstrzymywać test dla określonych userów wpisanych do acces z opisem Spam:adres@email FRIEND, którzy dokonaja autoryzacji, a puszczała do relayowania również spamerskie hosty, które przedstawiły się jako z domeny.
> Po wywaleniu tej opcji wszystko wraca do normy, jest spokój ale nie da się wysłać poczty z domowego internetu obojętne czy z portu 25, 587 czy 465, o ile nie jest to adres statyczny bo sendmail przy pomocy dnsbl spamhaus wysyła hosta na drzewo jeszcze przed autoryzacją.
Sprawdź config SASLa:
[root]# cat /etc/sasl2/Sendmail.conf
pwcheck_method:saslauthd
i ustaw w sendmail.mc
dnl # The following allows relaying if the user authenticates, and disallows plaintext authentication (PLAIN/LOGIN) on non-TLS links
define(`confAUTH_OPTIONS', `A p')dnl
dnl # w 2 poniższych mechanizmy możesz ustawić w/g uznania
TRUST_AUTH_MECH(`DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
FEATURE(`no_default_msa')dnl
DAEMON_OPTIONS(`port=587, Name=MSA, M=Ea')dnl
oraz zostaw delay_checks bez kombinacji:
FEATURE(`delay_checks')dnl
a w access wyłącz wszystkie zbędne wpisy dotyczące relay poza:
To:twoja.domena.pl RELAY
oraz powyłączaj do testów wszystkie wpisy Spam:...
W takiej konfiguracji delay_checks przesuwa kontrolę dnsbl do momentu rcpt, a poprawne uwierzytelnienie klienta wyłącza ją wogóle.
Powyższe ustawienia zakładają, że masz już w sendmailu uruchomione szyfrowanie i ehlo na porcie 587 pokazuje 250-STARTTLS.
W kliencie ustawiasz port:587/szyfrowanie:StartTLS/uwierzytelnianie:włączone (w Mozilla Thunderbird: "normalne hasło").
>
> LFC
LFC
Apr 7, 2020, 3:20:02 PM4/7/20
to
W dniu 2020-04-05 o 23:31, Piotr Lechowicz pisze:
> Sprawdź config SASLa:
>
> [root]# cat /etc/sasl2/Sendmail.conf
> pwcheck_method:saslauthd
>
> i ustaw w sendmail.mc
>
> dnl # The following allows relaying if the user authenticates, and
> disallows plaintext authentication (PLAIN/LOGIN) on non-TLS links
> define(`confAUTH_OPTIONS', `A p')dnl
> dnl # w 2 poniższych mechanizmy możesz ustawić w/g uznania
> TRUST_AUTH_MECH(`DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
> define(`confAUTH_MECHANISMS', `DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
>
> FEATURE(`no_default_msa')dnl
> DAEMON_OPTIONS(`port=587, Name=MSA, M=Ea')dnl
>
> oraz zostaw delay_checks bez kombinacji:
>
> FEATURE(`delay_checks')dnl
>
> a w access wyłącz wszystkie zbędne wpisy dotyczące relay poza:
>
> To:twoja.domena.pl RELAY
>
> oraz powyłączaj do testów wszystkie wpisy Spam:...
>
> W takiej konfiguracji delay_checks przesuwa kontrolę dnsbl do momentu
> rcpt, a poprawne uwierzytelnienie klienta wyłącza ją wogóle.
> Powyższe ustawienia zakładają, że masz już w sendmailu uruchomione
> szyfrowanie i ehlo na porcie 587 pokazuje 250-STARTTLS.
> W kliencie ustawiasz
> port:587/szyfrowanie:StartTLS/uwierzytelnianie:włączone (w Mozilla
> Thunderbird: "normalne hasło").
>
Wszystko jest tak, jak piszesz, z wyjatkiem (obecnie) opcji delay_checks
i w acces - To:twoja.domena.pl RELAY
Najpierw włączyłem opcję delay_checks bez opcji i po mniej wiecej jednym
dniu miałem sajgon.
Dodałem wtedy w opcji `friend' i w acces dopisałem adresy, ktore miały
być delayowane, jako friend - efekt ten sam.
Gwoli sprawiedliwości musze dodać, że błąd w scieżce do pliku klucza
certyfikatu znalazłem po tym, ale nie spróbowałem ponownie, bo siedzę w
domu na zdalnym, a zmiany w konfiguracji poczty wywołują u userów znany
odruch - "poczta mi nie działa!" i zaraz są afery typu Muszę pilnie
wyslać pocztę, a nie mogę, etc.
Zrobiłem nawet takie howto z obrazkami, jak sobie z tym poradzić w
thunderbirdzie, ale i tak większość je olała / nie zrozumiała i
zawracała mi dupę.
Nie bardzo rozumiem proponowany wpis do access
Jeżeli dobrze rozumiem to oznacza, że sendmail umożliwi każdemu wysłanie
maila na adres z domeny. Nie jest to proszenie się o spam i nie lepiej
dać tam OK?
LFC
> Sprawdź config SASLa:
>
> [root]# cat /etc/sasl2/Sendmail.conf
> pwcheck_method:saslauthd
>
> i ustaw w sendmail.mc
>
> dnl # The following allows relaying if the user authenticates, and
> disallows plaintext authentication (PLAIN/LOGIN) on non-TLS links
> define(`confAUTH_OPTIONS', `A p')dnl
> dnl # w 2 poniższych mechanizmy możesz ustawić w/g uznania
> TRUST_AUTH_MECH(`DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
> define(`confAUTH_MECHANISMS', `DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
>
> FEATURE(`no_default_msa')dnl
> DAEMON_OPTIONS(`port=587, Name=MSA, M=Ea')dnl
>
> oraz zostaw delay_checks bez kombinacji:
>
> FEATURE(`delay_checks')dnl
>
> a w access wyłącz wszystkie zbędne wpisy dotyczące relay poza:
>
> To:twoja.domena.pl RELAY
>
> oraz powyłączaj do testów wszystkie wpisy Spam:...
>
> W takiej konfiguracji delay_checks przesuwa kontrolę dnsbl do momentu
> rcpt, a poprawne uwierzytelnienie klienta wyłącza ją wogóle.
> Powyższe ustawienia zakładają, że masz już w sendmailu uruchomione
> szyfrowanie i ehlo na porcie 587 pokazuje 250-STARTTLS.
> W kliencie ustawiasz
> port:587/szyfrowanie:StartTLS/uwierzytelnianie:włączone (w Mozilla
> Thunderbird: "normalne hasło").
>
i w acces - To:twoja.domena.pl RELAY
Najpierw włączyłem opcję delay_checks bez opcji i po mniej wiecej jednym
dniu miałem sajgon.
Dodałem wtedy w opcji `friend' i w acces dopisałem adresy, ktore miały
być delayowane, jako friend - efekt ten sam.
Gwoli sprawiedliwości musze dodać, że błąd w scieżce do pliku klucza
certyfikatu znalazłem po tym, ale nie spróbowałem ponownie, bo siedzę w
domu na zdalnym, a zmiany w konfiguracji poczty wywołują u userów znany
odruch - "poczta mi nie działa!" i zaraz są afery typu Muszę pilnie
wyslać pocztę, a nie mogę, etc.
Zrobiłem nawet takie howto z obrazkami, jak sobie z tym poradzić w
thunderbirdzie, ale i tak większość je olała / nie zrozumiała i
zawracała mi dupę.
Nie bardzo rozumiem proponowany wpis do access
Jeżeli dobrze rozumiem to oznacza, że sendmail umożliwi każdemu wysłanie
maila na adres z domeny. Nie jest to proszenie się o spam i nie lepiej
dać tam OK?
LFC
0 new messages