Allow all types of Relay for a Hotspot Provider..

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Allow all types of Relay for a Hotspot Provider..

Lee Quince
Hi,

I am looking to do the following..

Be able to relay on the Basis of LocalNetwork as the sole accept.

This is the problem

I need to relay for customers who also have a existing setting for Outbound Auth SMTP in there client, i.e Outlook with the tick in the server required authentication.

For none authorised SMTP client's we just redirect port 25 at the firewall level to the postfix server, this then causes a problem with the AUTH'd clients as the server does not know the username / password they are trying to use.. Is there a way to get the server to accept any combination..??

If not is this something sendmail or Exim can do?

Regards
--

Lee Quince

Internet Email Confidentiality Notice:
This message contains confidential information. If you are not the addressee indicated in this message, you may not copy or deliver it to anyone. In such case, you should destroy this message and kindly notify us by reply email


Reply | Threaded
Open this post in threaded view
|

Re: Allow all types of Relay for a Hotspot Provider..

Stefan Förster-4
* Lee Quince <[hidden email]> wrote:
> I am looking to do the following..
>
> Be able to relay on the Basis of LocalNetwork as the sole accept.

You can set mynetworks to an appropriate setting and then use the
"permit_mynetworks" restriction in smptd_recipient_restrictions.


> For none authorised SMTP client's we just redirect port 25 at the
> firewall level to the postfix server, this then causes a problem with
> the AUTH'd clients as the server does not know the username / password
> they are trying to use.. Is there a way to get the server to accept any
> combination..??

Your firewall can intercept encrypted traffic and reroute it? I don't
understand what you are trying to accomplish.


Cheers
Stefan
Reply | Threaded
Open this post in threaded view
|

Re: Allow all types of Relay for a Hotspot Provider..

Lee Quince


Stefan Förster wrote:
* Lee Quince [hidden email] wrote:
  
I am looking to do the following..

Be able to relay on the Basis of LocalNetwork as the sole accept.
    

You can set mynetworks to an appropriate setting and then use the
"permit_mynetworks" restriction in smptd_recipient_restrictions.


  
No problem here I understand this part.

  
For none authorised SMTP client's we just redirect port 25 at the 
firewall level to the postfix server, this then causes a problem with 
the AUTH'd clients as the server does not know the username / password 
they are trying to use.. Is there a way to get the server to accept any 
combination..??
    

Your firewall can intercept encrypted traffic and reroute it? I don't
understand what you are trying to accomplish.
  
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.)

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.

Regards

Lee

Cheers
Stefan
  

--

Lee Quince
Managing Technical Director
iQunity Ltd
Undivided Attention
mobile: 07970 070 806
fax: 08703 835 661

Internet Email Confidentiality Notice:
This message contains confidential information. If you are not the addressee indicated in this message, you may not copy or deliver it to anyone. In such case, you should destroy this message and kindly notify us by reply email


Reply | Threaded
Open this post in threaded view
|

Re: Allow all types of Relay for a Hotspot Provider..

Stefan Förster-4
* Lee Quince <[hidden email]> wrote:

> Stefan Förster wrote:
> >Your firewall can intercept encrypted traffic and reroute it? I don't
> >understand what you are trying to accomplish.
> >  
> 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.)
>
> 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.

Can you redirect to a dedicated server which doesn't offer AUTH? I'm
not sure if this is a good thing to do - if anyone manages to break
into that hotels (W)LAN he or she might easily turn your server into a
spam source.


Cheers
Stefan
Reply | Threaded
Open this post in threaded view
|

Re: Allow all types of Relay for a Hotspot Provider..

Charles Marcus
In reply to this post by Lee Quince
On 5/13/2008, Lee Quince ([hidden email]) wrote:
> 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.)

This is precisely what the submission port (587) is for.

Just have everyone use that, and everything will 'just work' (as long as
the hotspot provider isn't brain dead and blocks outbound port 587
connections)...

--

Best regards,

Charles
Reply | Threaded
Open this post in threaded view
|

Re: Allow all types of Relay for a Hotspot Provider..

Jorey Bump
In reply to this post by Lee Quince
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.


Reply | Threaded
Open this post in threaded view
|

Re: Allow all types of Relay for a Hotspot Provider..

