ingress SMTP

[Keith_Medcalf]

Raises hand.

Why would the requirements for authentication be different depending on the port used to connect to the MTA?

No matter how a session comes into the MTA (port 25, 465, 587, anything else) and no matter whether it is encrypted or not, the requirement for authentication (which is always available and advertized), is based on a simple policy:

- local delivery originating from a non-blacklisted or "internal/customer" address does not require authentication;

- relay from "internal/customer" IP Addresses does not require authentication;

- any connection from a blacklisted IP requires authentication or no mail will be accepted;

- relay from "external/non-customer" IP Addresses requires authentication;

Is there a valid reason why a different configuration is justified?

As an aside, outbound port 25 traffic is also blocked except from the MTA.

[Mark_Foster]

> >You're forgetting that 587 *is authenticated, always*.

> I'm not sure how that makes much of a difference since the
> usual spam vector is malware that has (almost) complete
> control of the machine in the first place.

Well, that depends on MUA design, of course, but it's just
been pointed out to me that the RFC says MAY, not MUST.

Oops.

Does anyone bother to run an MSA on 587 and *not* require
authentication?

Raises hand.

Why would the requirements for authentication be different depending on
the port used to connect to the MTA?

No matter how a session comes into the MTA (port 25, 465, 587, anything
else) and no matter whether it is encrypted or not, the requirement for
authentication (which is always available and advertized), is based on a
simple policy:

- local delivery originating from a non-blacklisted or
"internal/customer" address does not require authentication;

- relay from "internal/customer" IP Addresses does not require
authentication;

- any connection from a blacklisted IP requires authentication or no mail
will be accepted;

- relay from "external/non-customer" IP Addresses requires
authentication;

Is there a valid reason why a different configuration is justified?

As an aside, outbound port 25 traffic is also blocked except from the MTA.

I'm glad someone finally posted the above.

When I came 'up through the ranks' the policy could be explained simply,
by separating POP3 and SMTP. The following is the users-perspective
explanation I used to offer:

- Mail from World to Client is checked via user/password check (POP3 in
your mail client). Because its authenticated, it can be done from
anywhere - subject to your ISPs policies on the subject.

- Mail from Client to World is not authenticated (generally speaking) but
what is checked is where you are. The rules:

- Mail from ISP-IP to ISP-SMTP-SERVER is accepted regardless of destination.
- Mail from anywhere else to ISP-SMTP-SERVER is accepted only if the
destination is 'local' to the ISP.
- There's no reason to do anything else as a general rule.

Privately managed outbound mail solutions (such as a colo, or a corporate
network, which subjects you to some other sort of validation before
accepting your message) should be 'accountable' and in order to circumvent
Port 25 blocking, should be found on other ports anyway. Port 25 traffic
should be subject to the above.

(I realise this doesnt account for SMTP-Auth. The reality today is that
ISPs are blocking Port 25 to reduce spam from drones and that people
should be prepared to work around this.)

So in terms of the OP,
I don't see why joe-user on a dynamic-IP home connection should need the
ability to use port 25 to talk to anywhere but their local ISP SMTP server
on a normal basis[1]. Theyre not doing MX lookups so theyre not going
direct to remote MTAs[2]. Regardless of where they got the mail _from_,
the outbound mail should be via SMTP to their local SMTP server.[3]

If you separate inbound (pop3) and outbound (smtp) mail delivery in your
thinking you can start to make sense of things (from a users perspective).
This is always the tack i've taken when trying to educate users about why
their email outbound doesn't work when theyre moving from ISP to ISP.
(At which point you offer them your authenticated-another-way service,
such as 587 with SMTP auth).

[1] Customers with a specific need to do so should have the means to
opt-out. I believe most of the ISPs in NZ who block 25-outbound from
clients also offer this option.

[2] Customers doing MX lookups are either drones or people with mail
servers at home. The former are obviously the target of the block. The
latter are likely going to be any one of:

