> As a specific example, I have
> email accounts at Sun, on my home systems, Gmail, and a bunch of
> other places.
> All, I repeat _all_, of these services allow me to easily configure
> autoforwarding to multiple destinations.
Uh - you sure.
Yes, as a matter of fact I am sure. I try very hard not to make
assertions
without the facts to back them up.
I'm not aware how to make gmail go to multiple system
It's trivial. Hit the settings tab at the top right and then create
two
filters. Use whatever critera you like and have one that forwards
to address A
and the other to address B. Before I included gmail in my response
I tested
this with two non-gmail accounts I have elsewhere and gmail happily
forwarded a
test message to both. No warnings, no problems, just two copies of
the mail. I
just checked my account again just now and the both forwards are
still in place
and working. Here's approximately what my settings page has to say
about it:
The following filters are applied to all incoming mail:
Matches: subject: vvv
Do this: Forward to xxx(_dot_)xxx(_at_)yyy(_dot_)yyy
Matches: subject: vvv www
Do this: Forward to zzz(_dot_)zzz(_at_)aaa(_dot_)aaa
I can't really talk about the specific ISPs we have as customers
and their
policies, but I can assure you gmail is not alone in offering this
capability
to their users. To the extent offerings differ, the difference
seems to be
whether or not users are allowed to configure custom filters at
all, not
whether or not setups that allow custom filtering configuration can
forward.
Hotmail, for example, effectively doesn't offer custom filter
settings, so it
is hardly surprising that they don't offer forwarding.
which is of course the important one because the others systems have
relationships with you and other ways to secure things by causing bad
consequences for you if you abuse the system.
I don't believe this is as much of a difference as you seem to
think. Quite a
few of the cases of mailbombing I've seen have been disgruntled
employees and
the like attacking their own company's systems. (AFAIK none of them
involved
the use of sieve redirect, but that's really beside the point.)
Apparently
nothing says "I quit" quite like a mailbox with 10 million pieces
of hate mail
in it.
> If memory serves, your suggested way to prevent it was to allow at
> most one redirect operation to be done during the execution of a
sieve
> script.
Well, what I have in my notes from the prague meeting was "Told them
I was OK with SHOULD not redirect to more than one location outside
the domain".
And I responded that I think that goes too far and isn't
reasonable. In
particular, a SHOULD that fails to take into account that there are
legitimate
use-cases for mutlple redirects makes the entire specification look
incompetent
and serves to weaken the effectiveness of all the other advice we
give.
We may have different ideas about what domain means but
roughly I would mean administrative domain - certainly I would call
an enterprise or large bank one domain even thought they might have
separate DNS domain names for different locations or something. You
might use the term "onsite" where I used domain.
I don't think the restriction to a single domain, regardless of
what domain
means, accomplishes nearly as much as you seem to think it does.
Again, to the
extent mailbombing is an issue, in my experience it's as much of
one within an
ADMD as outside of it. Perhaps more.
> And you've been told that this is simply not acceptable - there
are too
> many use cases for forwarding email to two different places at
once.
Actually, I have received very little comment on if this is
acceptable or not. I have mostly recieved something that loosely
translated to "the WG disagrees with your discuss". I would be very
happy to talk what my concerns are and have folks figure out if their
is a solution that addresses them and still meets the bulk of users
needs.
Then there has been a disconnect getting WG comments back to you.
Several
comments were in fact made, including but not limited to one from me.
> In fact this is an
> incredibly common thing for people to do for all sorts of
> legitimate reasons,
> including but not limited to:
I suspect what I had proposed meets all these use case but don't
claim to really know. Glad to be educated.
OK, let's go down the list and see how ADMD restrictions fare:
> (1) Making messages accessible in multiple ways, e.g. send one
copy to
> my email account and another to my pager. Or voice mail. Or
printer.
> Or FAX.
A very common case is for pager, fax, or voice mail services to be
outsourced
to an external service provider. Often as not different people in
the org will
use different providers for this stuff. This is especially true if
we're
talking about a hosted setup. ADMD restriction cannot possibly work
here.
> (2) Secretaries who need copies of their boss's email.
ADMD restriction are mostly compatible with this use-case.
> (3) Maintaining multiple mailboxes during a service transition
> period. Or two pagers.
This would depend on the nature of the transition. I've seen
transitions to
another ADMD as well as transitions within an ADMD. Domain
restrictions are
problematic in this case.
> (4) Making backup copies of mail to address reliability issues (IMO
> this is not the best way to solve this problem but it is
commonly done
> this way regardless of what I think).
In many cases the entire point of doing this sort of thing,
especially at the
user level, is to get a copy of your mail to a place that has separate
administative controls. ADMD restrictions would be hugely problematic
for this use-case.
> (5) Making copies of stuff for law enforcement use (garden variety
> forwarding is a piss-poor way to implement this but it is
nevertheless
> something people do fairly often).
(uh, yah, laughing about how well this will meet some US Law
enforcement requirements :-)
I can't get into details, but the truly amazing thing is that I've
seen
situations where law enforcement _insisted_ on it being done this
way even
when a technically superior solution was available. (I'm actually
writing a
response to a proposal that's basically a variant of this idea in
another
window.)
I don't actually know if the cases where this has been done involve
forwarding
outside the ADMD or not. (To be honest, I try very hard to learn as
little
about the operational details of interception activities as I
possibly can.)
But given the complete lack of clue needed to even consider using
this approach
I would not be at all surprised if such forwarding has been done in
this case.
> (6) Vacation-time forwarding of important messages to the "next
> tier" of handlers.
This is usually done inside the ADMD but not always.
Tallying up, restricting autforwarding by domain didn't fare so
well against
this list of use-cases. So we're talking about a mechanism that is
ineffective
against a significant subset of actual attacks as well as being
incompatible
with a lot of completely legitimate things people like to do.
Yet another problem with domain restrictions is that it is easy for
them to
turn into a violation of the least astonishment principle. ADMD
boundaries can
be complex - I've seen setups that consider thousands or tens of
thousands of
domains as local - and asking users to understand complex
boundaries is in
effect asking for a lot of support calls. And SPs will do almost
anything to
lessen the number of support calls they get.
...
I'm not surprised - this all seems very consistent with my
discussions to these types of folks. I assume you also have the
discussions with the people like Yahoo, MSN, gmail, around the
policies they put in place to stop their servers from being used in
DOS attacks?
The people I talk to tend to be large ISPs rather than these sorts
of SPs, but
yes, we talk about DOS attacks a fair amount. However, the issue of
the ISPs
own infrastructure being used in the ways you envision for DOS
attacks has
almsot never come up, for the simple reason that it is not a
significant issue
for them.
I know I have been dragged into a few theses - can you
provide some insight around policies there?
OK, let's look at email DOS attacks in a bit more detail. Let's
start with what
sounds like a silly question: What does an MTA do? The answer, of
course, is
that it transfers messages around. It follows that if an MTA is
good at its job
it has to be able to accept and process messages fairly quickly.
And this is in
fact the case: It isn't at all difficult to get performance of 50
messages/second on a single box. With a little more effort you can
kick things
up into the 500 messages/second realm (the main issue at this point
is spam and
virus scanning performance) and MTAs have been built that can
handle well over
2000 messages/second (at this point threads and filesystem
performance become
the bottleneck, requiring a bunch of exotic tricks to deal with).
MTAs are also built defensively, and the primary defensive stategy
is to try
and stop the bad stuff as close to the security perimeter as
possible. The
further in stuff gets the more resources have to be expended
dealing with it.
For example, when a user goes seriously over quota the best thing
to do is turn
back mail with a 4yz (temporary) error, not accept it and hold it
until they go
under quota again. Various rate limiting strategies are useful here
as well and
in practice are widely deployed. So unless your attack has both a
distributed
source and destination there's a very good chance it will be
quickly detected
and blocked.
The bottom line is that modern MTAs are very good at handling lots
legitimate
SMTP transactions and take all sorts of steps to prevent themselves
from being
overwhelmed by too many of them. So attacking the email
infrastructure by
performing lots of real transactions is in effect a frontal attack
against the
most heavily fortified part of the entire system. This is not a
recipe for
success.
So if frontal attacks don't work very well, what does? What we
commonly see are
attacks on various server resources: Connections, threads,
processes, memory
and disk. If an attacker can consume enough of some resource they
can bring the
servers down or at least make them very slow. For example, one
attack we saw a
while back was to send an infinitely long message - some MTAs
buffer messages
in memory and done right this could consume all available swap
space and hang
the server. Or there's the trick of opening lots of connections but
never
sending any data. Or stopping in the middle of the transaction.
(This one is
apparently popular right now - I have no idea why.) Or sending
commands R E A L
L Y S L O W L Y. Or attacking the network stack with malformed
packets,
incomplete TCP exchanges, and so on. Or simply overwhelming the
network itself
with data. Or causing the MTA to overlaod some other service, e.g.
kill the
directory server by sending lots of RCPT TOs and forcing lots of
lookups. Or
exploiting some known flaw in a particular implementation, e.g.
blowing a vital
cache by doing something to invalidate its content. The list is
long, and if
the attacker is highly distributed some of these are very difficult
to defend
against.
But now let's consider where autoforwarders fit into this attack
tree. First of
all, since email is store and forward you cannot get an
autoforwarder to
perform anything but an actual transaction, corresponding to a
direct frontal
attack - exactly the attack MTAs are best at preventing. Even worse
(for the
attacker), autforwarders don't provide an attacker with much
flexibility in
terms of either distributing either the source or destination of
the attack:
Automating account and filter creation is in most cases difficult
if not
impossible, making the task of getting enough autoforwarders in
place very time
consuming and error prone, and most autoforwarders, including Sieve
redirect,
can only forward to a fixed set of destinations - the redirection
cannot go to
an address that's pulled out of the message itself. (The sieve
variables
extension changes this, but the topic at hand is what's possible in
the Sieve
base specification, not what some extension allows.) Finally, the
people who
offer autoforwarding as part of their service are as a general rule
not morons
and will probably notice if a large volume of email starts coming
in only to be
forwarded right back out.
The bottom line is that, your beliefs to the contrary notwithstanding,
autoforwarders just aren't that interesting of a tool for
attackers. This has
been largely true throughout the history of email, and in the
present world of
botnets it is more true than ever. The folks at Cloudmark (who know
far more
about the attack landscape than I do) told me a couple of weeks ago
that the
botnets out there are now so large that devastating results can be
had even if
each infected system only sends out 5-6 messages a day. Given this
why would
any attacker even bother making autoforwarders part of their attack
toolkit?
>> I believe that
>> the IETF has clear consensus that it does not want to deploy
>> technology that could trivially be used for large scale DOS and
>> message amplification attacks with very little safeguards or
>> traceable ways of dealing with this.
>
> This presupposes that there's a real risk here and that the
necessary
> safeguards are not in place. I don't believe either of these are
true.
So far no one as sent me any information arguing these are not true.
Say what? My responses have contained exactly this sort of
information and
argument. And AFAICT you have yet to effectively refute a single
point I have
made.
> > Now my current judgement call is
> > that this is in that category and could cause harm to the
internet.
> But we're not dealing with a new protocol with zero operational
experience here
> where such judgement calls are our only means of assessing
possible risk.
> Rather, we're not only dealing with a protocol that has
signifcant deployment
> and operational experience, we're talking about a particular
feature that's
> been an integrall part of email for decades and is accessible in
all sorts of
> ways besides Sieve.
Sure - and clearly if it is not a problem, it is stopped somehow, I'm
asking the Security section to provide some advice about how this is
all stopped.
Leaving aside that this is a fairly significant change in position
on your
part, the problem with this is that your reasoning rests on an
unwarranted
assumption: That the reason it is not a problem is because people
have taken
specific steps to prevent autoforwarder abuse. The fact of the
matter is they
haven't done this. What has happened instead is that the myriad of
other
measures people have taken to prevent attacks on the email
infrastructure have
collectively managed to make autoforwarders a fairly uninteresting
tool for
attackers.
> First, nobody is claiming that autoforwarders cannot be used as
an amplifying
> component in various sorts of attacks. They can be used this
way. This was true
> for email decades before Sieve came along and it will continue
to be true no
> matter what we do in this document.
yet somehow widespread message amplification attacks from email are
mitigated to an currently acceptable level.
Yes, because the measures people take to defend against other, far
more
pernicious attacks end up defending against autoforwarders
vicariously.
Defending against mail loops, for example, does more to limit the
effectiveness
of autoforwarders as an attack mechanism than any other step you
can take. But
if you don't have reasonable loop detection in place you will
quickly find that
autoforwarders are the least of your problems.
> Second, nobody is claiming that script analysis can be used to
prevent people
> from abusing Sieve as part of such attacks. It simply cannot be
done.
agreed - let's make sure the draft does not suggest people do it
I have no problem with that.
> More generally, the days where email systems can get away
without producing
> comprehensive logs and audit trails ended a long time ago. I
have no idea
> what you're basing your assertions that such attacks would
not be tracable
> in modern email systems, but it runs absolutely contrary to
all of my
> recent experience.
Certainly agree with you in enterprise case but in a public provider
such as yahoo, sure they have logs but they may not have any way to
tying that to an actually human associated with the account.
But even if they had the information they still aren't going to go
after most
abusers - law enforcement could not care less about this stuff and
a civil suit
is way too much trouble for way too little gain. All they're going
to do is
shut down the account.
BTW, the same is often true in the enterprise case: If some guy
uses a mailbomb
to say "I quit" the odds are pretty good the company will simply
clean up the
mess and move on.
In any case, the point of having good logs is to be able to
identify and stop
bad behavior. Catching and punishing the person responsible is a whole
different matter.
This is great - few bits inline below...
> Allowing a single script to redirect to multiple destinations
can be
> used as a means of amplifying the number of messages in an
attack.
> Moreover, if loop detection is not properly implemented it
may be possible
> to set up expontentially growing message loops. Acording, Sieve
> implementations:
>
> (1) MUST implement facilities to detect and break message
loops. See
> RFC 2821 section 6.2 for additional information on basic
loop
> detection strategies.
My discuss did not ask for this but it certainly seems like a good
idea.
Alexey already pointed out that you did in fact ask for this.
>
> (2) MUST provide the means for administrators to limit the
ability of
> users to abuse redirect. In particular, it MUST be
possible to
> limit the number of redirects a script can perform.
Additionally,
> if no use cases exists for using redirect to to multiple
destinations,
> this limit SHOULD be set to 1. Additional limits, such
> as the ability to restrict redirect to local users MAY
also be
> implemented.
We are very close here. If you changed the "Additionally if no use
cases exists for using redirect to to multiple destinations this
limit SHOULD be set to 1." to "Scripts SHOULD be limited to at most
one redirect that is not 'onsite'". And define onsite somewhere. I'd
point out that this is a SHOULD not a MUST and that it could be
ignored if people understood the security implications of what they
were about to do. This could also possibly be coupled with idea after
next point to explicitly allow multiple redirects in some cases.
My problem with this is that "onsite" or "within the domain" or
whatever should
not be conflated with limiting the extent to which users are
allowed to use
redirect. I actually think you have substantially weakened the
impact of this
guidance by over-emphasizing domain restrictions.
> (3) MUST provide facilities to log use of redirect in order
to facilitate
> tracking down abuse.
I would ask if this mean that they MUST know what human the script
was associated with. If yes, it is way beyond what I am asking for
and if no then hard to see how it helps.
On the contrary, this is arguably the most useful advice we have to
offer. Real
time as well as offline analysis of logs is in practice one of the
primary
tools that's used to find and eliminate email abuse. We actually
spend at least
as much time advising our large ISP customers on how to do this more
effectively than we do on how to set up rate limiting or any other
sort of
defense. (And as I mentioned previously, our ISP customers have
demonstrated no
interest whatsoever in administrative limits on redirect. And we'd
know because
it turns out the limit option wasn't documented.)
When I mentioned months ago
I could imagine many ways to solve this, coupling this type of thing
to the ability to do more than one redirect was one of the things
that seemed like a possible solution (and corresponds to my
understanding of at least some current deployments).
In conclusion, Alexey has proposed new text in a separate messagage
which
I find completely acceptable. Please take a look at that and let's see
where we are.
Ned