Dont know if this may assist, but here is another from St Vincent...lime
network. Sunday 19th sep. 2010
http://n1.netalyzr.icsi.berkeley.edu/summary/id=43ca253f-6714-b0f7e7b0-d08e-4729-b491#BufferResult
RD
http://n1.netalyzr.icsi.berkeley.edu/summary/id=43ca253f-6714-b0f7e7b0-d08e-4729-b491#BufferResult
wow! lime's buffering and 587 hacking make me like caribbean cable more
and more.
randy
I'm sure it's a lot better than our Afghanistan satellite systems (84%
uptime on two of them, 41% on the third). Luckily we load balance the
WAN ports so it's not *too* painful.
Jeff
Randy Bush <randy@psg.com> writes:
http://n1.netalyzr.icsi.berkeley.edu/summary/id=43ca253f-6714-b0f7e7b0-d08e-4729-b491#BufferResult
wow! lime's buffering and 587 hacking make me like caribbean cable more
and more.
hmm, 587 hacking, issue with configuration, or typo?
Direct TCP connections to remote authenticated SMTP servers (port 587)
succeed, but do not receive the expected content.
The applet received the following reply instead of our expected
header: "421 Cannot establish SSL with SMTP server 67.202.37.63:465,
SSL_connect error 336031996 "
"Cannot establish SSL with SMTP server 67.202.37.63:465" does not
sound like a 587 problem to me.
netalyzr folks? comment?
-r
Cisco PIX?
Sorry, I hit send too soon ...
I've heard from a couple of people that the PIX will remap 587 (and 25)
to oddball ports if you fiddle the config just right. Given all the
other bogosity that box does with SMTP I wonder if there's truth to the
rumour. (I haven't found anyone who can reproduce this on demand, so
it's still apocryphal for now.)
I've heard some people say that reproducing totally compliant SMTP behavior
on those boxes on demand is apocryphal as well. 
(I have to admit I haven't actually tracked a user complaint down to a
misbehaving PIX in a year or two, but I can't say if the software has gotten
better or if its market share is just small enough to fly under my radar - the
type of people who send e-mail from behind a PIX don't interact with my users
all that often)
From: Lyndon Nerenberg [mailto:lyndon@orthanc.ca]
Sent: Monday, September 27, 2010 9:30 AM
To: nanog@nanog.org
Subject: Re: Randy in Nevis> "Cannot establish SSL with SMTP server 67.202.37.63:465" does not
> sound like a 587 problem to me.
>
> netalyzr folks? comment?Sorry, I hit send too soon ...
I've heard from a couple of people that the PIX will remap 587 (and
25)
to oddball ports if you fiddle the config just right. Given all the
other bogosity that box does with SMTP I wonder if there's truth to
the
rumour. (I haven't found anyone who can reproduce this on demand, so
it's still apocryphal for now.)
Static (inside,outside) tcp <outside ip> 25 <inside ip> 65535
Access-list outside_acl permit tcp any any eq 25
No fixup smtp
That will redirect port 25 to port 65535, allow port 25 through the
firewall, and remove the fixup that changes the server banner to
*************, which breaks most mail communications.
Regards,
Mike
465 is not an odd-ball port, it's the standard well-known port for STMPS.
Fortunately, few people actually use SMTPS, preferring instead to do their
security via TLS using the STARTTLS model after connecting to 25/587.
Owen
[...]
465 is not an odd-ball port, it's the standard well-known port for STMPS.
It is? That's not what's recorded at: Service Name and Transport Protocol Port Number Registry
urd 465/tcp URL Rendesvous Directory for SSM
igmpv3lite 465/udp IGMP over UDP for SSM
Regards,
Leo
Microsoft frequently has different ideas about things.
~Seth
>> 465 is not an odd-ball port, it's the standard well-known port for STMPS.
>
> It is? That's not what's recorded at:
Service Name and Transport Protocol Port Number Registry
>
> urd 465/tcp URL Rendesvous Directory for SSM
> igmpv3lite 465/udp IGMP over UDP for SSM
>Microsoft frequently has different ideas about things.
~Seth
FWIW - 465 is widely deployed as SMTPS, in more than just MS products. I'm actually quite surprised it's not in the well known ports list.
Best Regards,
Nathan Eisenberg
It is on all Linux distros:
ssmtp 465/tcp smtps # SMTP over SSL
Whether recorded with IANA or not, it certainly is what you will find if you google:
smtp ssl port
It's also what just about every MUA and MTA I've seen expects for that purpose.
Owen
John Peach <john-nanog@johnpeach.com> writes:
It is on all Linux distros:
ssmtp 465/tcp smtps # SMTP over SSL
So file bug reports.
Bjørn
John Peach <john-nanog@johnpeach.com> writes:
> It is on all Linux distros:
>
> ssmtp 465/tcp smtps # SMTP over SSLSo file bug reports.
With IANA?
It's common knowledge that 465 is smtps, whatever else IANA might say.
I don't know the history of 465/tcp as an entry in the registry found at <<http://www.iana.org/assignments/port-numbers>, but assuming the current entry is there for a reason (and hence is not an error that might be corrected), I believe this is the workflow required to change it.
The port-number registry is maintained according to the directions in RFC 2780. To change an entry in the registry you need to write and submit an internet-draft <http://www.ietf.org/id-info/> which contains an IANA Considerations section specifying the change that is required. Those specifications will be executed (and the registry updated) if/when the I-D makes it through to that stage in the RFC publication process. RFC 2780 gives the following guidance for how such an I-D might reach that stage.
9.1 TCP Source and Destination Port fields
Both the Source and Destination Port fields use the same namespace.
Values in this namespace are assigned following a Specification
Required, Expert Review, IESG Approval, IETF Consensus, or Standards
Action process. Note that some assignments may involve non-
disclosure information.
Joe
http://www.ietf.org/rfc/rfc4409.txt
Here's what they've had to say over time:
http://web.archive.org/web/20010519080902/http://www.iana.org/assignments/port-numbers
Says it's "unassigned."
Then they assign it to "URL Rendezvous" a few months after that.
http://web.archive.org/web/20010813015738/http://www.iana.org/assignments/port-numbers
We currently support SMTP submission over 465 since there are still some old cranky Outlook versions out there that simply don't appear to be able to support connecting to 587, but it's been 18 months since we got a call like that, so we'll probably be shutting that off soon.
--Chris