ietf-mxcomp
[Top] [All Lists]

Re: When spoofing is.

2004-03-21 14:30:28


[note: Co-chair Andrew Newton posted a etiquette list that suggests
posting no more than three times a day, so this will be my last post
today.]


In <20040321192414(_dot_)GA67093(_at_)bitshift(_dot_)org> "Mark C. Langston" 
<mark(_at_)bitshift(_dot_)org> writes:

                  And we need to be careful that the restrictions placed
on RFC2821 headers don't create widespread problems for legitimate
changes of identity.

Agreed.


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.

It is encumbent on those domain owners that *choose* to publish LMAP
restrictions to provide their legitimate users methods of working
within those restrictions.  Users who have IT departments that make
bad choices generally know how to contact them to voice their
complaints.  There will probably be some users that have IT
departments that are so bad that the market place will take care of
eliminating them.


As for blocking outbound mail use, Earthlink's a good example.

I realize that there are ISPs that block outbound email.  I am not
aware of any ISPs that block all methods of communication.


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

"We" are not going to put in a very strong anti-spoofing system.  "We"
are going to give domain owners, via the LMAP proposals, a voice and a
way for email receivers to listen.  Domain owners and/or email
receivers can choose not to communicate anything.


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.

Yes, our recommendations need to inform people of the consequences of
their actions.  "We" can not dictate anything, much less widespread
infrastructure changes.



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?

All LMAP proposals allow domain owners to choose to say that all IP
addresses are valid sources of email.  By default, this will let them
keep the status quo.


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.

If any of the LMAP proposals are widely adopted, it may be useful for
MUA developers to allow that option.  (I suspect that it will be
rarely needed, but...)


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.

You raised the point about distinguishing between postcard sites that
allow arbitrary creation of RFC2821/2822 headers to be sent and
roaming users.

The restrictions, therefore, are ISPs that allow you to send out
email with arbitrary RFC2821/2822 headers, but not allow you to send
out email where they don't match.  Neither of the examples you cite
restrict the latter without restricting the former.  Therefore, the
LMAP proposals do not make things any worse.


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.

We can not prevent ISPs from doing stupid stuff, but in any case, it
is their network and their rules.  The LMAP proposals do not change
this situation. 


                                                            We're moving
from an open trust model to a closed trust model.

No, we are moving from a model where domain owners have no voice to a
model where they do.  Domain owners that like the open trust model
will be able to express that and email receivers that don't want any
closed model will not have to listen.


                                                   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.

I disagree.  If you give people a voice, there will always be those
that will choose to use their freedom of speech to say things that are
stupid/bad/hateful/destructive/silly.  However, I fundamentally trust
that the benefits of free speech outweigh the costs.  This is
especially true when no one is forced to listen, as in the case of all
of the LMAP proposals.  Buying a domain name is only $5-10/yr, so even
if you need to buy a domain to get a voice, we aren't talking about a
huge cost.


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?  

Yes.  Educating domain owners/email receivers and having them educate
their users is not always easy, but it is far better than not allowing
them to have a voice.


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.

None of the LMAP proposals in any way give new restrictions the
direct-to-recipient-MTA connection.  They simply take company/ISP
policies off of the web pages, TUAs, employee handbooks, etc., and
automate them.


-wayne



<Prev in Thread] Current Thread [Next in Thread>