port question

[Tony Alfrey]

David A. Bandel wrote:
> On Sun, Aug 23, 2009 at 18:57, Tony Alfrey<tonyalfrey at earthlink.net> wrote:
>> David A. Bandel wrote:
>>
>>> I can't make this much clearer.
>> Yes, thanks, it is very clear! I'm just wondering about the actual packet of
>> bits that is assembled at each layer.  My understanding is that the port ID
>> is part of the bit stream that makes up the packet.  If this packet starts
>> out from ME where I (my mail client) put in an ID of port 587 into the
>> header that precedes the data bits, does an additional piece of header get
>> added (perhaps at the sending SMTP server end) with an ID of port 25 so that
>> it makes it to the receiving SMTP server?
> 
> The application, sendmail, only records the IP/hostname of the host to
> which it connects/connected to it and inserts that in the header.
> This is to identify where the message came from and the path it took
> to get where it got.  This is all outlined in the RFCs.  The ports in
> use are of no interest in determining where something came from.  Host
> 172.16.16.1 is host 172.16.16.1 no matter what ports were used for the
> communications, and BTW, TCP communications use two ports, not one.

Yes, I see that; one seems to be the "source port" and the "destination 
port" (which is perhaps where the port 587 from me and port 25 to e-mail 
come in)


> The commonly used port for e-mail is 25.  Has to be or e-mail servers
> couldn't find each other, so all e-mail servers bind port 25 so you
> can talk to them.

That seems very universal.

>  Mine also bind other ports (465 for SSL and 925 as
> an alternate).  Comcast blocks port 25 outgoing, but NOT incoming.  So
> you can receive mail all day, but not send or relay.

Frankly, I wish I didn't have to deal with comcast at all.

> 
> Get and use tcptraceroute to find what's blocked where.
> 
> David A. Bandel


Very Good!  Thank you!
Thanks to everyone!


-- 
Tony Alfrey
tonyalfrey at earthlink.net
"I'd Rather Be Sailing"