Walter Heukels
In reply to this post by Lee Quince
> I need to relay for customers who also have a existing setting for
> Outbound Auth SMTP in there client, i.e Outlook with the tick in the
> server required authentication.

My company does this for a hotspot provider; the way I solved it is to
allow relaying for authenticated connections, and make sure the
authentication always succeeds.  I configured saslauthd to use PAM and
used pam_permit.so for the SMTP service.  You'll want to look up SASL and
PAM documentation for this.

I guarantee you will get people sending viruses and spam from infected
laptops.  I implemented virus scanning and rate limiting to combat this,
which is working fine so far.

Walter


Reply | Threaded
Open this post in threaded view
|

Re: Allow all types of Relay for a Hotspot Provider..

Noel Jones-2
In reply to this post by Jorey Bump
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
Reply | Threaded
Open this post in threaded view
|

RE: Allow all types of Relay for a Hotspot Provider..

Lee Quince
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:[hidden email]]
Sent: 13 May 2008 16:23
To: [hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: Allow all types of Relay for a Hotspot Provider..

Jorey Bump
Lee Quince wrote, at 05/13/2008 11:48 AM:

> 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.

Then don't block or attempt to proxy port 25. They don't need you to
supply an MTA in order to send email. They already have an email
provider, as you point out. Why interfere at all, if you don't want the
headache?


Reply | Threaded
Open this post in threaded view
|

Re: Allow all types of Relay for a Hotspot Provider..

Mark Goodge
Jorey Bump wrote:

> Lee Quince wrote, at 05/13/2008 11:48 AM:
>> 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.
>
> Then don't block or attempt to proxy port 25. They don't need you to
> supply an MTA in order to send email. They already have an email
> provider, as you point out. Why interfere at all, if you don't want the
> headache?

Because among the users sending mail via his wireless network will be
those with infected computers, or worse. Since he has no ability to do
anything about this after the event (since any customer with a spamming
PC will have left the hotel by the time the complaints start coming in),
  the only way he can both protect himself and act as a responsible
netizen is to proxy port 25 and filter outbound traffic to ensure that
none of it is spam/viruses/etc.

It is the responsibility of any network operator to take reasonable
steps to reduce the probability of his network being used for spam and
virus dissemination. Where the users of that network form a transient
and rapidly changing population, over whom the network operator has no
direct control, then the most practical solution is to implement
network-level controls which will serve to block the majority of any
illegitimate outbound traffic.

Since this means not allowing unrestricted outbound traffic on port 25,
the next question is how best to allow customers to send mail at all.
Given that the majority of them will be non-technical users who expect
to simply be able to switch on their laptop and send mail, without
needing to reconfigure it in any way in order to do so (and, if it's a
locked-down company-owned machine subject to the restrictions of their
own IT department, may well not have the ability to change the settings
even if they knew how). Again, the most practical solution is to
intercept outbound traffic on port 25 and act as a transparent proxy so
that the customer can send mail whatever the settings on their computer.
This is a solution commonly used by wireless hotspot providers (and even
some consumer ISPs), so it's not as if the OP here is asking for
anything obscure or unreasonable. In fact, it's so common that I'm
surprised some of the respondents in this thread seem to be unaware of it!

The real problem is that some of his customers will be using
authenticated SMTP on port 25. That's wrong, by a strict reading of the
relevant RFCs - if they're using authenticated SMTP, they should be
using port 587, which is intended for authenticated SMTP, rather than
port 25, which is for anonymous SMTP. So a technically correct response
would be to leave port 587 open, proxy anonymous SMTP on port 25 and let
users who are incorrectly trying to authenticate on port 25 suffer the
consequences. But the technically correct response isn't always the best
business response, especially when your customers are paying to use your
facilities and, if they find them unusable, will simply go elsewhere.
Again, it has to be borne in mind that the actual user may well not be
responsible for their own incorrect configuration - it may be a
requirement of their own IT department or ISP.

What the OP appears to be looking for is a solution to the problem of
users trying to authenticate on a port that they should not authenticate
on, in order to allow them to send mail anyway. If the answer is "It
can't be done with Postfix", then fine - that's an appropriate answer on
this list (although I'm pretty sure it's the wrong one). But telling him
that he shouldn't be doing that isn't an appropriate answer, because
this isn't a list for discussing best business practice for wireless
hotspot operators, it's a list for getting practical help with using
Postfix. Advice which addresses the technical issue is more likely to be
helpful than advice which attempts to address the marketing issues.

Mark
Reply | Threaded
Open this post in threaded view
|

RE: Allow all types of Relay for a Hotspot Provider..

Lee Quince
In reply to this post by Jorey Bump
Jorey,

Still missing the point...

Most ISP's still only allow you to relay when connected to one of there
own connection's.

95% of users still use unauthenticated SMTP.

5% of users use authenticated SMTP.

Hence lets reduce the bigger problem. "What the Customer wants"

Regards

Lee

-----Original Message-----
From: Jorey Bump [mailto:[hidden email]]
Sent: 13 May 2008 16:51
To: Lee Quince
Cc: postfix users list
Subject: Re: Allow all types of Relay for a Hotspot Provider..

Lee Quince wrote, at 05/13/2008 11:48 AM:
> 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.

Then don't block or attempt to proxy port 25. They don't need you to
supply an MTA in order to send email. They already have an email
provider, as you point out. Why interfere at all, if you don't want the
headache?


Reply | Threaded
Open this post in threaded view
|

Re: Allow all types of Relay for a Hotspot Provider..

Blake Hudson
In reply to this post by Walter Heukels
-------- Original Message  --------
Subject: Re: Allow all types of Relay for a Hotspot Provider..
From: Walter Heukels [hidden email]
To: [hidden email]
Date: Tuesday, May 13, 2008 9:15:48 AM
I need to relay for customers who also have a existing setting for
Outbound Auth SMTP in there client, i.e Outlook with the tick in the
server required authentication.
    

My company does this for a hotspot provider; the way I solved it is to
allow relaying for authenticated connections, and make sure the
authentication always succeeds.  I configured saslauthd to use PAM and
used pam_permit.so for the SMTP service.  You'll want to look up SASL and
PAM documentation for this.

I guarantee you will get people sending viruses and spam from infected
laptops.  I implemented virus scanning and rate limiting to combat this,
which is working fine so far.

Walter


  
Initially, accepting all auth requests seemed the best idea to me as well. The method above is a good method of accomplishing this. However, then I remembered a time when an SMTP 'firewall' (much like a PIX) was blocking certain ESMTP commands/responses between a client and our server. It turns out that even if the client is configured for SMTP authentication, it will not even attempt to authenticate if the server does not respond to an ehlo/helo with "250-AUTH".

This was true of Eudora, OE, and thunderbird as of a few years ago, and I wouldn't doubt if it still holds true. So, if your server does not offer up to support authentication, then the majority (statistically all) will likely work just fine, happily bypassing the authentication process. Personally, I would prefer not intercepting usernames/passwords or even having them sent unencrypted on my network if avoidable.

--Blake
Reply | Threaded
Open this post in threaded view
|

Re: Allow all types of Relay for a Hotspot Provider..

Jorey Bump
In reply to this post by Mark Goodge
Mark Goodge wrote, at 05/13/2008 12:30 PM:

> Because among the users sending mail via his wireless network will be
> those with infected computers, or worse. Since he has no ability to do
> anything about this after the event (since any customer with a spamming
> PC will have left the hotel by the time the complaints start coming in),
>  the only way he can both protect himself and act as a responsible
> netizen is to proxy port 25 and filter outbound traffic to ensure that
> none of it is spam/viruses/etc.

He can block port 25, and leave it at that.

> It is the responsibility of any network operator to take reasonable
> steps to reduce the probability of his network being used for spam and
> virus dissemination.

Agreed.

> Again, the most practical solution is to
> intercept outbound traffic on port 25 and act as a transparent proxy so
> that the customer can send mail whatever the settings on their computer.
> This is a solution commonly used by wireless hotspot providers (and even
> some consumer ISPs), so it's not as if the OP here is asking for
> anything obscure or unreasonable. In fact, it's so common that I'm
> surprised some of the respondents in this thread seem to be unaware of it!

We're all *too* aware of the practice, as we're often left dealing with
the consequences.

> So a technically correct response
> would be to leave port 587 open,

Yes.

> proxy anonymous SMTP on port 25

No!

> and let
> users who are incorrectly trying to authenticate on port 25 suffer the
> consequences. But the technically correct response isn't always the best
> business response, especially when your customers are paying to use your
> facilities and, if they find them unusable, will simply go elsewhere.
> Again, it has to be borne in mind that the actual user may well not be
> responsible for their own incorrect configuration - it may be a
> requirement of their own IT department or ISP.

Precisely. Maybe a user has been authenticating on port 25 with STARTTLS
enabled. It may stop working in a hotspot, but at least it's still
secure. The last thing we need is a hotel clerk telling a user to
"disable TLS, our super smart proxy will send the mail for you!"

> What the OP appears to be looking for is a solution to the problem of
> users trying to authenticate on a port that they should not authenticate
> on, in order to allow them to send mail anyway. If the answer is "It
> can't be done with Postfix", then fine - that's an appropriate answer on
> this list (although I'm pretty sure it's the wrong one). But telling him
> that he shouldn't be doing that isn't an appropriate answer, because
> this isn't a list for discussing best business practice for wireless
> hotspot operators, it's a list for getting practical help with using
> Postfix. Advice which addresses the technical issue is more likely to be
> helpful than advice which attempts to address the marketing issues.

The OP is trying to reduce outgoing spam from his hotspot, which is
laudible, but wants to overcome the resulting issues by intercepting or
replaying user login credentials, which is completely unacceptable (and
impossible, in the case of encrypted connections). Blocking outgoing
connections to port 25 is an acceptable, if imperfect, solution. But
hijacking the connection can create a multitude of problems for everyone:

- User login credentials may be exposed.

- Nontechnical users may be encouraged to alter mail client settings to
an insecure configuration.

- The hotspot IP may become blacklisted, causing messages to bounce that
wouldn't have if the sender's relay had been used.

- SPF (or other sender/domain authentication) checks may cause the
message to bounce, if it appears to originate from the hotspot IP
address instead of an approved server for that domain.

- A hotspot's poorly implemented SMTP proxy could be a significant
source of backscatter. I wouldn't be surprised if this explains the
recent surge. In this case, we would all be better off if the hotspot
merely blocked port 25. Backscatter from spam with forged sender
addresses can ruin a legitimate account.

Current best practice suggests blocking (not proxying) outgoing
connections to port 25 to stop spam. This will allow users to use port
587 or webmail, if either is provided by the email service provider.
Tampering with the connection via a proxy is not likely to be a good
business decision, considering the potential problems. It isn't a good
technical solution, either.


Reply | Threaded
Open this post in threaded view
|

Re: Allow all types of Relay for a Hotspot Provider..

Jorey Bump
In reply to this post by Lee Quince
Lee Quince wrote, at 05/13/2008 12:56 PM:
> Jorey,
>
> Still missing the point...
>
> Most ISP's still only allow you to relay when connected to one of there
> own connection's.

It's true that ISPs are blocking outgoing connections to port 25, if it
isn't to one of their submission servers, but they are also implementing
port 587 submission or offering webmail to get around the blocks imposed
by other ISPs or hotspots when users are on another network. It's a
necessary evil, but also a good thing, considering the number of zombies
out there.

> 95% of users still use unauthenticated SMTP.

Well, maybe, but 98% of those are zombies. :)

