>Not too many days later I noticed that I was not able to send any e-mail
>to a select few sites if it was over ~1KB (i.e. if it caused a
>fragmented packet).  I contacted a few of the admins of the sites in
>question, and was contacted by at least one who had noticed my system's
>failing SMTP connects.  Various experiments proved that it was not
>Path-MTU-discovery or firewalls on their end causing any problems, and
>indeed tcpdumps on my router showed that my system was simply getting
>stuck retranmitting the larger packets without getting any kind of
>response from anyone at all.

	i experienced a similar symptom.  not sure if it is the same
	as the problem you are having.

	it was under the following configuration,

	destination (always do path MTU discovery)
	  | MTU == 1500
	router 2
	  | MTU < 1500 due to some VLAN
	router 1
	  | MTU == 1500
	source (netbsd 1.4.2)

	and the symptom was:
	- if the source node use path MTU discovery, TCP between source and
	  destination goes fine
	- if the source node turns off path MTU discovery (which was the
	  default setting on 1.4.2), source node keep retransmitting large
	  packet

	in my case, i had enough access to the intermediate router (as it
	was laboratory setting).

	router 1 was broken from DF bit manipulation.  it behaved like this:
	- if DF bit is raised on a packet, it worked fine.  it transmits
	  icmp "too big" as necessary toward source, if the source node sends
	  1500byte-packets.
	- if DF bit is off, it behaved wrong.  if the source node sends
	  1500byte-packets, it drops the packet onto the floor.  router 1
	  should have fragmented the packet on its own and relay it to router 2
	  (VLAN side), but it did not.

	i guess there is some broken device, somewhere between you and the
	destination.  i'm not sure if turning path MTU discovery on
	always helps, as there are stupid admins who filters out all icmp
	packets at their firewall (and preventing path MTU discovery from
	working).

itojun