mobile user strawman argument

Mailman List Mirror (Read Only)
1

Directed at no specific person because I've seen several people use it in
their examples recently...

I'm seeing alot of arguments in the form of "I have mobile users and they
aren't going to be able to send email if you use injection IP mail
filtering approach X" (where X is SPF, MX+, or what have you); which take
the same form as the arguments people made against closing open relays.

For those that don't remember, prior to around 1995 or so most all mail
servers would relay may for anybody by default. People that got tired of
being abused made it so only their customers could use their mail servers
to relay mail by methods such as: POP AUTH, only relaying mail for their
customer IPs, only accepting mail to be relayed from domains that were
hosted on that server, etc.

At that time some people swore up and down it was unworkable because all
of their mobile users wouldn't be able to send mail using their mail
servers because the remote users use random dynamic IPs from all over the
Internet.

After a large amount of gnashing of teeth and whining, and the spread of
knowhow of the several different methods to close an open server yet still
allow your users to send mail, these objections were overcome and the open
relays were closed.

Ok... fast forward to the present in which we can now assert that service
providers don't use open relays to provide service to their customers.

So now I'm supposed to believe that its impossible for service providers
to coordinate which mail server a user is supposed to use to send their
mail through (with the information about authorized sending IPs for a
domain communicated to receipient SMTP servers according to the method of
your choice) when they already force their users to use only SMTP servers
that they have authorized access to relay through.

Ya, ya, ya... you are going to say 1) its impossible to get people to use
designated servers for outgoing email. Or you will say 2) even if you do
this there will still be *spam*! (egads shock horrror!) Ugh please.

1) Getting customers to use designated servers is already done and
standard operating procedure.

2) Most people would agree that closing the open relays as they were was
worthwhile and a sound security decision. The fact that spam still exists
doesn't make the decision wrong, it just means that you should not be so
naive or disingenuous as to expect various limited practical precautions
to solve all the world's spam problems.

So much deja vu I feel like I'm on a merry-go-round.

Mike.

+----------------- H U R R I C A N E - E L E C T R I C -----------------+

2

So, try to authorize the sending host rather than the path (mail from
/ sender etc)

You neatly work around that problem

3

That's not the problem. The problem is that there are plenty of providers who transparently proxy *all* outgoing SMTP requests to their servers, e.g., AOL. If you publish SPF records for your business and a customer is roaming and using AOL to access the Internet (which is one of the primary reasons why a lot of people keep their AOL accounts), they will be unable to send e-mail as their userid on your server, because that connection will instead be silently routed to the AOL servers.

  Yes, you can bypass this by using alternative ports, but not all MUAs support alternative ports, or support them correctly.

  Of course, if you're going to do this, you should also be doing at least SMTPAUTH and preferably TLSSMTP, but then again many clients are broken and don't support these technologies or don't support them correctly.

  There are alternative solutions to the mobile user problem -- webmail services, VPNs, and shell e-mail. But none of them are a panacea, and if you want to talk about a private customer as opposed to a business person who is on an official trip, these options are much less practical if it is their home ISP who has done this to them.

4

> Ya, ya, ya... you are going to say 1) its impossible to get people to use
> designated servers for outgoing email. Or you will say 2) even if you do
> this there will still be *spam*! (egads shock horrror!) Ugh please.

  That's not the problem. The problem is that there are plenty of
providers who transparently proxy *all* outgoing SMTP requests to
their servers, e.g., AOL. If you publish SPF records for your
business and a customer is roaming and using AOL to access the
Internet (which is one of the primary reasons why a lot of people
keep their AOL accounts), they will be unable to send e-mail as their
userid on your server, because that connection will instead be
silently routed to the AOL servers.

In practice if your remote users don't use the submit port on your servers
it gives rise to all kinds of different issues involving you trying to
support the outbound filtering AOL is doing on your customers sending from
non AOL domains.

  Of course, if you're going to do this, you should also be doing