> 5% of users use authenticated SMTP.

Real users authenticate. :)

> Hence lets reduce the bigger problem. "What the Customer wants"

Again, if that's your only concern, don't block port 25. However, I
agree that you should do the responsible thing and block outgoing
connections to port 25, so the rest of us don't have to deal with spam
from zombies that connect to your hotspot. It's good that you're doing
this. It may cause problems for users that authenticate over port 25,
but there are solutions that don't require you to sniff login
credentials, break encryption, or relay mail for anyone connected to
your network. In fact, it's really not your problem anymore. Inform your
users that you block port 25 and that they should contact their own
technical support if this interferes with their ability to send email.


Reply | Threaded
Open this post in threaded view
|

Re: Allow all types of Relay for a Hotspot Provider..

mouss-2
In reply to this post by Mark Goodge
Mark Goodge wrote:
>
> Because among the users sending mail via his wireless network will be
> those with infected computers, or worse. Since he has no ability to do
> anything about this after the event (since any customer with a
> spamming PC will have left the hotel by the time the complaints start
> coming in),  the only way he can both protect himself and act as a
> responsible netizen is to proxy port 25 and filter outbound traffic to
> ensure that none of it is spam/viruses/etc.

redirecting traffic without the authorization of the user has a name:
hijacking.

I don't know for you, but if my lane goes to Egypt instead of Tunisia
because someone decided that the wheather is better there, I know what I
will do.