- Blocked by SORBS or similar as a dynamic IP
- Running a mail server in breach of AUP
- On a fixed IP and (theoretically) capable of securing their system and
not being a drone or open mail relay (and being traceable via their ISP).

[3] Note also [2]. Outbound mail is associated with your ISP and their
SMTP service. Has nothing to do with inbound mail. Nothing. Nada. Zip.

Or doesn't the rest of the world think like this?

Mark.

PS: It occurs to me that SPF has an influence here, if you're aggressively
using it then you should also be offering alternatives to Port 25 SMTP.
IMHO.

[Frank_Bulk1]

If you leave port 587 un-authenticated then spammers just need to move their
spambots to try port 587 *and* you're never sure who sent the message. If
you're going to have the customer click a few extra buttons to get to port
587, might as well get them to authenticate.

Authenticating port 587 is not the silver bullet, but it buys you a little
bit.

Frank

[Tony_Finch]

It's easier to configure the MTA if you make a distinction between
server-to-server traffic and client-to-server traffic. In fact my systems
distinguish three classes of traffic: MX, message submission, and
smarthost.

The MX service has lots of anti-spam features. You want to separate it
from the others so that techniques like teergrubing don't make message
submission painfully slow. You can also avoid interoperability problems
with server-to-server TLS. You can limit the number of connections used by
the MX service to that when it is being hammered by spammers, you can
reserve some capacity so that message submission and outgoing relay still
work.

Having a message submission service that always requires TLS and
authentication makes it easier for users to check their configuration. A
mistake such as not turning on AUTH can be hidden when they test on their
home network, only to be discovered later when they are roaming far from
tech support.

Separating your smarthost (outgoing relay service) from your MX can avoid
some strange problems. Back in the dim and distant past before remote
AUTHed message submission and before separate MX and smarthost, our
roaming users who failed to change their smarthost setting would have
working email when contacting colleagues but not anyone else, with a
mysterious "relaying is not permitted" error instead of something clear
and helpful. There's also some advantage to making it harder for spammers
to work out the name of your smarthost: we once (years ago) had a
problem with an open web proxy that spammers used as the first half of a
two-stage open relay, the second half of which was the MX of the proxy's
parent domain.

We separate these functions by having separate names and IP addresses for
each one. They are all just facets of the same MTA, so we don't have to
maintainn lots of different configurations.

Tony.

[Jeff_Kinz]

So in terms of the OP,
I don't see why joe-user on a dynamic-IP home connection should need the
ability to use port 25 to talk to anywhere but their local ISP SMTP server
on a normal basis[1].

Whats a normal basis?

My Home ISP won't let me send to more than 200 (or so) email addresses
per day. If I used my ISP's email system I would constantly be losing
my email service due to hitting the limit.

I do the field scheduling for my local town soccer league.
[Never volunteer! ]

So when I send a few announcements out to coaches, referees and
administrators, I hit that limit and get my email shutoff for two days
or so. I eventually switched to MailHop at DynDNS (smtp auth)

I would have used port 25 but our ISP has begun blocking outbound
port 25 nationwide, due to large amount of outbound spam from their
customers.

[Mark_Foster]

*rest snipped*

Is the above described limitation a common occurrance in the world-at-large?

I've not heard of ISPs doing number-of-recipients-per-day limitations.
I've heard of them doing number-of-recipients-per-email limitations (thus
limiting large cc/bcc lists) but not total number of emails.
Who's to say that there arent legitimate reasons to email a large number
of people - perhaps your customers??

Certainly if my own ISP did something like that, you're quite right, i'd
have to find an alternative. (Or perhaps, an alternative ISP. )

(who set the limit at 200? Can you opt-out of the limit or have it upped?)

Mark.

[Jeff_Kinz]

Summary: Perceived limit of 200 email addresses delivered to per day
*rest snipped*

Is the above described limitation a common occurrance in the world-at-large?

I've not heard of ISPs doing number-of-recipients-per-day limitations.
I've heard of them doing number-of-recipients-per-email limitations (thus
limiting large cc/bcc lists) but not total number of emails.

