> On Sep 22, 2016, at 3:40 PM, Joseph Thibeault wrote:
>
> Ah sorry. Pardon my inexperience. Do you have an example of how to ensure
> that it contains a single smtp session? When I record I just specify eth0
> which grabs everything.
1. Start the capture on the correct interface before (re-)
Joseph Thibeault:
> Ah sorry. Pardon my inexperience. Do you have an example of how to ensure
> that it contains a single smtp session? When I record I just specify eth0
> which grabs everything.
As mentioned in my earlier reply,
http://www.postfix.org/DEBUG_README.html
Please review a captured s
Ah sorry. Pardon my inexperience. Do you have an example of how to ensure
that it contains a single smtp session? When I record I just specify eth0
which grabs everything.
On Thu, Sep 22, 2016 at 3:24 PM Viktor Dukhovni
wrote:
>
> > On Sep 22, 2016, at 3:07 PM, Joseph Thibeault wrote:
> >
> > h
> On Sep 22, 2016, at 3:07 PM, Joseph Thibeault wrote:
>
> https://dl.dropboxusercontent.com/u/3432879/postfixdump.zip
That PCAP file contains no SMTP sessions. Send a PCAP file
containing a single problem SMTP session.
--
Viktor.
; > We use postfix as a mail queue / sending service in one of our
>> > applications. This application generates emails with PDF attachments.
>> Some
>> > of the emails with PDFs get sent fine, but others seem to cause a
>> "timeout
>> > after DATA" error.
&g
Joseph Thibeault:
> We use postfix as a mail queue / sending service in one of our
> applications. This application generates emails with PDF attachments. Some
> of the emails with PDFs get sent fine, but others seem to cause a "timeout
> after DATA" error.
>
> Throu
ervice in one of our
> applications. This application generates emails with PDF
> attachments. Some of the emails with PDFs get sent fine, but
> others seem to cause a "timeout after DATA" error.
> >
> > Through reading online, I've seen ans
ding service in one of our
> applications. This application generates emails with PDF attachments. Some
> of the emails with PDFs get sent fine, but others seem to cause a "timeout
> after DATA" error.
> >
> > Through reading online, I've seen answers such as adjusting the
rates emails with PDF attachments. Some of the emails
> with PDFs get sent fine, but others seem to cause a "timeout after DATA"
> error.
>
> Through reading online, I've seen answers such as adjusting the MTU size on
> the network interface, etc. None of these sol
We use postfix as a mail queue / sending service in one of our
applications. This application generates emails with PDF attachments. Some
of the emails with PDFs get sent fine, but others seem to cause a "timeout
after DATA" error.
Through reading online, I've seen answers such a
Hello,
We start to see this error in a specific IP:
"Timeout after DATA (0 bytes) from unknown[x.x.x.x]"
Looking for in the web, we found many people talking about MTU problem.
Do you have seen this problem?
There is a configuration in postfix that I need to do?
Thanks in advance
Luiz
On 09/18/2014 05:40 PM, Wietse Venema wrote:
Giuseppe De Nicolo':
136.233724 212.19.117.109 217.72.32.234 SMTP131 S:
250 2.1.0 Ok | 250 2.1.5 Ok | 354 End data with .
136.441076 212.19.117.109 217.72.32.234 SMTP131 [TCP
Retransmission] S: 250 2.1.
Wietse Venema:
> Giuseppe De Nicolo':
> > On 09/18/2014 05:40 PM, Wietse Venema wrote:
> > > Giuseppe De Nicolo':
> > >
> > >> 136.231890 217.72.32.234 212.19.117.109 SMTP227 C:
> > >> MAIL FROM: SIZE=2857 |
> > >> RCPT TO:
> > >> ORCPT=rfc822;giulio.digior...@oapointgroup.it | D
Giuseppe De Nicolo':
> On 09/18/2014 05:40 PM, Wietse Venema wrote:
> > Giuseppe De Nicolo':
> >
> >> 136.231890 217.72.32.234 212.19.117.109 SMTP227 C:
> >>MAIL FROM: SIZE=2857 |
> >>RCPT TO:
> >>ORCPT=rfc822;giulio.digior...@oapointgroup.it | DATA
> >> 136.233724
On 09/18/2014 05:40 PM, Wietse Venema wrote:
Giuseppe De Nicolo':
136.233724 212.19.117.109 217.72.32.234 SMTP131 S:
250 2.1.0 Ok | 250 2.1.5 Ok | 354 End data with .
136.441076 212.19.117.109 217.72.32.234 SMTP131 [TCP
Retransmission] S: 250 2.1.
Giuseppe De Nicolo':
> 136.233724 212.19.117.109 217.72.32.234 SMTP131 S:
> 250 2.1.0 Ok | 250 2.1.5 Ok | 354 End data with .
> 136.441076 212.19.117.109 217.72.32.234 SMTP131 [TCP
> Retransmission] S: 250 2.1.0 Ok | 250 2.1.5 Ok | 354 End data with
>
Hello all,
Lately one of my users reported to me that he was missing some
message that he was waiting didn't get into his mailbox , so I went I
checked and this is what I found out :
http://pastebin.com/HPmaGqaJ
I 've decided to contact the support staff of the sender MTA and
ask th
Quoting Alex :
Hi,
I have a few postfix-2.8.7 systems on fedora15 that connect with
another postfix-2.8.7 system. I'm receiving the following messages
periodically in the logs:
Apr 24 16:24:43 mailrelay postfix/smtpd[8814]: timeout after DATA
(9832 bytes) from mail02.example.com[68.XX
Alex:
> Hi,
>
> >> I have a few postfix-2.8.7 systems on fedora15 that connect with
> >> another postfix-2.8.7 system. I'm receiving the following messages
> >> periodically in the logs:
> >>
> >> Apr 24 16:24:43 mailrelay postfix/smtpd
Hi,
>> I have a few postfix-2.8.7 systems on fedora15 that connect with
>> another postfix-2.8.7 system. I'm receiving the following messages
>> periodically in the logs:
>>
>> Apr 24 16:24:43 mailrelay postfix/smtpd[8814]: timeout after DATA
>> (9832 byt
Alex:
[ Charset ISO-8859-1 unsupported, converting... ]
> Hi,
>
> I have a few postfix-2.8.7 systems on fedora15 that connect with
> another postfix-2.8.7 system. I'm receiving the following messages
> periodically in the logs:
>
> Apr 24 16:24:43 mailrelay postfix/
Hi,
I have a few postfix-2.8.7 systems on fedora15 that connect with
another postfix-2.8.7 system. I'm receiving the following messages
periodically in the logs:
Apr 24 16:24:43 mailrelay postfix/smtpd[8814]: timeout after DATA
(9832 bytes) from mail02.example.com[68.XXX.YYY.45]
Apr 24 16:
Alexander Moisseev:
[ Charset KOI8-R unsupported, converting... ]
> 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:3
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 supp
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
Wietse Venema wrote:
> No. The client sends both RCPT TO and DATA in one TCP segment.
> This is legitimate use of the PIPELINING option (another feature
> that has troubled firewalls from people who can't be bothered to
> learn how protocols work).
Bah, that'll teach me to make assumptions. I did
Petr Janda:
> by the way postmaster@ wont work. we dont set them up as the email
> addresses are stored in ldap and its just a hassle to create an extra
> postmaster@ address for each domain we host. if you want maybe try
> [EMAIL PROTECTED]
You must provide a postmaster address,as required by Int
Barney Desmond:
> * Noone's pointed out the your first packet capture also exhibits the
> same "missing data" problem. After the client sends RCPT TO and you
> respond with an Ok, the next thing it drops on the wire is "Received:
> from srv1.shoppingsquare.com.au" in frame 12. I'm not that confiden
DJ Lucas wrote:
This has been on by default in every piece of Cisco equipment that
I've messed with (admittedly not many), did you try and disable it yet?
Oops..I forgot to mention, on the newer models, the config item for the
'smtp fu**up protocol' is now /'inspect esmtp'...have no idea about
Barney Desmond wrote:
* Noone's pointed out the your first packet capture also exhibits the
same "missing data" problem. After the client sends RCPT TO and you
respond with an Ok, the next thing it drops on the wire is "Received:
from srv1.shoppingsquare.com.au" in frame 12. I'm not that confiden
I can't add much to the already-fairly-technical discussion so far, but
I do have a couple of thoughts.
* You mentioned being able to replace the Cisco router with another one.
Could you try a non-Cisco one? Some Cisco gear is infamous for silently
munging SMTP transactions in the name of "securit
by the way postmaster@ wont work. we dont set them up as the email
addresses are stored in ldap and its just a hassle to create an extra
postmaster@ address for each domain we host. if you want maybe try
[EMAIL PROTECTED]
Petr
On 11/16/08, Petr Janda <[EMAIL PROTECTED]> wrote:
>> Can you verify t
Petr Janda:
> > Can you verify that your machine really announces a MSS of 1460?
>
> Actually you caught me while tempering with the MTU, Ive had it set to
> 800 for testing and some of the lost mail started getting through, but
> with a setting this low IMAP authentication stopped working
> altog
> Can you verify that your machine really announces a MSS of 1460?
Actually you caught me while tempering with the MTU, Ive had it set to
800 for testing and some of the lost mail started getting through, but
with a setting this low IMAP authentication stopped working
altogether. Its back to 1500.
Wietse Venema:
> Petr Janda:
> > > If there is a traffic shaper at your end, it may replace your
> > > TCP stack's MSS=1460 announcement by something smaller, like 890.
> >
> > Could this also be caused by the ISP?
>
> Something is throwing away the first 7300 bytes of the email message.
>
> Dep
Petr Janda:
> > If there is a traffic shaper at your end, it may replace your
> > TCP stack's MSS=1460 announcement by something smaller, like 890.
>
> Could this also be caused by the ISP?
Something is throwing away the first 7300 bytes of the email message.
Depending on how pervasive this beha
> If there is a traffic shaper at your end, it may replace your
> TCP stack's MSS=1460 announcement by something smaller, like 890.
Could this also be caused by the ISP?
Petr
Petr Janda <[EMAIL PROTECTED]> wrote:
> > If there is a traffic shaper at your end, it may replace your
> > TCP stack's MSS=1460 announcement by something smaller, like 890.
>
> Could this also be caused by the ISP?
It could be caused by some router that sits and passes packets
between the send
Petr Janda:
> > Something is badly screwing up TCP, perhaps by throwing away packets
> > with flags that it does not like.
>
> A misconfigured firewall? Seems unlikely as this timeout problem
> really happens a lot. Im also going to have a look at the Cisco ADSL
> router, maybe try replacing it wi
> Something is badly screwing up TCP, perhaps by throwing away packets
> with flags that it does not like.
A misconfigured firewall? Seems unlikely as this timeout problem
really happens a lot. Im also going to have a look at the Cisco ADSL
router, maybe try replacing it with another one to make s
Petr Janda:
> Hello,
> Ive taken another tcpdump, this time with options: window scaling and
> SACK disabled.
>
> Please let me know what you think.
After Postfix replies with "354 End data with ."
the client sends something that appears to start in the middle of
an email message.
MsoNormal alig
Hello,
Ive taken another tcpdump, this time with options: window scaling and
SACK disabled.
Please let me know what you think.
Thanks,
Petr
postfix_dump2.tgz
Description: GNU Zip compressed data
> In the OPs packet dump, the window scale on the receiving system is 2^0,
> but the sending system uses 2^7. Not much we can do about that from the
> Postfix side...
>
So what is the problem here? Should they be same? What can be done
about this? I dont mean as in you but in general how can we ge
On Sat, Nov 15, 2008 at 01:01:24PM +1100, Petr Janda wrote:
> Welcome to more suggestions, before I result to the final working
> solution: force the stupid admins to allow ICMP traffic with a shotgun
> :)
I would have done that first... There is a reason why ICMP is part of
the IP protocol suite
der) recently and trying to find out whats going on seems to be beyond
> > > me.
> > >
> > > Basically a lot of email is lost with "timeout after DATA"
> > >
> > > For example:
> > > timeout after DATA (0 bytes) from mail.securep
> Until then, sysctl is your friend.
>
> *BSD: sysctl -w net.inet.tcp.sack.enable=0
> L*n*x: sysctl -w net.ipv4.tcp_sack=0 (and I suppose something
> equivalent if you use Linux IPv6 support).
>
> Wietse
Thanks for your suggestions, Ive had both SACK and Window Scaling
turned off for t
gt;
> > Basically a lot of email is lost with "timeout after DATA"
> >
> > For example:
> > timeout after DATA (0 bytes) from mail.securepay.com.au[203.89.212.166]
> >
> > . Supposedly the problem here is that the sending machine has got a firewall
>
On Sat, Nov 15, 2008 at 09:14:07AM +1100, Petr Janda wrote:
> Hi all,
> I have got reports about lost mail(not received, im the receiver not the
> sender) recently and trying to find out whats going on seems to be beyond me.
>
> Basically a lot of email is lost with "timeout
Hi all,
I have got reports about lost mail(not received, im the receiver not the
sender) recently and trying to find out whats going on seems to be beyond me.
Basically a lot of email is lost with "timeout after DATA"
For example:
timeout after DATA (0 bytes) from mail.secure
On Sat, Oct 11, 2008 at 02:31:12PM -0400, Sahil Tandon wrote:
> > Your server offers Window scaling (WS=3). Either the client's firewall or
> > yours is confused by window scaling. You may need to turn window scaling
> > off (it is a pity that many "new" TCP features are unusable in practice
> > d
Victor Duchovni <[EMAIL PROTECTED]> wrote:
> On Sat, Oct 11, 2008 at 11:03:37AM -0400, Sahil Tandon wrote:
>
> > Thank you and Viktor for your response. The sending MTA continues to
> > retry on an hourly basis. I ran tcpdump as per the DEBUG_README and
> > pasted one session capture (the outpu
On Sat, Oct 11, 2008 at 11:03:37AM -0400, Sahil Tandon wrote:
> Thank you and Viktor for your response. The sending MTA continues to
> retry on an hourly basis. I ran tcpdump as per the DEBUG_README and
> pasted one session capture (the output of tshark -n -r tcpdump_file) at
> the URL below. P
Wietse Venema <[EMAIL PROTECTED]> wrote:
> > Oct 10 10:09:56 aegis postfix/smtpd[53022]: timeout after DATA (3240605
> > bytes) from relay.airtiger.com[63.170.171.120]
> > Oct 10 11:09:36 aegis postfix/smtpd[53463]: timeout after DATA (2998025
> > bytes) from rel
Sahil Tandon:
> This afternoon a user complained about missing email and mentioned that
> the sender "is not getting a bounce". In the logs I see several
> iterations of:
>
> Oct 10 09:51:42 aegis postfix/smtpd[52803]: timeout after DATA (256605 bytes)
> from relay
On Sat, Oct 11, 2008 at 12:04:22AM -0400, Sahil Tandon wrote:
> This afternoon a user complained about missing email and mentioned that
> the sender "is not getting a bounce". In the logs I see several
> iterations of:
>
> Oct 10 09:51:42 aegis postfix/smtpd[52803]: t
This afternoon a user complained about missing email and mentioned that
the sender "is not getting a bounce". In the logs I see several
iterations of:
Oct 10 09:51:42 aegis postfix/smtpd[52803]: timeout after DATA (256605 bytes)
from relay.airtiger.com[63.170.171.120]
Oct 10 10:0
57 matches
Mail list logo
