Selcuk Yazar:
> postfix/smtpd[6055]: lost connection after DATA (3865 bytes) from
> mx2.iparadigms.com[199.47.85.44]
Possible cause:
- Broken WSCALE (window scaling).
https://en.wikipedia.org/wiki/TCP_window_scale_option
Less likely, because the failure happened after 3865 bytes:
-
9.47.85.44, *helo=mx2.turnitin.com <http://mx2.turnitin.com> *
postfix/smtpd[6055]: lost connection after DATA (3865 bytes) from
*mx2.iparadigms.com
<http://mx2.iparadigms.com>*[199.47.85.44]
dig mx2.turnitin.com
;; ANSWER SECTION:
mx2.turnitin.com. 900 IN A 199.
Hi Viktor,
Am 11.09.2014 um 16:04 schrieb Viktor Dukhovni:
Your PCAP files should demonstrate repeated retransmission of data,
are the ACKs you're sending confirming receipt of packets that are
sent repeatedly? In that case your ACKs are getting lost? Is
there a sequence number gap in the
Hi Wietse,
Am 11.09.2014 um 17:10 schrieb Wietse Venema:
That increases my suspicion of a data-dependent error - some marginal
cable/switch/router, perhaps some middle box with a memory bit error
that requires a power cycle to clear the problem. If the problem is
caused by crosstalk defect,
Hi Hannes,
Am 11.09.2014 um 20:48 schrieb Hannes Erven:
I remember a possibly similar situation back in 2008... the culprit was a
not-fully-up-to-date Cisco ASA firewall that corrupted TCP SACK fields and
hence had the remote site send RSET.
Anyways on our end the connection seemed to
Hi Mark,
Am 11.09.2014 um 22:59 schrieb L. Mark Stone:
Any chance there is a UTM device in the email stream?
Possible, but I wouldn't know. This is a rented rootserver in some data center.
I don't know their topology, and they probably wouldn't tell me even if I asked.
We see lots of these
On Fri, Sep 12, 2014 at 10:36:51AM +0200, Sean Durkin wrote:
If it's a middle box somewhere along the way, that's even worse.
Even more different people potentially involved...
I would rent a backup MX server (deploy identical anti-spam policies,
and lists of valid recipients, ...) at a
Hello Wietse,
Am 10.09.2014 um 21:52 schrieb Wietse Venema:
Slow performance is typical for TCP window scaling problems. Have
you tried to turn it off in your kernel?
Yes, Viktor suggested that also and I tried it. It does not make a difference,
the problem persists.
Regards,
Sean
Sean Durkin:
Hello Wietse,
Am 10.09.2014 um 21:52 schrieb Wietse Venema:
Slow performance is typical for TCP window scaling problems. Have
you tried to turn it off in your kernel?
Yes, Viktor suggested that also and I tried it. It does not make
a difference, the problem persists.
postfix/smtpd[25537]: 8736FC40A7D:
client=quattuorocto.psi.cust-cluster.com[195.140.187.48]
Sep 11 10:36:44 mail postfix/smtpd[25537]: lost connection after DATA (36809
bytes) from quattuorocto.psi.cust-cluster.com[195.140.187.48]
Sep 11 10:36:44 mail postfix/smtpd[25537]: disconnect from
mail18-21.srv2.de[193.169.181.21]
Sep 11 09:43:31 mail postfix/smtpd[25170]: 2C076C4026A:
client=mail18-21.srv2.de[193.169.181.21]
Sep 11 09:46:33 mail postfix/smtpd[25170]: lost connection after DATA (33290
bytes) from mail18-21.srv2.de[193.169.181.21]
Sep 11 09:46:33 mail postfix/smtpd[25170
Hi Wietse,
Am 11.09.2014 um 13:49 schrieb Wietse Venema:
What is the distribution of DATA sizes before failure? In your
example I see numbers around 3kB, 9kB, 12kB.
At the moment, I see these sizes:
- always exactly 17511 bytes from smtp-out-127-*.amazon.com (today, seems to be
only 3
On Thu, Sep 11, 2014 at 03:25:57PM +0200, Sean Durkin wrote:
I can contact support, but they of course charge you for
everything they do, and as long as I haven't ruled out that the
reason is just some stupid configuration mistake on my part (or a
routing/filtering issue at my hosting
Sean Durkin:
Hi Wietse,
Am 11.09.2014 um 13:49 schrieb Wietse Venema:
What is the distribution of DATA sizes before failure? In your
example I see numbers around 3kB, 9kB, 12kB.
At the moment, I see these sizes:
- always exactly 17511 bytes from smtp-out-127-*.amazon.com (today,
Hi Sean,
Meanwhile, I've managed to record a tcpdump of such a failed session.
What exactly am I looking for there?
I remember a possibly similar situation back in 2008... the culprit was
a not-fully-up-to-date Cisco ASA firewall that corrupted TCP SACK fields
and hence had the remote site
Sean Durkin:
Meanwhile, I've managed to record a tcpdump of such a failed
session. What exactly am I looking for there?
- The receiving host's window announcement in the tcp handshake
and in subsequent ACKs.
- Whether there is a gap in the sender packet sequence numbers
as seen by the
Any chance there is a UTM device in the email stream?
We see lots of these errors when our SonicWalls do an RBL lookup, don't like
the data in the email stream etc. The SonicWalls then just drop the connection
and Postfix logs the drop.
Hope that helps,
Mark
of this:
[... snip ...]
Sep 10 00:06:37 mail postfix/smtpd[23095]: lost connection after DATA (17511
bytes) from smtp-out-127-108.amazon.com[176.32.127.108]
Sep 10 00:06:48 mail postfix/smtpd[23111]: lost connection after DATA (22788
bytes) from mail18-92.srv2.de[193.169.181.92]
Sep 10 00:13:35 mail
Am 10.09.2014 um 09:56 schrieb Sean Durkin:
The first question is:
Can I rule out it's my fault?
have you changed anything last days/month upgrades/updates software
hardware ?
please send you postfix config , search list archive lost connection
after DATA
Best Regards
MfG Robert Schetterer
, increasing log verbosity
and such, I found a lot of this:
Have you tried disabling TCP window scaling? It might be confusing
some middle-box (firewall, NAT device, ...) on path between the
remote systems and your MTA.
[... snip ...]
Sep 10 00:06:37 mail postfix/smtpd[23095]: lost connection
not seem to make a difference. So I'm now back to
a very basic Postfix conf, but the problem persists.
please send you postfix config ,
Anonymized postfinger-output is attached below.
search list archive lost connection after DATA
I did that, I couldn't find anything that really applies in my
Hi Viktor,
Am 10.09.2014 um 16:19 schrieb Viktor Dukhovni:
Have you tried disabling TCP window scaling? It might be confusing
some middle-box (firewall, NAT device, ...) on path between the
remote systems and your MTA.
I would not have thought of that... I've tried that now, but it does not
Sean Durkin:
[ Charset windows-1252 converted... ]
Hi Viktor,
Am 10.09.2014 um 16:19 schrieb Viktor Dukhovni:
Have you tried disabling TCP window scaling? It might be confusing
some middle-box (firewall, NAT device, ...) on path between the
remote systems and your MTA.
I would not
On Wed, Sep 10, 2014 at 09:19:58PM +0200, Sean Durkin wrote:
For at least one such session, post all related messages from the
postfix/smtpd[pid] that occur between connect from and
disconnect from.
Here's one: http://pastebin.com/twb3Z8Eg
This trace has an insane level of debugging
Hello,
one question about connection errors...for example:
Jun 19 08:43:37 postfix/smtpd[26460]: connect from unknown[x]
Jun 19 08:43:46 postfix/smtpd[26460]: 7EAD855B8355: client=unknown[x]
Jun 19 08:43:55 postfix/smtpd[26460]: lost connection after DATA (17
bytes) from unknown[x]
Jun 19 08:43
On Thu, Jun 19, 2014 at 09:06:34AM +0200, Alvaro Mar?n wrote:
Jun 19 08:43:37 postfix/smtpd[26460]: connect from unknown[x]
Jun 19 08:43:46 postfix/smtpd[26460]: 7EAD855B8355: client=unknown[x]
Jun 19 08:43:55 postfix/smtpd[26460]: lost connection after DATA (17 bytes)
from unknown[x]
Jun
, something like:
Jun 19 08:43:55 postfix/smtpd[26460]: 7EAD855B8355: lost connection
after DATA (17 bytes) from unknown[x]
In this specific case, I could search with the smtpd PID but I guess
that is not unique.
Regards,
--
Alvaro Marín Illera
Hostalia Internet
www.hostalia.com
, something like:
Jun 19 08:43:55 postfix/smtpd[26460]: 7EAD855B8355: lost connection
after DATA (17 bytes) from unknown[x]
It was far from clear you were asking for a queue-id here, that's
possible, but would likely require changes in existing log parsing
scripts. Not sure this is sufficiently
:
On Thu, Jun 19, 2014 at 09:06:34AM +0200, Alvaro Mar?n wrote:
Jun 19 08:43:37 postfix/smtpd[26460]: connect from unknown[x]
Jun 19 08:43:46 postfix/smtpd[26460]: 7EAD855B8355: client=unknown[x]
Jun 19 08:43:55 postfix/smtpd[26460]: lost connection after DATA (17 bytes)
from unknown[x]
Jun 19 08
connection error, something like:
Jun 19 08:43:55 postfix/smtpd[26460]: 7EAD855B8355: lost connection
after DATA (17 bytes) from unknown[x]
It was far from clear you were asking for a queue-id here, that's
possible, but would likely require changes in existing log parsing
scripts
All of a sudden (Monday morning - typical) we have starting getting this
error:
postfix/smtpd[4696]: lost connection after DATA (0 bytes) from XXX...
Which is resulting in the following bounce back to senders:
Server refused mail at END OF DATA - 554 5.7.1 This message has been
blocked because
Simon:
All of a sudden (Monday morning - typical) we have starting getting this
error:
postfix/smtpd[4696]: lost connection after DATA (0 bytes) from XXX...
Your server loses the SMTP connection.
Which is resulting in the following bounce back to senders:
Server refused mail at END
On Sun, 11 Dec 2011 22:57:12 -0500
Jim Seymour jseym...@linxnet.com wrote:
On Sun, 11 Dec 2011 20:03:59 -0500 (EST)
Wietse Venema wie...@porcupine.org wrote:
Wietse Venema:
bge1 @0:24 b my_outside_ip,25 - 89.73.201.168,36545 PR
tcp len 20 40 -AR OUT
Why are you blocking
James Seymour:
-AR means the ACK and RST flags are set.
My question is why is your firewall blocking outbound ACK|RST?
I'm using basically canned rulesets in my ipfilter setup. That is
the default deny at the end of bge1's output filters.
I must've
On Mon, 12 Dec 2011 08:24:38 -0500 (EST)
Wietse Venema wie...@porcupine.org wrote:
[snip]
There are two stateful engines: the TCP stack and ipfilter.
*nodding*
With keep state, ipfilter remembers the connection and lets
packets pass, up to the point that ipfilter believes the connection
James Seymour:
The TCP stack sends an outbound ACK|RST because it received
*something* on port 25. Your firewall should not have passed that.
Should not have passed it *incoming*, do you mean?
Indeed (assuming that ipfilter actually tracks state in the exact
same way as the TCP stack,
On Mon, 12 Dec 2011 09:11:26 -0500 (EST)
Wietse Venema wie...@porcupine.org wrote:
James Seymour:
The TCP stack sends an outbound ACK|RST because it received
*something* on port 25. Your firewall should not have passed that.
Should not have passed it *incoming*, do you mean?
Indeed
Client host
rejected: cannot find your reverse hostname, [89.73.201.168];
from=a...@carloerbareactifs.com to=nngu...@mydom.ain
proto=ESMTP helo=89-73-201-168.dynamic.chello.pl
Dec 11 17:47:11 myhost postfix/smtpd[48290]: lost connection
after DATA from unknown[89.73.201.168
...@mydom.ain
proto=ESMTP helo=89-73-201-168.dynamic.chello.pl
Dec 11 17:47:11 myhost postfix/smtpd[48290]: lost connection
after DATA from unknown[89.73.201.168]
Dec 11 17:47:11 myhost postfix/smtpd[48290]: disconnect from
unknown[89.73.201.168]
This particular one occurred
Jim Seymour:
Hi All,
This may be a weird one, and may be completely OT. If the latter:
Feel free to tell me to bugger off :)
System is FreeBSD 8.2, running ipfilter and
postfix-current-2.9.2019,4.
Occasionally I see something like this from ipfilter in
/var/log/messages:
4.7.1 Client host
rejected: cannot find your reverse hostname, [89.73.201.168];
from=a...@carloerbareactifs.com to=nngu...@mydom.ain
proto=ESMTP helo=89-73-201-168.dynamic.chello.pl
Dec 11 17:47:11 myhost postfix/smtpd[48290]: lost connection
after DATA from unknown
On Mon, 12 Dec 2011 00:14:08 +0100
Reindl Harald h.rei...@thelounge.net wrote:
[snip]
why do you use reject_unknown_reverse_client_hostname if you do
not like the results of it?
Why do you answer the question when you obviously have not read it?
(Or at least apparently not understood it.)
Am 12.12.2011 01:04, schrieb Jim Seymour:
On Mon, 12 Dec 2011 00:14:08 +0100
Reindl Harald h.rei...@thelounge.net wrote:
[snip]
why do you use reject_unknown_reverse_client_hostname if you do
not like the results of it?
Why do you answer the question when you obviously have not read it?
On Sun, 11 Dec 2011 18:35:23 -0500 (EST)
Wietse Venema wie...@porcupine.org wrote:
[snip]
Why are you blocking outbound TCP RST?
I am not, to the best of my knowledge.
There is a TCP control traffic rate limit in the border router, there
as a DoS prevention tactic, but that's it.
This
On Mon, 12 Dec 2011 01:11:00 +0100
Reindl Harald h.rei...@thelounge.net wrote:
Am 12.12.2011 01:04, schrieb Jim Seymour:
On Mon, 12 Dec 2011 00:14:08 +0100
Reindl Harald h.rei...@thelounge.net wrote:
[snip]
why do you use reject_unknown_reverse_client_hostname if you do
not like
On Sun, 11 Dec 2011 19:15:35 -0500
Jim Seymour jseym...@linxnet.com wrote:
Each of them occurs two-or-more
times, involving the same contacting IP.
Clarification: That was to say that, when it occurs multiple times
in a row, it's the same IP trying over-and-over again in each set of
retries. A
On Sun, 11 Dec 2011 20:03:59 -0500 (EST)
Wietse Venema wie...@porcupine.org wrote:
Wietse Venema:
bge1 @0:24 b my_outside_ip,25 - 89.73.201.168,36545 PR
tcp len 20 40 -AR OUT
Why are you blocking outbound TCP RST?
According to ipmon(8),
The web is rotting my brain. I never
Hi
Why would postfix log lost connection after DATA from
ns.0.us.jsdaav.net[98.158.177.54] after receiving a mail that contains
the following hyperlink?
a moz-do-not-send=true href=mailto:diseasemanagem...@bestmed.co.za;
target=_blank
title=blocked::mailto:diseasemanagem
Bennie Joubert:
Hi
Why would postfix log lost connection after DATA from
ns.0.us.jsdaav.net[98.158.177.54] after receiving a mail that contains
the following hyperlink?
Because something decides to break the connection and it isn't Postfix.
Look for security products such as firewalls
p34 postfix/smtpd[29148]: input attribute name: (end)
Feb 10 10:17:05 p34 postfix/smtpd[29148]: lost connection after DATA (5109403
bytes) from unknown[166.137.8.8]
Feb 10 10:17:05 p34 postfix/smtpd[29148]: disconnect from unknown[166.137.8.8]
Justin.
Justin Piszcz:
Feb 10 10:16:38 p34 postfix/cleanup[29153]: BD7141200F4:
message-id=fefad905-882b-4984-81bb-38292e820...@lucidpixels.com
Feb 10 10:16:38 p34 postfix/cleanup[29153]: BD7141200F4: warning: header
X-Mailer: iPhone Mail (8C148) from unknown[166.137.8.8];
I have a problem with receiving mail from yandex (large mail service).
May 21 13:30:09 mx postfix/smtpd[77115]: timeout after DATA (47440 bytes) from
forward11.mail.yandex.net[95.108.130.93]
May 21 13:31:56 mx postfix/smtpd[76924]: lost connection after DATA (33439
bytes) from forward3
I have a problem with receiving mail from yandex (large mail service).
May 21 13:30:09 mx postfix/smtpd[77115]: timeout after DATA (47440
bytes) from forward11.mail.yandex.net[95.108.130.93]
May 21 13:31:56 mx postfix/smtpd[76924]: lost connection after DATA
(33439 bytes) from forward3
Did you try... oh, I dunno, *asking* yandex ?
They have logs that can tell you what happens; you don't.
Yes, I did.
ya-dump.cap was captured by yandex support. They told to me that have conversation
with mx.tehstroi.ru[81.25.172.91] timed out while sending message body errors. Also
they
[76924]: lost connection after DATA (33439
bytes) from forward3.mail.yandex.net[77.88.46.8]
May 21 13:32:39 mx postfix/smtpd[77207]: lost connection after DATA (75160
bytes) from forward14.mail.yandex.net[95.108.130.92]
I have no problem with receiving mail from other servers.
I have
On 2010-05-13 9:59 PM, Gary Smith wrote:
Anyway, we are still receiving them. The firewall allows port 25
incoming, everything outgoing but there is also some nat'ing going on
because of the ipvsadm. Anyone ever seen this type of issue with
this type of config?
Per the welcome message you
Gary Smith:
I've been getting a lost of lost connection after DATA this last
week. On our low volume servers (that houses some minor clients)
we are receiving 800/day. We switched over to ipvsadm about 3
weeks ago and I though maybe it's because of non-persistent
connections. So I reset
connection
established from sender[senderip]: TLSv1 with cipher RC4-SHA (128/128 bits)
May 13 18:48:37 host01 postfix/smtpd[18110]: B30AAAFE4F: sender[senderip]]
May 13 18:48:42 host01 postfix/smtpd[18110]: lost connection after DATA
(1723601 bytes) from sender[senderip]
May 13 18:48:42 host01 postfix
Weitse,
For some reason, random mails from you pop up in my inbox, instead of my
postfix list instead delivery on behalf of postfix-users@postfix.org like most
others. Just an FYI
If the NAT assumes that everything is a web client and drops
connections after a few seconds, then Postfix
On Fri, May 14, 2010 at 09:23:12AM -0700, Gary Smith wrote:
I'm sure it's not a probable with postfix, I'm just looking for postfix
cases where they have overcome this type of config issue.
Have you disabled window scaling on your Postfix server. Lost connections
are often the result of
Have you disabled window scaling on your Postfix server. Lost connections
are often the result of firewalls mangling advanced TCP features.
- Disable window scaling
- Disable ECN
I don't believe we have disabled any of the advanced features. That will give
me something to do
Gary Smith:
If the NAT assumes that everything is a web client and drops
connections after a few seconds, then Postfix will report lost
connections.
If the NAT keeps connections open but it is a crappy box that can
maintain state for only 100 connections, then it will be forced to
with cipher RC4-SHA (128/128 bits)
May 13 18:48:37 host01 postfix/smtpd[18110]: B30AAAFE4F: sender[senderip]]
May 13 18:48:42 host01 postfix/smtpd[18110]: lost connection after DATA
(1723601 bytes) from sender[senderip]
This strongly suggests that you have is a 10 second time limit
on the life
, that a good percentage of
the connections were unknown. I might be able to write off a number of these
as being spammers with bad implementations for disconnect. So I might be
chasing a partial ghost.
May 13 04:08:33 host01 postfix/smtpd[10912]: lost connection after DATA from
unknown
On Fri, May 14, 2010 at 11:20:47AM -0700, Gary Smith wrote:
May 13 04:08:33 host01 postfix/smtpd[10912]: lost connection after DATA from
unknown[82.178.110.201]
Listed on SpamHaus XBL and PBL
May 13 04:08:34 host01 postfix/smtpd[10409]: lost connection after RCPT from
unknown
May 13 04:09:23 host01 postfix/smtpd[10301]: lost connection after RCPT from
unknown[190.107.112.194]
Listed on SpamHaus XBL
Unless these listings postdate your log entries, you should probably
not allow these clients to get as far as DATA.
reject_rbl_client zen.spamhaus.org
I've been getting a lost of lost connection after DATA this last week. On
our low volume servers (that houses some minor clients) we are receiving
800/day. We switched over to ipvsadm about 3 weeks ago and I though maybe it's
because of non-persistent connections. So I reset ipvsadm
67 matches
Mail list logo
