Phil Pennock wrote:
> On 2008-01-13 at 15:40 -0800, chuckee wrote:
>> I want to have Exim open on port 80 on my server (say, myserver.com),
>> however I also have a website that needs to be visible (on port 80), at
>> least on www.myserver.com and also myserver.com if possible.
>>
>> I need Exim open on port 80 because many of my users are accessing Exim from
>> networks where port 80 is the only port that is open (e.g. airports).
>>
>> What would be the best way to do this? I don't want to have to have
>> port80.myserver.com as the server.
>
> Quite aside from the policy and other issues raised, technically you
> can't reliably do this.
>
> In HTTP the client sends first and an SMTP banner would be quite bad
> unexpected data. In SMTP, the server sends first, sending a banner, so
> the client waits until it sees something from the server.
>
> If SMTP clients sent first then you might have been able to do a clever
> protocol analysis hack in the web-server to pass things off to Exim, but
> they don't and so you can't.
>
Though I agree (from actual testing) that use of port 80 is a bad idea,
for smtp - the above does not apply in practice.
The MTA and the MUA both still 'know' they are using smtp protocol,
(indeed - have scant choice...) so whatever an httpd or browser would do
is not relevant to getting a working session established on whatever
choice of ports one chooses. It is not even a strict requirement that
one edits /etc/services UNLESS relying on inetd.
Not with Exim as MTA and either Mozilla suite or SeaMonkey suite or
Opera suite as MUA anyway - and all three of those are also browsers,
but 'confusethed not' the relevant protocols (did make cert installation
easier, though).
> The only other technical approaches would involve things like HTTP
> CONNECT and running special client software to set this up.
>
> If you have to provide service to people in such draconian environments
> and you're sure that you won't be an accessory to anything like managing
> to leak customer data out of a corporation, then you'd be better off
> looking to the future, when you need a second service outbound, and
> instead use SSH on port 80 with a port-forwarding service and use the
> existing SSH tunnelling tools which already exist.
>
> -Phil
>
>
That works. And with 'stunnel' is easily left up with an abitrary port
at *either* end. Used for years before some of our client's Win-based
MUA were SSL/TLS capable.
