From: Lee Quince (Lee.Quinceiqunity.com)
Date: Tue May 13 2008 - 10:48:12 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

O'well you all seem to miss the business side of it..

Sometimes its not about what we want but what our customers ask for.!
i.e in this case a hotel.

I agree not best practice, but when you have a screaming executive at
3am on the support phone who cannot understand where the power button is
"i normally shut the lid" then you may understand..

We will have 10,000 smtp redirect's of legitimate email everyday.. then
there will be the 4 users that have paid 500.00 for a room and they
cannot send email on the free wifi service. What is the smaller pain?

As for the comment about who's protects the user? Well it would have to
be the box the laptop came in. Really is that our problem, we don't host
there email just provide a mechanism to send. The least we need the user
to change the better.

Regards

Lee

-----Original Message-----
From: Noel Jones [mailto:njonesmegan.vbhcs.org]
Sent: 13 May 2008 16:23
To: postfix-userspostfix.org
Cc: Lee Quince
Subject: Re: Allow all types of Relay for a Hotspot Provider..

Jorey Bump wrote:
> Lee Quince wrote, at 05/13/2008 04:55 AM:
>
>> Ok say your ISP is force9.net, your staying in a hotel and you want
to
>> send email without changing your SMTP setting's. force9 servers will
>> only allow a relay for there connected network. Hence while you are
in
>> the hotel and using our network relay is denied. To get around this
we
>> basically redirect port 25 TCP using NAT to our postfix server's, (we

>> do some grey listing and max messages, per min, ClamAV etc to
protect
>> ourselves.)
>
> Who's protecting the user?
>
>> The problem we have is if the client's ISP normally allows there
>> customer to send via there SMTP server on port 25 TCP (the one
located
>> at the ISP) using SMTP with AUTH, this could be plain, cleartext or
>> TLS.. We are redirecting the traffic already to ourselves.. So I need

>> to if possible ignore the AUTH from the client on our network and
>> allow relay.
>
> So, you're intercepting an authenticated connection without the user's

> permission and attempting to complete it successfully without the
user's
> knowledge. This is evil. You're now in a position to sniff unencrypted

> passwords (which are foolish, but still...). Why should the user trust

> anyone on your network? If you want to block outgoing connections to
> port 25, that's perfectly justifiable. Users can use alternative ports

> (submission on port 587) or webmail to securely send mail without
> creating a liability for your network. But don't kid yourself that
> you're offering a service by hijacking their connections. What you
> propose is bad practice and simply wrong. Besides, it won't work for
> encrypted AUTH, anyway.
>
> By the way, this could also turn you into a major backscatter source
if
> you accept the message and bounce it after you can't relay it or it
> fails some of your checks. What you propose isn't good for your users
or
> your network.
>
>

I agree with Jorey 100%. You're not doing anyone any good
with a setup like you propose.

If you want to provide mail relay service as a courtesy to
your hotspot customers, post instructions on your web portal
(or on the wall nearby!) with your server's IP address.

Block outbound connections to port 25 so your hotspot can't be
used for direct spamming, encourage users to connect to their
own servers on 587 or use their own webmail.

Redirecting user connections (I would call it hijacking) might
sound like a nice idea to the marketing guys, but it's not
good for anybody. Unless your real objective is to sniff
passwords and intercept private mail...

--
Noel Jones

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]