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
>
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.XXX.YYY.4
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.examp
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]
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/smtpd[8814]: timeout after DATA
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:31:56 mx postfix/smt
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.mail.yan
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
On Fri, Nov 14, 2008 at 06:14:33PM -0500, Wietse Venema wrote:
> Victor Duchovni:
> > 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 go
> 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
Victor Duchovni:
> 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
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 after DATA"
>
> For
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 relay.airtiger.com[63.170.171.120]
>
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.airtiger.com[63.170.171.120]
>
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]: timeout after DATA (256605 by
41 matches
Mail list logo
