MySQL Student:
> Hi,
>
> >> > Ah, found it. ?The problem is you've got the Postfix host relaying mail
> >> > to itself. ?It's right in your log entries:
> >> >
> >> > to=<[email protected]>, relay=127.0.0.1[127.0.0.1]
> >>
> >> Yes, my apologies; as Sahil said, I'm using amavisd-new, although there is
> >> no longer spam and virus scanning happening on this host.
> >>
> >> The message is just getting requeued back to the second queue.
> >
> > Have you already looked at a tcpdump recording as requested?
>
> I will try and investigate that today. Can anyone recommend a
> front-end to make browsing
> through the output easier? Is it ethereal/ettercap/wireshark that I
> should be using?
>
> Can you recommend how I can isolate the output to a specific message? Perhaps
> by
> process ID or the ability to somehow track the queue ID?
Postfix logs the approximate time of failed transactions. Use
that information to narrow down the search.
You need to look at the TCP-level features (stuff negotiated during
the initial handshake, and the behavior of acks and windows during
message delivery).
Broken implementations of SACK and WSCALE have resulted in timeouts
during message delivery, but we have also seen "security" appliances
that simply drop packets with flags that they did not understand.
Wietse
