fixing CONNECT-then-immediate-DISCONNECT from some senders?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

fixing CONNECT-then-immediate-DISCONNECT from some senders?

robgane
I run Postfix 3.3.

My inbound mail is working great, except for a few 'newsletters' I sign up for.

From a few "legit" newsletter senders, i.e. those that I opt-in with, I get

        CONNECT/DISCONNECT

pairs in my logs.  And of course no delivery.

In the logs I get these

        Jul 23 06:22:21 maryland postfix/handoff/smtpd[7668]: connect from smtp10.ymem.net[24.73.102.76]
        Jul 23 06:22:22 maryland postfix/handoff/smtpd[7668]: disconnect from smtp10.ymem.net[24.73.102.76] ehlo=1 mail=0/1 quit=1 commands=2/3

On the postfix mailing list I found this thread

        http://postfix.1071664.n5.nabble.com/meaning-of-connect-immediately-followed-by-disconnect-in-mail-log-td32773.html

that says

        As of 20090109, Postfix 2.6 supports a workaround.
        ...
        Specify "tcp_windowsize = 65535" (or less) to work around routerswith broken TCP window scaling implementations.

So I did that and have

        postconf tcp_windowsize
                tcp_windowsize = 65535

But I still get these connect/disconnect pairs.

Any other ideas for workaround?

I added "-v" for the 'handoff/smtpd' instance but that doesn't seem to tell me what's causing these immediate disconnects.  Is there a better way to get more information on the disconnect reason?

Rob
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixing CONNECT-then-immediate-DISCONNECT from some senders?

Viktor Dukhovni

> On Jul 31, 2017, at 1:17 PM, [hidden email] wrote:
>
> Jul 23 06:22:21 maryland postfix/handoff/smtpd[7668]: connect from smtp10.ymem.net[24.73.102.76]
> Jul 23 06:22:22 maryland postfix/handoff/smtpd[7668]: disconnect from smtp10.ymem.net[24.73.102.76] ehlo=1 mail=0/1 quit=1 commands=2/3

The client sent:

        EHLO        -- which your server accepted
        MAIL FROM:  -- -"- rejected
        QUIT        -- -"- accepted

Find out why you're rejecting the client's "MAIL FROM:" command.
This would typically be logged, but you can also use tcpdump to
record the SMTP session and look there as a last resort.

TCP buffer sizes are unlikely to be relevant here.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixing CONNECT-then-immediate-DISCONNECT from some senders?

robgane
Hi Viktor

On Mon, Jul 31, 2017, at 10:30 AM, Viktor Dukhovni wrote:
> > Jul 23 06:22:21 maryland postfix/handoff/smtpd[7668]: connect from smtp10.ymem.net[24.73.102.76]
> > Jul 23 06:22:22 maryland postfix/handoff/smtpd[7668]: disconnect from smtp10.ymem.net[24.73.102.76] ehlo=1 mail=0/1 quit=1 commands=2/3
>
> The client sent:
>
> EHLO        -- which your server accepted
> MAIL FROM:  -- -"- rejected
> QUIT        -- -"- accepted

So THAT'S what those are telling me!  Missed that in the docs :-(

> Find out why you're rejecting the client's "MAIL FROM:" command.

Huh.   No idea what's causing the sender's FROM to be rejected -- should be an OK address.

> This would typically be logged

So it SHOULD be logged.

By the handoff/smtpd instance right? Not by the postscreen in fron of it?

Like I mentioned I did turn on the "-v" for it.  Nothing more.

> but you can also use tcpdump to record the SMTP session and look there as a last resort.

I can get that set up.

I'd like to figure out why any logging that SHOULD be working , isn't.

> TCP buffer sizes are unlikely to be relevant here.

Ok!

Rob
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixing CONNECT-then-immediate-DISCONNECT from some senders?

Viktor Dukhovni

> On Jul 31, 2017, at 1:39 PM, [hidden email] wrote:
>
>> Find out why you're rejecting the client's "MAIL FROM:" command.
>
> Huh.   No idea what's causing the sender's FROM to be rejected -- should be an OK address.
>
>> This would typically be logged
>
> So it SHOULD be logged.
>
> By the handoff/smtpd instance right? Not by the postscreen in fron of it?

