info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
timeouty sendmaila
6 views
Skip to first unread message
LFC
Jun 2, 2020, 8:40:03 AM6/2/20
to
Za radą któregoś z howto's w pliku sendmail.ms ustawiłęm niektóre
podstawowe timeouty:
define(`confTO_ICONNECT', `20s')dnl
define(`confTO_CONNECT', `3m')dnl
define(`confTO_HELO', `2m')dnl
define(`confTO_MAIL', `1m')dnl
define(`confTO_RCPT', `1m')dnl
define(`confTO_DATAINIT', `1m')dnl
define(`confTO_DATABLOCK', `1m')dnl
define(`confTO_DATAFINAL', `1m')dnl
define(`confTO_RSET', `1m')dnl
define(`confTO_QUIT', `1m')dnl
define(`confTO_MISC', `1m')dnl
define(`confTO_COMMAND', `1m')dnl
define(`confTO_STARTTLS', `2m')dnl
W zasadzie serwer działa, ale od kilku dni jest problem z wysyłaniem
poczty do serwera poczty blue.pekao.com.pl.
W maillogu wygląda to tak:
STARTTLS=client, relay=blue.pekao.com.pl., version=TLSv1/SSLv3,
verify=OK, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256/256
Jun 2 14:08:13 mpwik sendmail[6599]: 0519KE6A014371:
to=<nasza...@pekao.com.pl>, delay=1+02:47:58, xdelay=00:01:01,
mailer=esmtp, pri=3771349, relay=blue.pekao.com.pl. [193.111.166.171],
dsn=4.0.0, stat=Deferred: Connection timed out with blue.pekao.com.pl.
Natomiast w fragmencie logu zadania w kolejce
V8
T1591003215
K1591099693
N33
P3771349
I8/1/8389820
B8BITMIME
Mreply: read error from blue.pekao.com.pl.
Fw8bs
$_[192.168.0.201]
$rESMTP
$s[192.168.0.201]
${daemon_flags}
${if_addr}192.168.0.1
S<nasza.k...@domena.com.pl>
MDeferred: Connection timed out with blue.pekao.com.pl.
rRFC822; nasz...@pekao.com.pl
RPFD:<nasza...@pekao.com.pl>
Na pomoc, czy współpracę adminów serwera PKO raczej nie da się liczyć,
więc próbuję dojść sam, co jest grane, ze do niedawna było dobrze, a od
3-4 dni jest kicha i nie wiadomo dlaczego.
Nasz serwer zasuwa bez żadnych zmian od około miesiąca, gdy wprowadziłem
milter greylista więc problem musi raczej tkwić po tamtej stronie, ale
nie wiadomo czego dotyczy.
Milter greylista nie powinien byc przeszkodą, bo od nich poczta dochodzi
bez problemu, a do wychodzącej od nas greylist nie stosuje delaya.
Przyszło mi na myśl, czy któryś z timeoutów nie jest za krótki, albo
certyfikat TLS (samopodpisany) mu się nagle przestał podobać, ale nie
chcę grzebac w konfiguracji bez potrzeby.
Jakies sugestie, podpowiedź?
LFC
podstawowe timeouty:
define(`confTO_ICONNECT', `20s')dnl
define(`confTO_CONNECT', `3m')dnl
define(`confTO_HELO', `2m')dnl
define(`confTO_MAIL', `1m')dnl
define(`confTO_RCPT', `1m')dnl
define(`confTO_DATAINIT', `1m')dnl
define(`confTO_DATABLOCK', `1m')dnl
define(`confTO_DATAFINAL', `1m')dnl
define(`confTO_RSET', `1m')dnl
define(`confTO_QUIT', `1m')dnl
define(`confTO_MISC', `1m')dnl
define(`confTO_COMMAND', `1m')dnl
define(`confTO_STARTTLS', `2m')dnl
W zasadzie serwer działa, ale od kilku dni jest problem z wysyłaniem
poczty do serwera poczty blue.pekao.com.pl.
W maillogu wygląda to tak:
STARTTLS=client, relay=blue.pekao.com.pl., version=TLSv1/SSLv3,
verify=OK, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256/256
Jun 2 14:08:13 mpwik sendmail[6599]: 0519KE6A014371:
to=<nasza...@pekao.com.pl>, delay=1+02:47:58, xdelay=00:01:01,
mailer=esmtp, pri=3771349, relay=blue.pekao.com.pl. [193.111.166.171],
dsn=4.0.0, stat=Deferred: Connection timed out with blue.pekao.com.pl.
Natomiast w fragmencie logu zadania w kolejce
V8
T1591003215
K1591099693
N33
P3771349
I8/1/8389820
B8BITMIME
Mreply: read error from blue.pekao.com.pl.
Fw8bs
$_[192.168.0.201]
$rESMTP
$s[192.168.0.201]
${daemon_flags}
${if_addr}192.168.0.1
S<nasza.k...@domena.com.pl>
MDeferred: Connection timed out with blue.pekao.com.pl.
rRFC822; nasz...@pekao.com.pl
RPFD:<nasza...@pekao.com.pl>
Na pomoc, czy współpracę adminów serwera PKO raczej nie da się liczyć,
więc próbuję dojść sam, co jest grane, ze do niedawna było dobrze, a od
3-4 dni jest kicha i nie wiadomo dlaczego.
Nasz serwer zasuwa bez żadnych zmian od około miesiąca, gdy wprowadziłem
milter greylista więc problem musi raczej tkwić po tamtej stronie, ale
nie wiadomo czego dotyczy.
Milter greylista nie powinien byc przeszkodą, bo od nich poczta dochodzi
bez problemu, a do wychodzącej od nas greylist nie stosuje delaya.
Przyszło mi na myśl, czy któryś z timeoutów nie jest za krótki, albo
certyfikat TLS (samopodpisany) mu się nagle przestał podobać, ale nie
chcę grzebac w konfiguracji bez potrzeby.
Jakies sugestie, podpowiedź?
LFC
Lemat
Jun 2, 2020, 9:41:08 AM6/2/20
to
W dniu 02.06.2020 o 14:32, LFC pisze:
Te timeouty to mi wygladąją na timeouty serwera
a problem dotyczy timeoutów klienta.
zrób telnet na port 25
i/lub
openssl s_client -connect 193.111.166.171:25 -starttls smtp
i zobacz sam czy/kiedy cię rozłaczy
--
Pozdrawiam
Lemat
a problem dotyczy timeoutów klienta.
zrób telnet na port 25
i/lub
openssl s_client -connect 193.111.166.171:25 -starttls smtp
i zobacz sam czy/kiedy cię rozłaczy
--
Pozdrawiam
Lemat
Andrzej A. Filip
Jun 2, 2020, 9:54:17 AM6/2/20
to
LFC <l...@onet.eu> pisze:
[…]
> Jakies sugestie, podpowiedź?
Popchnij maile w kolejce w trybie verbose (transkrypt sesji SMTP) =>
zobaczysz w którym miejscu przekazanie maila wysiada i będzie znacznie
prościej radzić/zgadywać.
Jako root wykonaj:
# popchnięcie wszystkich maili do pekao.com.pl w kolejce
sendmail -v -qRpekao.com.pl
# popchnięcie jednego maila z konkretnym queue-id w kolejce
sendmail -v -qI0519KE6A014371
P.S.
Ja niestety z "sendmail-owego poradnictwa" mam brzydki nawyk reagowania
po słowach kluczowych. Z tego powodu przeważnie+ proszenia o
"dokładniejszą diagnostykę wstępną" bo "dziwnych i niezwykłych"
problemów poznałem za dużo (na szczęście u innych).
--
Andrzej A. Filip
[…]
> W zasadzie serwer działa, ale od kilku dni jest problem z wysyłaniem
> poczty do serwera poczty blue.pekao.com.pl.
>
> W maillogu wygląda to tak:
>
> STARTTLS=client, relay=blue.pekao.com.pl., version=TLSv1/SSLv3,
> verify=OK, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256/256
> Jun 2 14:08:13 mpwik sendmail[6599]: 0519KE6A014371:
> to=<nasza...@pekao.com.pl>, delay=1+02:47:58, xdelay=00:01:01,
> mailer=esmtp, pri=3771349, relay=blue.pekao.com.pl. [193.111.166.171],
> dsn=4.0.0, stat=Deferred: Connection timed out with blue.pekao.com.pl.
[…]
> poczty do serwera poczty blue.pekao.com.pl.
>
> W maillogu wygląda to tak:
>
> STARTTLS=client, relay=blue.pekao.com.pl., version=TLSv1/SSLv3,
> verify=OK, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256/256
> Jun 2 14:08:13 mpwik sendmail[6599]: 0519KE6A014371:
> to=<nasza...@pekao.com.pl>, delay=1+02:47:58, xdelay=00:01:01,
> mailer=esmtp, pri=3771349, relay=blue.pekao.com.pl. [193.111.166.171],
> dsn=4.0.0, stat=Deferred: Connection timed out with blue.pekao.com.pl.
> Jakies sugestie, podpowiedź?
Popchnij maile w kolejce w trybie verbose (transkrypt sesji SMTP) =>
zobaczysz w którym miejscu przekazanie maila wysiada i będzie znacznie
prościej radzić/zgadywać.
Jako root wykonaj:
# popchnięcie wszystkich maili do pekao.com.pl w kolejce
sendmail -v -qRpekao.com.pl
# popchnięcie jednego maila z konkretnym queue-id w kolejce
sendmail -v -qI0519KE6A014371
P.S.
Ja niestety z "sendmail-owego poradnictwa" mam brzydki nawyk reagowania
po słowach kluczowych. Z tego powodu przeważnie+ proszenia o
"dokładniejszą diagnostykę wstępną" bo "dziwnych i niezwykłych"
problemów poznałem za dużo (na szczęście u innych).
--
Andrzej A. Filip
LFC
Jun 2, 2020, 3:00:02 PM6/2/20
to
W dniu 2020-06-02 o 15:53, Andrzej A. Filip pisze:
>
> Jako root wykonaj:
> # popchnięcie wszystkich maili do pekao.com.pl w kolejce
> sendmail -v -qRpekao.com.pl
> # popchnięcie jednego maila z konkretnym queue-id w kolejce
> sendmail -v -qI0519KE6A014371
>
> P.S.
> Ja niestety z "sendmail-owego poradnictwa" mam brzydki nawyk reagowania
> po słowach kluczowych. Z tego powodu przeważnie+ proszenia o
> "dokładniejszą diagnostykę wstępną" bo "dziwnych i niezwykłych"
> problemów poznałem za dużo (na szczęście u innych).
>
Jutro w pracy sprawdzę. Z diagnostyką na ogół w takich sytuacjach jest
kicha, bo jak coś działa bardzo długo bez żadnej awarii i nagle okaże
się, że jest kicha, to człowiek w pierwszym momencie ma kłopot z
ogarnięciem się i zakumaniem, gdzie sięgnąć i co sprawdzić. Czasem wręcz
nie pamięta już, co, gdzie sprawdzić i jak. Szczególnie, jak jest to
jedna z wielu spraw do ogarnięcia w tym samym czasie.
LFC
>
> Jako root wykonaj:
> # popchnięcie wszystkich maili do pekao.com.pl w kolejce
> sendmail -v -qRpekao.com.pl
> # popchnięcie jednego maila z konkretnym queue-id w kolejce
> sendmail -v -qI0519KE6A014371
>
> P.S.
> Ja niestety z "sendmail-owego poradnictwa" mam brzydki nawyk reagowania
> po słowach kluczowych. Z tego powodu przeważnie+ proszenia o
> "dokładniejszą diagnostykę wstępną" bo "dziwnych i niezwykłych"
> problemów poznałem za dużo (na szczęście u innych).
>
kicha, bo jak coś działa bardzo długo bez żadnej awarii i nagle okaże
się, że jest kicha, to człowiek w pierwszym momencie ma kłopot z
ogarnięciem się i zakumaniem, gdzie sięgnąć i co sprawdzić. Czasem wręcz
nie pamięta już, co, gdzie sprawdzić i jak. Szczególnie, jak jest to
jedna z wielu spraw do ogarnięcia w tym samym czasie.
LFC
LFC
Jun 2, 2020, 3:00:03 PM6/2/20
to
W dniu 2020-06-02 o 15:40, Lemat pisze:
po EHLO daje STARTTLS i czeka na dalsze komendy
CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert
High Assu rance EV Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert
SHA2 Exte nded Validation Server CA
verify return:1
depth=0 businessCategory = Private Organization,
1.3.6.1.4.1.311.60.2.1.3 = PL,
serialNumber = 0000014843, C = PL, ST = Mazowieckie, L = Warszawa, O =
Bank Pols ka Kasa Opieki S.A., OU =
Departament Bezpiecze\C5\84stwa Banku, CN = black.peka
o.com.pl
verify return:1
---
Certificate chain
0 s:/businessCategory=Private
Organization/1.3.6.1.4.1.311.60.2.1.3=PL/serialNu
mber=0000014843/C=PL/ST=Mazowieckie/L=Warszawa/O=Bank Polska
Kasa Opieki S.A./OU =Departament
Bezpiecze\xC5\x84stwa Banku/CN=black.pekao.com.pl
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended
Validati on Server CA
1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended
Validati on Server CA
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High
Assurance EV Root
CA
2 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High
Assurance EV Root CA
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High
Assurance EV Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIG+TCCBeGgAwIBAgIQBYYic0A6D9HWlWALMbt31zANBgkqhkiG9w0BAQsFADB1
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMTQwMgYDVQQDEytEaWdpQ2VydCBTSEEyIEV4dGVuZGVk
IFZhbGlkYXRpb24gU2VydmVyIENBMB4XDTIwMDUxOTAwMDAwMFoXDTIxMDUyNTEy
MDAwMFowge8xHTAbBgNVBA8MFFByaXZhdGUgT3JnYW5pemF0aW9uMRMwEQYLKwYB
BAGCNzwCAQMTAlBMMRMwEQYDVQQFEwowMDAwMDE0ODQzMQswCQYDVQQGEwJQTDEU
MBIGA1UECBMLTWF6b3dpZWNraWUxETAPBgNVBAcTCFdhcnN6YXdhMSUwIwYDVQQK
ExxCYW5rIFBvbHNrYSBLYXNhIE9waWVraSBTLkEuMSowKAYDVQQLDCFEZXBhcnRh
bWVudCBCZXpwaWVjemXFhHN0d2EgQmFua3UxGzAZBgNVBAMTEmJsYWNrLnBla2Fv
LmNvbS5wbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALYZbDbaTQP5
7oj3ZQzxZkQ1dAZkY8lRNqRxxvupNT/xT8DIV4PncbUF0OKMLJoUI+hFB1Y3MIx5
upgWxC85tCLXumM/Q/mf50XECiWoP1jtxJWFtmtB3rKO409V5cggK7y3OTA7rja+
MZDVEoN0UaK6sNxPuYlCIn4oaDlIxU1qjoT2gyAUeOLyTgB0TiDi5g04o7o5kDum
85LoN/DY0hnF+Ip10uyQriKD5n0jpPg6kzLTY5+AJvVCsBcFn8p4IwhckUMuUSUL
DEh93trgoG1c/IrTZwu2S3b7L4wtzsVOyOtYYvjditk2yEzauEesWu1NceO3eSfy
zCT3RcsHaT0CAwEAAaOCAwgwggMEMB8GA1UdIwQYMBaAFD3TUKXWoK3u80pgCmXT
IdT4+NYPMB0GA1UdDgQWBBRFP40q3+TFmxKbfDZYRYisHFWjPzAwBgNVHREEKTAn
ghJibGFjay5wZWthby5jb20ucGyCEWJsdWUucGVrYW8uY29tLnBsMA4GA1UdDwEB
/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwdQYDVR0fBG4w
bDA0oDKgMIYuaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL3NoYTItZXYtc2VydmVy
LWcyLmNybDA0oDKgMIYuaHR0cDovL2NybDQuZGlnaWNlcnQuY29tL3NoYTItZXYt
c2VydmVyLWcyLmNybDBLBgNVHSAERDBCMDcGCWCGSAGG/WwCATAqMCgGCCsGAQUF
BwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMAcGBWeBDAEBMIGIBggr
BgEFBQcBAQR8MHowJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNv
bTBSBggrBgEFBQcwAoZGaHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lD
ZXJ0U0hBMkV4dGVuZGVkVmFsaWRhdGlvblNlcnZlckNBLmNydDAJBgNVHRMEAjAA
MIIBBQYKKwYBBAHWeQIEAgSB9gSB8wDxAHcA9lyUL9F3MCIUVBgIMJRWjuNNExkz
v98MLyALzE7xZOMAAAFyLA01uwAABAMASDBGAiEAj3K70Hvpx+tz2GNNCFMnle2H
ZXNp6A1cCpn7s7Tp7LECIQCBCWtH2xadR9ZQROyM1Qd9aIau/5NeAGkGuDY7oz36
RgB2AFzcQ5L+5qtFRLFemtRW5hA3+9X6R9yhc5SyXub2xw7KAAABciwNNdoAAAQD
AEcwRQIhAIb/pV2pDypC9+LiZZ8c+Wt3jBSYWYADWSXr/E1N0V1zAiA1NZgQDhC+
G3wib5kgDq3eifMMhx9OtASLM/5DaUFADDANBgkqhkiG9w0BAQsFAAOCAQEAGQtB
dj/JWCW//3ySVxiGhX0A1VCSnI75xjyXoHghUUb+vCwwjGJcKdTV4OfhAQ4vyeam
wi35Q+uE1DA+Q1r17ZCMuQ9EjXJGv0xPQdqiqHnaKDQbIIx+K0iTvRBQOXVU7NS8
J5W19sdHCHETv4nP0JwD2weoGMmUz9ldKGkivQ2v+YYkVjJZUJvNJEAkqesfBvLy
esq7uHYsR6Lyq/f9KiSz6lrUcrijA6Vif6qZwd040+CRkfuar1j2GylCfqmuAUgc
LI5aFWkXp+PyMYDQrDlIjE620pmQPOiKW+860o2coDhdGOBtZHzgwF+qrwzKk3jx
HXT1hQgptZY5S8M4zQ==
-----END CERTIFICATE-----
subject=/businessCategory=Private
Organization/1.3.6.1.4.1.311.60.2.1.3=PL/seria
lNumber=0000014843/C=PL/ST=Mazowieckie/L=Warszawa/O=Bank Polska
Kasa Opieki S.A. /OU=Departament
Bezpiecze\xC5\x84stwa Banku/CN=black.pekao.com.pl
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2
Extended Valida tion Server CA
---
No client certificate CA names sent
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 4751 bytes and written 408 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID:
0908CE15C4FD548D54C2DADE9BDDFD779DE328C7FDF9790CA13179D836BC5CA5
Session-ID-ctx:
Master-Key:
429BCEBD192980BE928842B9F18DDA4ED408EAA71A03F8FDA550564EA2E5A59D
A7555CED63A3CEBA58C1703FAB92E640
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - e3 5a 32 0c 38 72 e1 ad-d6 0c dc 31 e1 9f 33 0b
.Z2.8r.....1..3.
0010 - b3 77 d6 a2 37 0a 98 88-b6 6a 11 a1 b0 a3 09 2c
.w..7....j.....,
0020 - 09 66 f3 08 fb 82 31 78-ce 6f 15 a0 1d ca f2 85
.f....1x.o......
0030 - 8e 44 b3 61 09 4f 87 f0-30 7c b4 d3 8a e6 be 39
.D.a.O..0|.....9
0040 - 47 ec 5e f8 36 bc ea 5e-7f 60 c9 13 ca a2 64 c6
G.^.6..^.`....d.
0050 - 3c ad 5f 5c fd ef 93 9b-0f 11 d2 e2 7d ba 21 e1
<._\........}.!.
0060 - e5 59 3c e8 90 bb cc e9-00 73 c7 8c 1d cc 8f b1
.Y<......s......
0070 - 2a b2 4b 08 08 2c 28 91-f1 b9 25 6b 9a a5 17 80
*.K..,(...%k....
0080 - a2 e5 47 8d 55 37 bd a0-83 c6 1e f9 ca 09 12 de
..G.U7..........
0090 - d4 7c e5 43 3c de df 48-5d e6 7d 82 58 52 c7 10
.|.C<..H].}.XR..
Start Time: 1591122561
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
To dały oba podejścia.
Serwer PKO łączy się po ipv6. Specjalnie enablowałem z tego powodu ipv6
z polityką DROP i dla nich dałem ACCEPT w ip6tables.
Wcześniej nie było żadnych problemów przez długi czas. Jak kilka dni
temu zorientowaliśmy się, że ważne poczty nie doszły i siedziały w queue
to przyjrzałęm się połączeniom i zobaczyłem, że łączy się po ipv6, więc
enablowałem ipv6 i zrobiłem dla niego furtke, ale nic to nie dało. po
jakichś 2 dniach nagle część poczt poszła, ale na drugi dzień znowu
kicha - to samo.
Z wysyłką do innych odbiorców póki, co nie ma problemów
LFC
CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert
High Assu rance EV Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert
SHA2 Exte nded Validation Server CA
verify return:1
depth=0 businessCategory = Private Organization,
1.3.6.1.4.1.311.60.2.1.3 = PL,
serialNumber = 0000014843, C = PL, ST = Mazowieckie, L = Warszawa, O =
Bank Pols ka Kasa Opieki S.A., OU =
Departament Bezpiecze\C5\84stwa Banku, CN = black.peka
o.com.pl
verify return:1
---
Certificate chain
0 s:/businessCategory=Private
Organization/1.3.6.1.4.1.311.60.2.1.3=PL/serialNu
mber=0000014843/C=PL/ST=Mazowieckie/L=Warszawa/O=Bank Polska
Kasa Opieki S.A./OU =Departament
Bezpiecze\xC5\x84stwa Banku/CN=black.pekao.com.pl
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended
Validati on Server CA
1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended
Validati on Server CA
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High
Assurance EV Root
CA
2 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High
Assurance EV Root CA
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High
Assurance EV Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIG+TCCBeGgAwIBAgIQBYYic0A6D9HWlWALMbt31zANBgkqhkiG9w0BAQsFADB1
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMTQwMgYDVQQDEytEaWdpQ2VydCBTSEEyIEV4dGVuZGVk
IFZhbGlkYXRpb24gU2VydmVyIENBMB4XDTIwMDUxOTAwMDAwMFoXDTIxMDUyNTEy
MDAwMFowge8xHTAbBgNVBA8MFFByaXZhdGUgT3JnYW5pemF0aW9uMRMwEQYLKwYB
BAGCNzwCAQMTAlBMMRMwEQYDVQQFEwowMDAwMDE0ODQzMQswCQYDVQQGEwJQTDEU
MBIGA1UECBMLTWF6b3dpZWNraWUxETAPBgNVBAcTCFdhcnN6YXdhMSUwIwYDVQQK
ExxCYW5rIFBvbHNrYSBLYXNhIE9waWVraSBTLkEuMSowKAYDVQQLDCFEZXBhcnRh
bWVudCBCZXpwaWVjemXFhHN0d2EgQmFua3UxGzAZBgNVBAMTEmJsYWNrLnBla2Fv
LmNvbS5wbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALYZbDbaTQP5
7oj3ZQzxZkQ1dAZkY8lRNqRxxvupNT/xT8DIV4PncbUF0OKMLJoUI+hFB1Y3MIx5
upgWxC85tCLXumM/Q/mf50XECiWoP1jtxJWFtmtB3rKO409V5cggK7y3OTA7rja+
MZDVEoN0UaK6sNxPuYlCIn4oaDlIxU1qjoT2gyAUeOLyTgB0TiDi5g04o7o5kDum
85LoN/DY0hnF+Ip10uyQriKD5n0jpPg6kzLTY5+AJvVCsBcFn8p4IwhckUMuUSUL
DEh93trgoG1c/IrTZwu2S3b7L4wtzsVOyOtYYvjditk2yEzauEesWu1NceO3eSfy
zCT3RcsHaT0CAwEAAaOCAwgwggMEMB8GA1UdIwQYMBaAFD3TUKXWoK3u80pgCmXT
IdT4+NYPMB0GA1UdDgQWBBRFP40q3+TFmxKbfDZYRYisHFWjPzAwBgNVHREEKTAn
ghJibGFjay5wZWthby5jb20ucGyCEWJsdWUucGVrYW8uY29tLnBsMA4GA1UdDwEB
/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwdQYDVR0fBG4w
bDA0oDKgMIYuaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL3NoYTItZXYtc2VydmVy
LWcyLmNybDA0oDKgMIYuaHR0cDovL2NybDQuZGlnaWNlcnQuY29tL3NoYTItZXYt
c2VydmVyLWcyLmNybDBLBgNVHSAERDBCMDcGCWCGSAGG/WwCATAqMCgGCCsGAQUF
BwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMAcGBWeBDAEBMIGIBggr
BgEFBQcBAQR8MHowJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNv
bTBSBggrBgEFBQcwAoZGaHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lD
ZXJ0U0hBMkV4dGVuZGVkVmFsaWRhdGlvblNlcnZlckNBLmNydDAJBgNVHRMEAjAA
MIIBBQYKKwYBBAHWeQIEAgSB9gSB8wDxAHcA9lyUL9F3MCIUVBgIMJRWjuNNExkz
v98MLyALzE7xZOMAAAFyLA01uwAABAMASDBGAiEAj3K70Hvpx+tz2GNNCFMnle2H
ZXNp6A1cCpn7s7Tp7LECIQCBCWtH2xadR9ZQROyM1Qd9aIau/5NeAGkGuDY7oz36
RgB2AFzcQ5L+5qtFRLFemtRW5hA3+9X6R9yhc5SyXub2xw7KAAABciwNNdoAAAQD
AEcwRQIhAIb/pV2pDypC9+LiZZ8c+Wt3jBSYWYADWSXr/E1N0V1zAiA1NZgQDhC+
G3wib5kgDq3eifMMhx9OtASLM/5DaUFADDANBgkqhkiG9w0BAQsFAAOCAQEAGQtB
dj/JWCW//3ySVxiGhX0A1VCSnI75xjyXoHghUUb+vCwwjGJcKdTV4OfhAQ4vyeam
wi35Q+uE1DA+Q1r17ZCMuQ9EjXJGv0xPQdqiqHnaKDQbIIx+K0iTvRBQOXVU7NS8
J5W19sdHCHETv4nP0JwD2weoGMmUz9ldKGkivQ2v+YYkVjJZUJvNJEAkqesfBvLy
esq7uHYsR6Lyq/f9KiSz6lrUcrijA6Vif6qZwd040+CRkfuar1j2GylCfqmuAUgc
LI5aFWkXp+PyMYDQrDlIjE620pmQPOiKW+860o2coDhdGOBtZHzgwF+qrwzKk3jx
HXT1hQgptZY5S8M4zQ==
-----END CERTIFICATE-----
subject=/businessCategory=Private
Organization/1.3.6.1.4.1.311.60.2.1.3=PL/seria
lNumber=0000014843/C=PL/ST=Mazowieckie/L=Warszawa/O=Bank Polska
Kasa Opieki S.A. /OU=Departament
Bezpiecze\xC5\x84stwa Banku/CN=black.pekao.com.pl
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2
Extended Valida tion Server CA
---
No client certificate CA names sent
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 4751 bytes and written 408 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID:
0908CE15C4FD548D54C2DADE9BDDFD779DE328C7FDF9790CA13179D836BC5CA5
Session-ID-ctx:
Master-Key:
429BCEBD192980BE928842B9F18DDA4ED408EAA71A03F8FDA550564EA2E5A59D
A7555CED63A3CEBA58C1703FAB92E640
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - e3 5a 32 0c 38 72 e1 ad-d6 0c dc 31 e1 9f 33 0b
.Z2.8r.....1..3.
0010 - b3 77 d6 a2 37 0a 98 88-b6 6a 11 a1 b0 a3 09 2c
.w..7....j.....,
0020 - 09 66 f3 08 fb 82 31 78-ce 6f 15 a0 1d ca f2 85
.f....1x.o......
0030 - 8e 44 b3 61 09 4f 87 f0-30 7c b4 d3 8a e6 be 39
.D.a.O..0|.....9
0040 - 47 ec 5e f8 36 bc ea 5e-7f 60 c9 13 ca a2 64 c6
G.^.6..^.`....d.
0050 - 3c ad 5f 5c fd ef 93 9b-0f 11 d2 e2 7d ba 21 e1
<._\........}.!.
0060 - e5 59 3c e8 90 bb cc e9-00 73 c7 8c 1d cc 8f b1
.Y<......s......
0070 - 2a b2 4b 08 08 2c 28 91-f1 b9 25 6b 9a a5 17 80
*.K..,(...%k....
0080 - a2 e5 47 8d 55 37 bd a0-83 c6 1e f9 ca 09 12 de
..G.U7..........
0090 - d4 7c e5 43 3c de df 48-5d e6 7d 82 58 52 c7 10
.|.C<..H].}.XR..
Start Time: 1591122561
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
To dały oba podejścia.
Serwer PKO łączy się po ipv6. Specjalnie enablowałem z tego powodu ipv6
z polityką DROP i dla nich dałem ACCEPT w ip6tables.
Wcześniej nie było żadnych problemów przez długi czas. Jak kilka dni
temu zorientowaliśmy się, że ważne poczty nie doszły i siedziały w queue
to przyjrzałęm się połączeniom i zobaczyłem, że łączy się po ipv6, więc
enablowałem ipv6 i zrobiłem dla niego furtke, ale nic to nie dało. po
jakichś 2 dniach nagle część poczt poszła, ale na drugi dzień znowu
kicha - to samo.
Z wysyłką do innych odbiorców póki, co nie ma problemów
LFC
LFC
Jun 3, 2020, 1:20:03 AM6/3/20
to
W dniu 02.06.2020 o 15:53, Andrzej A. Filip pisze:
>
> Jako root wykonaj:
> # popchnięcie wszystkich maili do pekao.com.pl w kolejce
> sendmail -v -qRpekao.com.pl
> # popchnięcie jednego maila z konkretnym queue-id w kolejce
> sendmail -v -qI0519KE6A014371
>
> P.S.
> Ja niestety z "sendmail-owego poradnictwa" mam brzydki nawyk reagowania
> po słowach kluczowych. Z tego powodu przeważnie+ proszenia o
> "dokładniejszą diagnostykę wstępną" bo "dziwnych i niezwykłych"
> problemów poznałem za dużo (na szczęście u innych).
>
Running /var/spool/mqueue/0519KE6A014371 (sequence 1 of 1)
<nasza...@pekao.com.pl>... Connecting to blue.pekao.com.pl. via esmtp...
220 Email system Pekao service
>>> EHLO mpwik.mpwikzdw.com.pl
250-Requested mail action okay, completed.
250 STARTTLS
>>> STARTTLS
220 Start TLS negotiation.
>>> EHLO host.domena.com.pl
250 Requested mail action okay, completed.
>>> MAIL From:<nasza.ksieg...@domena.com.pl>
250 Requested mail action okay, completed.
>>> RCPT To:<nasza...@pekao.com.pl>
250 Requested mail action okay, completed.
>>> DATA
354 Enter mail, end with "." on a line by itself.
>>> .
Tak to widać.
Co oznacza ta ostatnia linia?
Wyszedłem z tego przez ctr-C, a poczta nadal jest niewysłana.
LFC
>
> Jako root wykonaj:
> # popchnięcie wszystkich maili do pekao.com.pl w kolejce
> sendmail -v -qRpekao.com.pl
> # popchnięcie jednego maila z konkretnym queue-id w kolejce
> sendmail -v -qI0519KE6A014371
>
> P.S.
> Ja niestety z "sendmail-owego poradnictwa" mam brzydki nawyk reagowania
> po słowach kluczowych. Z tego powodu przeważnie+ proszenia o
> "dokładniejszą diagnostykę wstępną" bo "dziwnych i niezwykłych"
> problemów poznałem za dużo (na szczęście u innych).
>
<nasza...@pekao.com.pl>... Connecting to blue.pekao.com.pl. via esmtp...
220 Email system Pekao service
>>> EHLO mpwik.mpwikzdw.com.pl
250-Requested mail action okay, completed.
250 STARTTLS
>>> STARTTLS
220 Start TLS negotiation.
>>> EHLO host.domena.com.pl
250 Requested mail action okay, completed.
>>> MAIL From:<nasza.ksieg...@domena.com.pl>
250 Requested mail action okay, completed.
>>> RCPT To:<nasza...@pekao.com.pl>
250 Requested mail action okay, completed.
>>> DATA
354 Enter mail, end with "." on a line by itself.
>>> .
Tak to widać.
Co oznacza ta ostatnia linia?
Wyszedłem z tego przez ctr-C, a poczta nadal jest niewysłana.
LFC
LFC
Jun 3, 2020, 2:40:02 AM6/3/20
to
W dniu 02.06.2020 o 14:32, LFC pisze:
Sprawa już nieaktualna. Wydało się, co jest grane.
Dziś rano wysłałem kontrolnie emaila do pekao i przeszedł gładko.
Spróbowałem znowy wysłać tamta pocztę i znowu Error.
Ich serwerowi nie podobały się ząłączniki (zip i pdf podpisany xades)
Spakowałém je 7zipem do jednego pliku i poszło gładko.
Dzadostwo. Żeby choć jakiś komunikat w rodzaju "bad file attached", ale
nic - domyśl się.
LFC
Andrzej A. Filip
Jun 3, 2020, 3:38:26 AM6/3/20
to
LFC <l...@onet.eu> pisze:
Jak rozumiem twój serwer wysłał maila łącznie z "kropką na zakończenie"
i nie może się doczekać potwierdzenia odbioru.
Zasadniczo są dwie możliwości:
a) ich anty-spam/anty-wirus albo sprawdzacz nagłówków maila się ślimaczy
- wystarczy że walnie w problem z DNS i będzie miał (domyślne)
opóźnienie 75s [a ty masz timeoty 1m=60s]
Sprawdzenie: przywróć (testowo) domyślne timeouty na transmisje treści
mail (blok DATA). Zakomentuj (dnl …) te linie poniżej w sendmail.mc
[ wygeneruj nowy sendmail.cf, zrestartuj lub zHUPuj demona sendmaila]
define(`confTO_DATAINIT', `1m')dnl
define(`confTO_DATABLOCK', `1m')dnl
define(`confTO_DATAFINAL', `1m')dn
b) są problemy z wielkością pakietów TCP/IP (przejdą tylko mniejsze niż
domyślne) a pakiety ICMP giną gdzieś po drodze
Sprawdzenie: Wysłanie *MAŁEGO* maila (jedna linijka treści)
--
Andrzej A. Filip
i nie może się doczekać potwierdzenia odbioru.
Zasadniczo są dwie możliwości:
a) ich anty-spam/anty-wirus albo sprawdzacz nagłówków maila się ślimaczy
- wystarczy że walnie w problem z DNS i będzie miał (domyślne)
opóźnienie 75s [a ty masz timeoty 1m=60s]
Sprawdzenie: przywróć (testowo) domyślne timeouty na transmisje treści
mail (blok DATA). Zakomentuj (dnl …) te linie poniżej w sendmail.mc
[ wygeneruj nowy sendmail.cf, zrestartuj lub zHUPuj demona sendmaila]
define(`confTO_DATAINIT', `1m')dnl
define(`confTO_DATABLOCK', `1m')dnl
define(`confTO_DATAFINAL', `1m')dn
domyślne) a pakiety ICMP giną gdzieś po drodze
Sprawdzenie: Wysłanie *MAŁEGO* maila (jedna linijka treści)
--
Andrzej A. Filip
LFC
Jun 3, 2020, 5:20:02 AM6/3/20
to
W dniu 03.06.2020 o 09:37, Andrzej A. Filip pisze:
>
> Zasadniczo są dwie możliwości:
> a) ich anty-spam/anty-wirus albo sprawdzacz nagłówków maila się ślimaczy
> - wystarczy że walnie w problem z DNS i będzie miał (domyślne)
> opóźnienie 75s [a ty masz timeoty 1m=60s]
> Sprawdzenie: przywróć (testowo) domyślne timeouty na transmisje treści
> mail (blok DATA). Zakomentuj (dnl …) te linie poniżej w sendmail.mc
> [ wygeneruj nowy sendmail.cf, zrestartuj lub zHUPuj demona sendmaila]
>
> define(`confTO_DATAINIT', `1m')dnl
> define(`confTO_DATABLOCK', `1m')dnl
> define(`confTO_DATAFINAL', `1m')dn
>
> b) są problemy z wielkością pakietów TCP/IP (przejdą tylko mniejsze niż
> domyślne) a pakiety ICMP giną gdzieś po drodze
> Sprawdzenie: Wysłanie *MAŁEGO* maila (jedna linijka treści)
>
Już napisałem na grupie - załączniki mu się nie podobały (ale nie ze
względu na wielkość, choć oni mają też ograniczenie wielkości
załacznika, chyba do 6MB)).
Jeden był plikiem pdf podpisanym xades, a drugi zip, oba razem z 700kB.
Jak spakowałem oba 7zipem do jednego pliku, to poszło w takim tempie, ze
nie ma mowy o żadnych timeoutach.
Zbuldoczyło mnie tylko, że ich serwer po prostu przerywa transakcję nic
nie komunikując i nie ma się jak doinformować, o co chodzi.
LFC
>
> Zasadniczo są dwie możliwości:
> a) ich anty-spam/anty-wirus albo sprawdzacz nagłówków maila się ślimaczy
> - wystarczy że walnie w problem z DNS i będzie miał (domyślne)
> opóźnienie 75s [a ty masz timeoty 1m=60s]
> Sprawdzenie: przywróć (testowo) domyślne timeouty na transmisje treści
> mail (blok DATA). Zakomentuj (dnl …) te linie poniżej w sendmail.mc
> [ wygeneruj nowy sendmail.cf, zrestartuj lub zHUPuj demona sendmaila]
>
> define(`confTO_DATAINIT', `1m')dnl
> define(`confTO_DATABLOCK', `1m')dnl
> define(`confTO_DATAFINAL', `1m')dn
>
> b) są problemy z wielkością pakietów TCP/IP (przejdą tylko mniejsze niż
> domyślne) a pakiety ICMP giną gdzieś po drodze
> Sprawdzenie: Wysłanie *MAŁEGO* maila (jedna linijka treści)
>
względu na wielkość, choć oni mają też ograniczenie wielkości
załacznika, chyba do 6MB)).
Jeden był plikiem pdf podpisanym xades, a drugi zip, oba razem z 700kB.
Jak spakowałem oba 7zipem do jednego pliku, to poszło w takim tempie, ze
nie ma mowy o żadnych timeoutach.
Zbuldoczyło mnie tylko, że ich serwer po prostu przerywa transakcję nic
nie komunikując i nie ma się jak doinformować, o co chodzi.
LFC
Andrzej A. Filip
Jun 3, 2020, 6:38:45 AM6/3/20
to
LFC <l...@onet.eu> pisze:
Przy jednominutowych timeoutach może nie doczekałeś odpowiedzi.
Jestem niezbyt przekonany że tak jest ale mi się chce sprawdzać jeszcze
mniej niż tobie.
--
Andrzej A. Filip
Jestem niezbyt przekonany że tak jest ale mi się chce sprawdzać jeszcze
mniej niż tobie.
--
Andrzej A. Filip
LFC
Jun 3, 2020, 8:20:02 AM6/3/20
to
W dniu 03.06.2020 o 12:38, Andrzej A. Filip pisze:
>
> Przy jednominutowych timeoutach może nie doczekałeś odpowiedzi.
> Jestem niezbyt przekonany że tak jest ale mi się chce sprawdzać jeszcze
> mniej niż tobie.
>
We wcześniejszym okresie przesyłaliśmy im pocztę z załącznikami rzędu
20MB i więcej, spakowanymi tak, żeby w kawałkach nie przekraczały tych
6MB i wszystko szło bez przeszkód i timeoutów.
Dlatego sądzę, że zabezpieczyli serwer, zeby nie przyjmował poczt z
określonymi załacznikami, ale nie będę się dalej zmóżdżał nad sprawą bo
ewidentnie transfer działa w obie strony, a kontaktu z ich służbami
odpowiedzialnymi za serwery praktycznie nie ma.
Nawet pracownicy banku, jak mają jakieś problemy zgłoszone ze strony
klientów,to piszą na helpdeska i często nie doczekuja się żadnej
sensownej odpowiedzi, czy reakcji.
LFC
>
> Przy jednominutowych timeoutach może nie doczekałeś odpowiedzi.
> Jestem niezbyt przekonany że tak jest ale mi się chce sprawdzać jeszcze
> mniej niż tobie.
>
20MB i więcej, spakowanymi tak, żeby w kawałkach nie przekraczały tych
6MB i wszystko szło bez przeszkód i timeoutów.
Dlatego sądzę, że zabezpieczyli serwer, zeby nie przyjmował poczt z
określonymi załacznikami, ale nie będę się dalej zmóżdżał nad sprawą bo
ewidentnie transfer działa w obie strony, a kontaktu z ich służbami
odpowiedzialnymi za serwery praktycznie nie ma.
Nawet pracownicy banku, jak mają jakieś problemy zgłoszone ze strony
klientów,to piszą na helpdeska i często nie doczekuja się żadnej
sensownej odpowiedzi, czy reakcji.
LFC
0 new messages