some users can't receive mails from domain.

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

some users can't receive mails from domain.

Selcuk Yazar
Hi,
Some of our users can receive mail from national academic journal site but a few can't. when i look the logs, it says;
..  
 timeout after END-OF-MESSAGE from rs248.mailgun.us[209.61.151.248]
..
is it about our server or their server ?

thanks in advance
--
Selçuk YAZAR

Reply | Threaded
Open this post in threaded view
|

Re: some users can't receive mails from domain.

Viktor Dukhovni
> On Dec 12, 2018, at 2:49 PM, Selcuk Yazar <[hidden email]> wrote:
>
> Hi,
> Some of our users can receive mail from national academic journal site but a few can't. when i look the logs, it says;
> ..  
>  timeout after END-OF-MESSAGE from rs248.mailgun.us[209.61.151.248]
> ..
> is it about our server or their server ?
>
> thanks in advance

You'll need a PCAP capture:

  http://www.postfix.org/DEBUG_README.html#sniffer

which you can analyze with wireshark, tshark, or similar.

Often this is indicative of path MTU issues, but the PCAP file
should tell all.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: some users can't receive mails from domain.

Wietse Venema
In reply to this post by Selcuk Yazar
Selcuk Yazar:
> Hi,
> Some of our users can receive mail from national academic journal site but
> a few can't. when i look the logs, it says;
> ..
>  timeout after END-OF-MESSAGE from rs248.mailgun.us[209.61.151.248]
> ..
> is it about our server or their server ?

Probably none of that, i.e. suspect a network-level problem. These
tend to be caused by middleboxes (firewalls, traffic shapers, etc.)
that break path MTU discovery, TCP window scaling, both, or something
else. As Victor suggests, only a packet sniffer can determine the
cause. No packet content is needed, but TCP metadata is essential
(handshake, flags, ack, window size, etc.).

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: some users can't receive mails from domain.

Benny Pedersen-2
In reply to this post by Selcuk Yazar
Selcuk Yazar skrev den 2018-12-12 20:49:

>  timeout after END-OF-MESSAGE from rs248.mailgun.us
> [209.61.151.248]
> ..
> is it about our server or their server ?

i have prolems with them aswell, turned out have problems with ssl/tls

dont know how to solve it

openssl here have sslv2 and sslv3 disabled at compile time
Reply | Threaded
Open this post in threaded view
|

Re: some users can't receive mails from domain.

Viktor Dukhovni
> On Dec 12, 2018, at 3:15 PM, Benny Pedersen <[hidden email]> wrote:
>
> I have problems with them as well, turned out have problems with ssl/tls

If you want the problem solved, start by posting non-verbose logs that
show the problem behaviour.  Don't get distracted by SSL handshake
failures from some broken clients, if the client then retries in
cleartext.  Some systems fail to implement opportunistic TLS sensibly.

SSL is unlikely to be a barrier mid-stream in data transfer, generally
once the handshake is over, encryption does not noticeably impede
data transfer.

--
--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: some users can't receive mails from domain.

Benny Pedersen-2
Viktor Dukhovni skrev den 2018-12-12 21:29:
>> On Dec 12, 2018, at 3:15 PM, Benny Pedersen <[hidden email]> wrote:
>>
>> I have problems with them as well, turned out have problems with
>> ssl/tls
>
> If you want the problem solved, start by posting non-verbose logs that
> show the problem behaviour.  Don't get distracted by SSL handshake
> failures from some broken clients, if the client then retries in
> cleartext.  Some systems fail to implement opportunistic TLS sensibly.

Dec 11 09:58:53 localhost postfix/smtpd[24986]: connect from
rs241.mailgun.us[209.61.151.241]
Dec 11 09:58:54 localhost postfix/smtpd[24986]: SSL_accept error from
rs241.mailgun.us[209.61.151.241]: 0
Dec 11 09:58:54 localhost postfix/smtpd[24986]: lost connection after
STARTTLS from rs241.mailgun.us[209.61.151.241]
Dec 11 09:58:54 localhost postfix/smtpd[24986]: disconnect from
rs241.mailgun.us[209.61.151.241] ehlo=1 starttls=0/1 commands=1/2

more logs ?
Reply | Threaded
Open this post in threaded view
|

Re: some users can't receive mails from domain.

Viktor Dukhovni
On Wed, Dec 12, 2018 at 10:16:14PM +0100, Benny Pedersen wrote:

> postfix/smtpd[24986]: connect from rs241.mailgun.us[209.61.151.241]
> postfix/smtpd[24986]: SSL_accept error from rs241.mailgun.us[209.61.151.241]: 0
> postfix/smtpd[24986]: lost connection after STARTTLS from rs241.mailgun.us[209.61.151.241]
> postfix/smtpd[24986]: disconnect from rs241.mailgun.us[209.61.151.241] ehlo=1 starttls=0/1 commands=1/2

As expected this is a handshake problem, but I would expect to see
additional log messages showing more detailed SSL library error
details.  For example, my logs have:

  postfix/smtpd[72804]: connect from sonic315-20.consmr.mail.ne1.yahoo.com[66.163.190.146]
  postfix/smtpd[72804]: SSL_accept error from sonic315-20.consmr.mail.ne1.yahoo.com[66.163.190.146]: -1
  postfix/smtpd[72804]: warning: TLS library problem:
    error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown:
    ssl/record/rec_layer_s3.c:1528:SSL alert number 46:
  postfix/smtpd[72804]: lost connection after STARTTLS from sonic315-20.consmr.mail.ne1.yahoo.com[66.163.190.146]

Which was supposed to have been fixed some time back, but Yahoo
have never quite gotten around to actually doing it.  Anyway, where's
your "TLS library problem" log message?  Perhaps this is a case
where the handshake fails at the TCP layer (the remote end simply
hangs up), in which case Postfix logging may not be as detailed as
it could be.  Here's a patch for 3.3.2, that may show more detail.

diff --git a/src/tls/tls_bio_ops.c b/src/tls/tls_bio_ops.c
index 1f4ec41f..c427a646 100644
--- a/src/tls/tls_bio_ops.c
+++ b/src/tls/tls_bio_ops.c
@@ -279,8 +279,10 @@ int     tls_bio(int fd, int timeout, TLS_SESS_STATE *TLScontext,
  case SSL_ERROR_ZERO_RETURN:
  case SSL_ERROR_NONE:
     errno = 0; /* avoid bogus warnings */
-    /* FALLTHROUGH */
+    return (status);
  case SSL_ERROR_SYSCALL:
+    if (hsfunc && errno != 0)
+ msg_warn("SSL handshake I/O error: %m");
     return (status);
  }
     }

--
        Viktor.