|
Re: When spoofing is.
2004-03-21 13:46:19
> On Sun, Mar 21, 2004 at 05:13:47AM -0800, Hallam-Baker, Phillip wrote:
>> And we should prevent giving folk like this some pain because???
>
In <20040321174750(_dot_)GZ67093(_at_)bitshift(_dot_)org> "Mark C. Langston"
<mark(_at_)bitshift(_dot_)org> writes:
> Can you distinguish between that evil postcard site based on RFC2821
> identity, and a mobile user attempting to use an address other than the
> one his ISP has assigned him (say, for example, his work address)?
On Sun, Mar 21, 2004 at 12:32:29PM -0600, wayne wrote:
No, we can't make a distinguish between various kinds of
spoofing/forgery/munging/whatever-you-want-to-call-it.
--"Mark C. Langston" <mark(_at_)bitshift(_dot_)org> wrote:
Well, semantic difficulties aside (we won't get into the whole
"legitimate spoofing" again), there are legitimate reasons to alter
RFC2822 headers. And we need to be careful that the restrictions placed
on RFC2821 headers don't create widespread problems for legitimate
changes of identity.
Mark and Wayne-
I think you two agree more than you disagree. May I suggest that you try a
bit harder to state your own positions concisely, rather than concentrating
on DISagreeing with what the other person said?
I would much rather read a paragraph or two of well-written and
well-thought text describing what you think, than to see a thread go on and
on with one-liner comebacks that are all argument and no discussion.
Let's assume that there is a WIDE range of proposals possible, and at
either two extremes are "Modify nothing. Fix nothing." and "Break as much
as possible to make things more technically correct." I don't think anyone
here would reasonably pick either of these. I think we want a solution
that gives a balance of "maximal pain to spammers, minimal pain to
legitimate users".
So, please focus on saying what you mean and what you think. And please
don't assume that because someone uses an extreme or a generalization to
make a point that they necessarily advocate extremes or believe
generalizations. Using extremes and generalizations are lazy ways to make
a point, but attacking those instead of attacking the point prolongs the
agony for everyone else :)
Thanks for your time.
> Assume for the sake of argument that the ISP blocks outbound port 25,
> 465 and 587, so the entity cannot connect directly to their office MTA.
Well, I have a whole bundle of disagreements with this sentence.
First, you would also have to assume that the ISP blocks all VPNs,
port 80/443 traffic to webmail systems run by their company, SMTP over
other ports and all other means to communication with their office.
I doubt that you can find such an ISP, but if you do, I would
recommend not using them. They don't sound particularly useful.
And here, you've assumed the presence of VPN, webmail systems, SMTP over
nonstandard ports, etc. Many ISPs prohibit VPN use or insist on a
more expensive service tier if TCP protos 50 and 51 are to be used. As
for blocking outbound mail use, Earthlink's a good example.
It's all well and good to think, "we'll put in a very strong
anti-spoofing system and let the chips fall where they may", but I'm on
Dave's side with this: We need to be careful what consequences ensue
from our recommendations. We can't see ourselves as dictating
widespread infrastructure changes unnecessarily; we should be seeking a
solution that has maximum desired effect _and_ minimum infrastructure
impact. Otherwise, we'll be greatly limiting the acceptance of this
group's product.
Here's another valid use of spoofing (again, apologies to Dave):
Anonymous remailers. If the postcard contingent aren't viewed as
valuable in this discussion, how about the bulk of the pro-privacy and
cryptography communities?
Second, does the hypothetical ISP prevent email going through there
MTA to have the same RFC2821 MAIL FROM as the RFC2822 From: data?
If not, you can, at least theoretically, use your ISPs account on the
RFC2821 MAIL FROM: and your work address on the From:. This is
basically what all mailing list software does.
Yes, but is it what all MUAs do? End-users never interact with the
RFC2821 identity; the software does that for them.
Can you cite examples of ISPs that would have such a restriction?
Which restriction? Blocking outbound mail use on servers other than
their MTAs? Earthlink, for one. Insisting upon the ISP's assigned
account be in the RFC2822 From: header? Programmatically, no, not off
the top of my head. By policy, yes: Comcast is but one example.
From http://www.comcast.net/terms/use.jsp :
(xviii) impersonate any person or entity, engage in sender address
falsification, forge anyone else's digital or manual signature, or
perform any other similar fraudulent activity;
Third, I can understand an ISP/Companies blocking port 25 traffic
from other than their authorized MTAs. The vast majority of such
email is spam, and blocking such traffic cuts down on abuse desk
costs. However, I have a much harder time understanding why an ISP
would block 587 traffic. It is my understanding that almost all MTAs
require some sort of validation before accepting email on the
submission port.
Can you cite examples of MTAs that accept unauthorized email to port
587? Can you cite examples of ISPs that block port 587?
No. But æs Meng states on the pobox.com SPF pages, ISPs don't _yet_
block port 587, which he points out as justification for using it as a
workaround for ISPs blocking 25 outbound.
As for reasons as to why they might in the future: The ISP may view use
of port 587 as an attempt to skirt their outbound 25 block. The ISP may
not have a well-implemented port-blocker, and it may already be blocked
out of negligence, and remain so out of inertia. The ISP may wish to
keep their customers on their infrastructure, and therefore block 587
just as they block 25.
It's okay to say, "change ISPs" when it's a single, rogue ISP doing
this. But when the status quo is, "thou shalt use our MTAs, and only
our MTAs, for all outbound mail", the lack of port 587 blocking may
largely be due to the lack of port 587 use. Force traffic to migrate to
that port, and it may well end up blocked as well.
We can't guess the reasons for ISPs doing these things, nor can we know
whether they will. The one thing that's certain is that wholescale
changes like this will have consequences, and those consequences aren't
easily knowable.
We could recommend those changes and hope for the best, but hoping for
the best is what got us into this situation to begin with. We're moving
from an open trust model to a closed trust model. I believe that
movement will result in a balkanization among service providers to the
detriment of the end user, unless and until software catches up to the
changes and finds ways to minimize the damage.
Fourth, if someone is really in a very locked down network (public
access terminals?), is it really that unreasonable to ask them to use
the appropriate email address and add a comment to the top of the
message that says "Hi, I'm at a restricted terminal, this is really
foo(_at_)example(_dot_)net"?
I don't know. Is it reasonable to assume automated anti-spam tools can
interpret that? You assume that comment will make it to a human.
Whitelisting in current tools works on RFC2822 identities, typically.
Domain owners that publish LMAP restrictions need to be aware that in
some cases, their legitimate users will have to make some changes. I
don't see this as a big problem.
User education as solution?
> Or, shall we force everyone who travels on business to expose their
> personal email accounts when conducting business while on the road?
I'm not sure what you mean by "expose" here.
If I'm travelling on business, and I can't use my work address in the
headers for whatever reason (whether it's due to ISP enforcement or
bounces resulting from RFC2821 checks), I'd have to use whatever works
with that ISP. The same holds true if I want to send work email from my
home, using my home ISP.
If that's my personal ISP account, it's been "exposed". Many people
prefer to keep their business and personal email separate. Futher, they
like to keep one group from discovering the identity used in the other
group. Handing over a list of personal addresses to one's employer
isn't typical.
Perhaps the solution is to have the employer pay for the ISPs used on
the road, and that's reasonable. But what about all other scenarios in
which the employee is out of the office, on personal time, and needing
to send an email with a work address? I'm all for everyone moving to
SMTP AUTH. In much the same way, I'm in favor of ubiquitous encrypted
communication. But I don't believe either are going to occur until
everyone is forced to do so. I don't think forcing everyone to do so is
the correct approach, however. Not without an easy transition between
the two, _and_ a sunset provision for the older, less-secure approach.
I can see a way to do the former, but no way to enforce the latter.
Without the latter, I can't see any impetus to change, particularly in
organizations where change is met with significant inertia.
What I'm getting at here is this: Is there any data on how MUAs create
the RFC2821 identity based on RFC2822 identity? How many MUAs simply
take what's on the RFC2822 From: and use it for the RFC2821
ENVELOPE-FROM, and how many allow manipulation of the RFC2821 identity?
If we're moving towards a world in which we completely eliminate
the MUA direct-to-recipient-MTA connection, we should acknowledge and
embrace that, rather than talking around it.
--
Mark C. Langston Sr. Unix SysAdmin
mark(_at_)bitshift(_dot_)org
mark(_at_)seti(_dot_)org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>
|
|