An excellent question. I was unable, as a customer, to get a direct answer
to any of my queries as to what was or wasn't allowed at all, despite
multiple attempts each time it happened.

After the 3rd cut-off, I cut out, so to speak. All my email still
travels over their network, it just doesn't get routed through their
SMTP servers.

Who's to say that there arent legitimate reasons to email a large number
of people - perhaps your customers??

Certainly if my own ISP did something like that, you're quite right, i'd
have to find an alternative. (Or perhaps, an alternative ISP. )

(who set the limit at 200? Can you opt-out of the limit or have it upped?)

Never found any way to, but that may only mean I didn't find the right
magic combination.

At least now I know my monthly gross transfer is limited to 250 GB
(except in February when its only 228 GB... )

Jeff Kinz.

[Simon_Waters1]

If the ISP blocks port 25, then the ISP is taking responsibility for
delivering all email sent by a user, and they have to start applying rate
limits. Otherwise if they send all email from their users, all they've done
is take the spam, and mix it in with the legitimate email, making spam
filtering harder.

Locally one of the big ISP insists you register all sender addresses with
them, so all the spam from them has legitimate sender credentials.

The problem is that by blocking port 25, you are basically then switching
users to arbitrary per ISP rules for how to send email. This is probably good
for ISPs (provides some sort of lock-in) but bad for their users.

Whilst the antispam folk think it is a godsend because their block lists are
smaller, it is relatively easy to block spewing IP addresses, and hard to
filter when good and bad email is combined. Which is why they hate Google
hiding the source IP address.

This will continue until the real issue is addressed, which is the security of
end user systems.

[Mikael_Abrahamsson]

MUAs should stop sending email via 25 and use 587 or equivalent instead. There is little actual reason why someone should be able to send TCP/25 SMTP email from a residential connection when most software support authenticated TCP/587 submits.

We don't allow most of our residential customer base to speak SMTP TCP/25 to anywhere at all (and we have millions of them). Wish more ISPs would do the same.

[Mark_Foster]

Probably fair enough, if you as an ISP can get away with enforcing this sort of policy then so much the better.

However relaying through your own ISPs 25/tcp should surely then make it relatively easy for noise to be tracked down and nailed at the source - by ISPs? (Do abuse@ desks investigate spam these days?)

[Jeff_Kinz]

>If the ISP blocks port 25, then the ISP is taking responsibility for
>delivering all email sent by a user, and they have to start applying rate
>limits.

MUAs should stop sending email via 25 and use 587 or equivalent instead.
There is little actual reason why someone should be able to send TCP/25
SMTP email from a residential connection when most software support
authenticated TCP/587 submits.

Just FYI- the ISP has the same 220 email address limit even when I send
thru port 587, authenticated. (its comcast)

[Rob_Seastrom2]

Mark Foster <blakjak@blakjak.net> writes:

We don't allow most of our residential customer base to speak SMTP
TCP/25 to anywhere at all (and we have millions of them). Wish more
ISPs would do the same.

Probably fair enough, if you as an ISP can get away with enforcing
this sort of policy then so much the better.

However relaying through your own ISPs 25/tcp should surely then make
it relatively easy for noise to be tracked down and nailed at the
source - by ISPs? (Do abuse@ desks investigate spam these days?)

As others have noted, intercepting 25 breaks SPF. It also
gratuitously creates weird anomalous behaviour that is much harder for
a reasonably clued person to debug than a simple blocked port, so it's
more likely to buy you a help desk call (with a subtle problem that
your level 1 folks probably can't get sorted anyway). Perhaps you
aren't in a position where you have to care about the balance sheets,
but keeping the load off the help desk is a wonderful thing to do in
terms of cost control. Doing traffic analysis looking for noise is
just extra work for your abuse people - when I was setting policy for
this sort of thing we put a cap at 1000 discrete destinations per day
per authenticated user (with a daily report of who'd busted it, and
most days the report was 0) and only once ran into a problem where
someone was legitimately trying to send mail to a bajillion people and
called the help desk.

-r