From: Jorey Bump (listjoreybump.com)
Date: Tue May 13 2008 - 08:13:05 CDT

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

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.

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