>
> It is the responsibility of any network operator to take reasonable
> steps to reduce the probability of his network being used for spam and
> virus dissemination.

of course. but tracking criminals never meant annoying honest people,
except in dictatorial governments.

> Where the users of that network form a transient and rapidly changing
> population, over whom the network operator has no direct control, then
> the most practical solution is to implement network-level controls
> which will serve to block the majority of any illegitimate outbound
> traffic.


Not at all. If I pay for a service, I want that service. the fact that
my neighbourghs are criminals changes nothing.

>
> Since this means not allowing unrestricted outbound traffic on port
> 25, the next question is how best to allow customers to send mail at
> all. Given that the majority of them will be non-technical users who
> expect to simply be able to switch on their laptop and send mail,
> without needing to reconfigure it in any way in order to do so (and,
> if it's a locked-down company-owned machine subject to the
> restrictions of their own IT department, may well not have the ability
> to change the settings even if they knew how). Again, the most
> practical solution is to intercept outbound traffic on port 25 and act
> as a transparent proxy so that the customer can send mail whatever the
> settings on their computer. This is a solution commonly used by
> wireless hotspot providers (and even some consumer ISPs), so it's not
> as if the OP here is asking for anything obscure or unreasonable. In
> fact, it's so common that I'm surprised some of the respondents in
> this thread seem to be unaware of it!