Of course.

> Like I mentioned I did turn on the "-v" for it.  Nothing more.

The main effect of "-v" in most cases is to obscure the relevant logs
with lots of noise from the irrelevant logs.  In most cases "-v" is
counter-productive.  Policy rejection of the "MAIL FROM:" is covered
by routine (non-verbose) logging.  Rejection of messages that exceed
the maximum message size limit (ESMTP SIZE=... option in MAIL FROM)
or have syntax errors in the sender address does not produce log
records, as it is too easy to flood the logs with these.

For the latter category "tcpdump" or debug_peer_list (origin-dependent
"-v") may be appropriate.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixing CONNECT-then-immediate-DISCONNECT from some senders?

robgane
Hi Viktor

On Mon, Jul 31, 2017, at 12:45 PM, Viktor Dukhovni wrote:
> The main effect of "-v" in most cases is to obscure the relevant logs
> with lots of noise from the irrelevant logs.

No kidding!

>  Policy rejection of the "MAIL FROM:" is covered
> by routine (non-verbose) logging.

Ok so I do have some kindof problem.

> the maximum message size limit (ESMTP SIZE=... option in MAIL FROM)

I don't know about that one yet.  Reading.

> or have syntax errors in the sender address does not produce log
> records, as it is too easy to flood the logs with these.
>
> For the latter category "tcpdump" or debug_peer_list (origin-dependent
> "-v") may be appropriate.

Didn't know about debug_peer_list yet.  VERY handy!

What debug_peer_level would catch 'ESMTP SIZE=' and 'syntax errors in the sender address' issues? Only for the debug_peer_list table entries.

The docs read as 'increment'.  I don't know yet if that's additive on top of some other value? Or just an absolute value.

Rob
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixing CONNECT-then-immediate-DISCONNECT from some senders?

robgane
> What debug_peer_level would catch 'ESMTP SIZE=' and 'syntax errors in the sender address' issues? Only for the debug_peer_list table entries.

That seems to be only the debug level for smtpd right?

Is there a different domain-specific parameter that sets log level for tls@smtpd?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixing CONNECT-then-immediate-DISCONNECT from some senders?

Viktor Dukhovni
In reply to this post by robgane

> On Jul 31, 2017, at 4:05 PM, [hidden email] wrote:
>
> What debug_peer_level would catch 'ESMTP SIZE=' and 'syntax errors in the sender address' issues? Only for the debug_peer_list table entries.
>
> The docs read as 'increment'.  I don't know yet if that's additive on top of some other value? Or just an absolute value.

The default debug_peer_level (2) is sufficient, but even (1) is likely enough
to log the SMTP conversation (which is all you need here).

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixing CONNECT-then-immediate-DISCONNECT from some senders?

Viktor Dukhovni
In reply to this post by robgane

> On Jul 31, 2017, at 4:09 PM, [hidden email] wrote:
>
>> What debug_peer_level would catch 'ESMTP SIZE=' and 'syntax errors in the sender address' issues? Only for the debug_peer_list table entries.
>
> That seems to be only the debug level for smtpd right?
>
> Is there a different domain-specific parameter that sets log level for tls@smtpd?

As documented, debug_peer_list determines which clients have a higher than
default debug level.  There is no similar mechanism for TLS logging, which
is the same for all clients (based on smtpd_tls_loglevel).

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixing CONNECT-then-immediate-DISCONNECT from some senders?

robgane
Viktor

> >> What debug_peer_level would catch 'ESMTP SIZE=' and 'syntax errors in the sender address' issues? Only for the debug_peer_list table entries.

The default debug_peer_level (2) is sufficient, but even (1) is likely enough
to log the SMTP conversation (which is all you need here).

I set it to 2 for just one known problem sender.  I'll see what that tells me. Thanks.

> > That seems to be only the debug level for smtpd right?
> As documented, debug_peer_list determines which clients have a higher than
> default debug level.

I was asking about level, not list.  Buy anyway I got it sorted out.

> > Is there a different domain-specific parameter that sets log level for tls@smtpd?
> There is no similar mechanism for TLS logging, which
> is the same for all clients (based on smtpd_tls_loglevel).

Ok.  It'd be really handy though!

Rob
Loading...