Re: [exim] How to have port 80 open, along with a website?

>
> Port 587 is for *authenticated* SMTP, as you say. My SMTP uses a different
> 'quota' system where users don't authenticate, but rather are restricted
> to a lowish number of emails per day (and before you say 'open relay',
> this system has been proven to be an effective alternative to
> authentication for over 10 years). Spammers don't have the incentive to
> try to guess an actual member's email address (exim looks at the sender's
> 'from' email address to determine if they are allowed to send), and I
> have never seen anyone successfully guess a member's email address yet.
> Trust me - it works, so let's not discuss that strategy.
>
> Because port 587 is for authenticated SMTP, I do not think I can or should
> use it for this.
>
>

Quite right. If you provide unauthenticated SMTP on port 587, then ISPs
will start to block access to port 587 for the same reasons that they block
port 25. Limiting the sender address, and limiting the quotas might be a
workable, and acceptable alternative strategy. However, if I were in your
situation, I'd require all NEW customers to authenticate, and offer more
relaxed quotas for users that were willing and able to change their
configuration.

I'd also suggest deploying new IP addresses, with specific addresses
imap.x, smtp.x, pop.x for new customers. Let them know the configurations,
and if they choose to change their configuration, have them authenticate
too. Oh, and have all your documentation point to port 587, but tell people
that when they're at tightly locked down sites that using port 80 might
work (depending on whether those sites deploy web proxy servers).

It may take some years to get to a situation where all your customers are
using separate addresses for separate services, but it's worth doing
because it will give you more flexibility in how you deploy your services.
We, for example, use the same hardware but separate IP addresses, and
separate DNS names for our IMAP, SMTP, and MSA services. If we choose to,
we could easily separate the hardware.


--
Ian Eiloart
IT Services, University of Sussex
x3148