at least SMTPAUTH and preferably TLSSMTP, but then again many clients
are broken and don't support these technologies or don't support them
correctly.

Or you support POP AUTH, which just works, is in widespread use (probably
the most widespread of the methods of authenticating the submit port after
allowing relaying by IP), and was implemented years ago when open relays
were closed.

Mike.

+----------------- H U R R I C A N E - E L E C T R I C -----------------+

5

In practice if your remote users don't use the submit port on your servers
it gives rise to all kinds of different issues involving you trying to
support the outbound filtering AOL is doing on your customers sending from
non AOL domains.

  That doesn't change the fact that plenty of MUAs do not properly handle alternative ports.

Or you support POP AUTH, which just works, is in widespread use (probably
the most widespread of the methods of authenticating the submit port after
allowing relaying by IP), and was implemented years ago when open relays
were closed.

  Unfortunately, plenty of MUAs, even ones old enough to have been around when POP-before-SMTP was the only authentication measure around, still don't support this, or don't support it correctly.

  Hell, damn few clients do plain-jane POP or SMTP anywhere remotely close to correctly. Expecting them to do anything more advanced than that will be an exercise in frustration.

  You can't just set a hard and fast rule (like "let them eat cake"), and automatically expect all MUAs to kow-tow overnight.

6

> In practice if your remote users don't use the submit port on your servers
> it gives rise to all kinds of different issues involving you trying to
> support the outbound filtering AOL is doing on your customers sending from
> non AOL domains.

  That doesn't change the fact that plenty of MUAs do not properly
handle alternative ports.

I've done a look-see around my network and acquaintances a while ago, and
among them were quite a few mailers, all of which supported not only
alternate ports, but also SMTP AUTH. MSA support is far more available than
this classic FUD.

If a MUA still doesn't support setting the port to 587 then, at this point,
it should be declared broken, to wit:

  You can't just set a hard and fast rule (like "let them eat cake"),
and automatically expect all MUAs to kow-tow overnight.

It's been nearly six years (RFC2476 was December 1998). Is that long enough
for you yet?

(Heck, if the change-for-standards-at-a-snail's-pace Pacific Northwestern
quasi-monopoly could get off their asses to allow alternate ports, anyone
should be able to offer it by now.)

7

We support all of the above - including only authenticated submit port use. I don't really understand the religious discussion of which protocols should be supported and which should not be. Support them all and let your customers decide which ones work for them based on their particular circumstances at the time and the network they happen to be using.

-Robert

Tellurian Networks - The Ultimate Internet Connection
http://www.tellurian.com | 888-TELLURIAN | 973-300-9211
"Well done is better than well said." - Benjamin Franklin

8

I've done a look-see around my network and acquaintances a while ago, and
among them were quite a few mailers, all of which supported not only
alternate ports, but also SMTP AUTH. MSA support is far more available than
this classic FUD.

  Your network and your acquaintances don't count. They're much more technically competent than the average Internet user. Your family probably thinks of you as the computer expert. In turn, they themselves are probably the computer experts in their respective groups of friends and co-workers, probably in part due to their long-term association with you and the knowledge that has "rubbed off" over the years. Even they and their friends/co-workers are probably too advanced for this survey to be valid.

  I worked at AOL for over two years. I know what the average Internet user is and is not capable of. I know what kind of software they use, and their total and complete incompetence in configuring that software, even if given the world's most explicit step-by-step instructions. If you can't deliver a configuration that works out-of-the-box for them, and which they are unable to change into a less functional state, it's not going to happen.

  I am the computer expert in my family. My mom is the computer expert in her office. My maternal grandmother was the computer expert in her office -- she wasn't introduced to them until she was in her late 50s, and she's in her 80s now. Even my grandmother is more technically competent than the average Internet user, and would be overqualified to be a subject of such a survey.