oh no. while it is good practice to block port 25 (both out and in),
traffic hijacking is bad. if my wife's MUA gives her login:password to
an arbitrary sever, I consider that simply as an attack, even if the
problem is in the MUA. and I reserve my right to react to that, in any
form ;-p


oh please come on. it's like if SPs and providers were so secure that we
can count on them. a tcpdump shows many funny things, and experience
with SPs shows even more problems.

>
> The real problem is that some of his customers will be using
> authenticated SMTP on port 25. That's wrong, by a strict reading of
> the relevant RFCs - if they're using authenticated SMTP, they should
> be using port 587, which is intended for authenticated SMTP, rather
> than port 25, which is for anonymous SMTP.

while 587 is recommended, using port 25 for submission is more than
acceptable.

> So a technically correct response would be to leave port 587 open,
> proxy anonymous SMTP on port 25 and let users who are incorrectly
> trying to authenticate on port 25 suffer the consequences. But the
> technically correct response isn't always the best business response,
> especially when your customers are paying to use your facilities and,
> if they find them unusable, will simply go elsewhere. Again, it has to
> be borne in mind that the actual user may well not be responsible for
> their own incorrect configuration - it may be a requirement of their
> own IT department or ISP.


Blocking port 25 creates no problem, provided that the SP makes it easy
to override for those who want to send directly. for example, free.fr
allows customers to enable port 25 on their web UI (requires rebooting
the freebox, but this is not too much). the consequence is that most
people who don't know what this means will have the port blocked, which
is good.

>
> What the OP appears to be looking for is a solution to the problem of
> users trying to authenticate on a port that they should not
> authenticate on, in order to allow them to send mail anyway. If the
> answer is "It can't be done with Postfix", then fine - that's an
> appropriate answer on this list (although I'm pretty sure it's the
> wrong one). But telling him that he shouldn't be doing that isn't an
> appropriate answer, because this isn't a list for discussing best
> business practice for wireless hotspot operators, it's a list for
> getting practical help with using Postfix. Advice which addresses the
> technical issue is more likely to be helpful than advice which
> attempts to address the marketing issues.

I am sure OP can manage to do whatever he wants, but I confess that I do
not understand what he wants to do.

Reply | Threaded
Open this post in threaded view
|

Re: Allow all types of Relay for a Hotspot Provider..

