🚀 go-pugleaf

W dniu 02.06.2020 o 14:32, LFC pisze:
> 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.pani@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.ksiegowa@domena.com.pl>
> MDeferred: Connection timed out with blue.pekao.com.pl.
> rRFC822; nasz.pani@pekao.com.pl
> RPFD:<nasza.pani@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


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

LFC <lfc@onet.eu> pisze:
[…]
> 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.pani@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

W dniu 2020-06-02 o 15:40, Lemat pisze:
> W dniu 02.06.2020 o 14:32, LFC pisze:
>> 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.pani@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.ksiegowa@domena.com.pl>
>> MDeferred: Connection timed out with blue.pekao.com.pl.
>> rRFC822; nasz.pani@pekao.com.pl
>> RPFD:<nasza.pani@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
> 
> 
> Te timeouty to mi wygladąją na timeouty serwera
> a problem dotyczy timeoutów klienta.
> 
> zrób telnet na port 25
> i/lub

po EHLO daje STARTTLS i czeka na dalsze komendy

> openssl s_client -connect 193.111.166.171:25 -starttls smtp
> 


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

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

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.pani@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.ksiegowa.swiatek@domena.com.pl>
250 Requested mail action okay, completed.
 >>> RCPT To:<nasza.pani@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

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

LFC <lfc@onet.eu> pisze:
> 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.pani@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.ksiegowa.swiatek@domena.com.pl>
> 250 Requested mail action okay, completed.
>>>> RCPT To:<nasza.pani@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.

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

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

LFC <lfc@onet.eu> pisze:
> 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

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

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