It's been nearly six years (RFC2476 was December 1998). Is that long enough
for you yet?

  Don't ask me, ask the MUA authors.

(Heck, if the change-for-standards-at-a-snail's-pace Pacific Northwestern
quasi-monopoly could get off their asses to allow alternate ports, anyone
should be able to offer it by now.)

  Plenty of monopoly cable and telephone operators still don't offer such services, and most will only be dragged kicking and screaming into the 1980s when they are literally given absolutely no other choice. The existence of a particular operator that is apparently somewhat more enlightened does not disprove the model.

9

That's great, but that still doesn't solve the problem. The problem is not your servers and the systems under your control.

  The problems are the clients (which may or may not be under your control), and the systems at the remote end which may prevent the clients from working in the only way they are capable of working, or capable of working correctly, or configured to work.

10

* brad@stop.mail-abuse.org (Brad Knowles) [Fri 01 Jul 2005, 00:33 CEST]:

11

> I've done a look-see around my network and acquaintances a while ago, and
> among them were quite a few mailers, all of which supported not only
> alternate ports, but also SMTP AUTH. MSA support is far more available
> than
> this classic FUD.

  Your network and your acquaintances don't count. They're much more
technically competent than the average Internet user.

And Grandma Ann and her knitting circle aren't. Yeah, yeah, I've heard this
all before dozens of times, and the fact of the matter is that there are a
lot of ignorant folks in my family, and I did not set up, nor do I maintain,
any of their equipment or software. Of course, by far and large, they use
the crappy MUA which ships with the OS I already mentioned by inference,
which has long since supported alternate port submission.

Rather than repeating FUD with abstractions, would you care to point out
what MUAs you think still don't support a six-year-old RFC for which the
major MUAs *do* already provide support?

> (Heck, if the change-for-standards-at-a-snail's-pace Pacific Northwestern
> quasi-monopoly could get off their asses to allow alternate ports, anyone
> should be able to offer it by now.)

  Plenty of monopoly cable and telephone operators still don't offer
such services, and most will only be dragged kicking and screaming into the
1980s when they are literally given absolutely no other choice.

Um, I wasn't talking about an ISP. I was talking about the MUA with the
largest market share, and most frequently found security holes, which ships
with an OS I prefer not to name directly is possible.

Or is that still too vague?

12

NANOG != routers

  NANOG is about much more than just routers. It is the North American Network Operators Group, and some Network Operators may do nothing but administer routers, but plenty of other Network Operators do a lot more.

  So, you can take your petulant holier-than-thou attitude elsewhere.

13

Um, I wasn't talking about an ISP. I was talking about the MUA with the
largest market share, and most frequently found security holes, which ships
with an OS I prefer not to name directly is possible.

  There are three key pieces of the puzzle, all of which have to fit together in order to make the whole thing work:

    1. The user's ISP

    2. The remote ISP

    3. The user's equipment (including OS and MUA)

  If the user's ISP doesn't provide the necessary services, then nothing else matters. If the user's OS and MUA don't support the necessary services, then nothing else matters. If the remote ISP blocks the necessary services, then nothing else matters.

  As a North American Network Operator, the only thing you can control is #1. Whatever problems exist as part of #1, you should have the ability to fix them, but that is the limit of your ability.

Or is that still too vague?

  I'm saying that there are problems in #2 and #3 that also have to be lived with or worked around in some way, otherwise the user is dead in the water.

  If that's still too vague, consider that smartphones will soon be the dominant method of connecting to the Internet (if that isn't the case already). I have run into multiple MUAs on a SonyEricsson P900 and a Treo 650 that are sorely broken in a variety of ways, including things like SMTPAUTH, TLSSMTP, POP-before-SMTP, etc....

  Oh, and Microsoft still throws some pretty interesting wrenches into the mix.

14

So, you can take your petulant holier-than-thou attitude elsewhere.

ok, kiddies. please read your own example.

randy