mouss-2
In reply to this post by Lee Quince
Lee Quince wrote:

> Jorey,
>
> Still missing the point...
>
> Most ISP's still only allow you to relay when connected to one of there
> own connection's.
>
> 95% of users still use unauthenticated SMTP.
>
> 5% of users use authenticated SMTP.
>
> Hence lets reduce the bigger problem. "What the Customer wants"
>  

whatever the situation is, you have absolutely no authority to hijack
traffic. you can block port 25 (possibly with a reject text that you
hope will be understandable by the user). you can block all traffic if
you want. but you should not redirect traffic. if my client connects to
a server and this server claims to be foo.example.com when it is not,
there are names for that: lies, hijacking, attack, ... etc. Networks
that act this way have chosen to get out of honest practice (if not out
of law) and should be attacked until they get down (I am only half joking).

Reply | Threaded
Open this post in threaded view
|

Re: Allow all types of Relay for a Hotspot Provider..

Charles Marcus
On 5/13/2008, mouss ([hidden email]) wrote:
> whatever the situation is, you have absolutely no authority to hijack
> traffic.

In fact, I'd go so far as to say that if you do this, you are opening
yourself up to a major lawsuit... I know *I* would sue a hotel if I
found out they were doing this... what with Identity theft (and the
consequences if you happen to be a victim of it) being the major problem
 that it is.

--

Best regards,

Charles
Reply | Threaded
Open this post in threaded view
|

Re: Allow all types of Relay for a Hotspot Provider..

Wietse Venema
In reply to this post by mouss-2
mouss:

> Mark Goodge wrote:
> >
> > Because among the users sending mail via his wireless network will be
> > those with infected computers, or worse. Since he has no ability to do
> > anything about this after the event (since any customer with a
> > spamming PC will have left the hotel by the time the complaints start
> > coming in),  the only way he can both protect himself and act as a
> > responsible netizen is to proxy port 25 and filter outbound traffic to
> > ensure that none of it is spam/viruses/etc.
>
> redirecting traffic without the authorization of the user has a name:
> hijacking.

Enough on this thread.

If hotspot operators want to block viruses in outbound mail, then
they should be using a transparent proxy.

An MTA is not supposed to store the IP address that the client
wanted to connect to, and to replay the login information that the
user wanted to send. There are too many things that can go wrong.

        Wietse
Reply | Threaded
Open this post in threaded view
|

RE: Allow all types of Relay for a Hotspot Provider..

Lee Quince
In reply to this post by Jorey Bump
Jorey..

In a way we do try to cover all angles .. All port 25 traffic hits ASSP
first then is proxied to Postfix.

This solution allows us to support port 25 traffic, like T-Mobile, BT
openZon, The Cloud, but also restrict.

A client is only allowed

5 Msg's in a 1 Min otherwise then are black listed for 10 Min

We also Bayesian Check outbound Email, along with DNSBL, URIBL, SPF
Check..

This closes down any Zombies on the network straight away. So far it has
been successful.

Regards

Lee

Lee Quince wrote, at 05/13/2008 12:56 PM:
> Jorey,
>
> Still missing the point...
>
> Most ISP's still only allow you to relay when connected to one of
there
> own connection's.

It's true that ISPs are blocking outgoing connections to port 25, if it
isn't to one of their submission servers, but they are also implementing

port 587 submission or offering webmail to get around the blocks imposed

by other ISPs or hotspots when users are on another network. It's a
necessary evil, but also a good thing, considering the number of zombies

out there.

> 95% of users still use unauthenticated SMTP.

Well, maybe, but 98% of those are zombies. :)

> 5% of users use authenticated SMTP.

Real users authenticate. :)

> Hence lets reduce the bigger problem. "What the Customer wants"

Again, if that's your only concern, don't block port 25. However, I
agree that you should do the responsible thing and block outgoing
connections to port 25, so the rest of us don't have to deal with spam
from zombies that connect to your hotspot.




It's good that you're doing
this. It may cause problems for users that authenticate over port 25,
but there are solutions that don't require you to sniff login
credentials, break encryption, or relay mail for anyone connected to
your network. In fact, it's really not your problem anymore. Inform your

users that you block port 25 and that they should contact their own
technical support if this interferes with their ability to send email.


12