On 9 May 2004, John Levine wrote:
I bet that got your attention.
I can't help but note that the issues being hashed over here bear a
remarkable resemblance to the ones we were hashing over in the ASRG
LMAP group last year. If there were good solutions, we'd have found
them by now.
There are good solutions. It'll require changes of behavior for roaming
users and for some ISPs... But nothing as major as LMAP/MARID though and
much of that has already been done and well tested.
Last year there were three general approaches to the roaming user
problem, and they haven't changed:
A: Make roamers phone home to send their mail
Pro: can use standard SUBMIT and SMTP AUTH or tunnels, often there
are other reasons to do so anyway
Authentication with submit should be preferred option. In fact it should
be done no matter if its remote user or not. Changing behavior in this way
will go long way towards fighting spam.
I see bad disadvantage to adaption of above for roaming is that some
roaming networks proxy all SMTP connections to their own servers and then
AUTH would fail. We should write something up that says that during client
email submit if SMTP AUTH is chosen as preferred option but fails, the
client email system should try sending email without AUTH (rather then
immediatly give failure notice). In that case if smtp is being proxied
and SMTP AUTH to home server fails it may still work going through this
proxy in normal way. Another option is to allow for such smtp proxy servers
to also proxy authentication to remote SMTP server, that would require
having SMTP client provide name of the SMTP server it actually meant to
authenticate with (simplest way to do it is to have authentication token
include domain or server name, i.e.
"username(_at_)mailserver(_dot_)domain(_dot_)com"
rather then just "username" is sent as part of SMTP AUTH)
Con: requires config changes or upgrades so that home servers
support roamer access, reconfig roamer MUA's ot network config to
call home. Some setups like acm.org have no home servers.
For last several years email client programs have included ability to do
simple SMTP AUTH. So do many servers even if its not enabled by default.
I believe by now more then 50% of the users maybe ready to do SMTP AUTH
if it were required of them.
B: Poke holes in the rules big enough for roamer mail to get through
Pro: roamers can send mail just like they do now
Con: bad guys will use the same holes, don't have enough LMAP
experience to predict how much spam and phish will get through but
it could be a lot.
It depends on what kind of "holes" were talking about. Its also important
to point out that if we force domains and ips used during email session
validation to have tie-in to specific ip address or other way around
(for whitelisting of email going through) it will make tracking abuse
easier and help in "legal solution" to spam as it would provide record of
prior intent to use somebody else computer and tie in specific spammers
to specific zombie computers.
C: Use a bounce address from the network where mail is sent
Pro: can be implemented in the (relatively few?) MTAs on systems that
host roamers.
Con: how to get bounces back to actual sender is non-obvious,
Not at all. If the implementation is on "relavively few MTAs that
host roamers" we can make a special spec for them on how to write these
bounce address that identifies actual sender. This is what SRS from SPF
group has been about if I understood it right. But the problem is that it
really is not so "few" MTAs that would need substantial modifications
to undetstand this new roaming user bounce address format.
privacy issue since it publishes roamer's actual location
Oh, come on, the privacy issue should be least of our concerns. Right now
if they roam and send email from that roaming location, their ip is right
there to identify possibly roaming. For those few that have such "privacy"
concerns available is VPN to home location or webmail client provided by
their home mail server.
These are the options if you want to validate senders by IP.
Which is not to say there aren't other options available.
Such as perhaps using PGP or S/MIME to provide certain verification and
trace record of user's identity or other crypto based mechanisms
(yahoo domain keys might be one if I ever get to see their specs)
And remember it does not have to be one and only one option. If we leave
certain "holes" in LMAP that allow to mark email as "suspect" and then
have something else in the email that allows to validate the user based
on signature for example, then it may well work.
Maybe the roaming and forwarding issues and the ease of mismatching
envelope and header sender address will be a killer. This might push
people toward signature systems which can deal with roamers in
straightforward ways. I know at least two that should have draft specs
and sample code available within the next month.
I'm assuming one is yahoo domain keys. Which is the other one?
But at some point you just have to pick the least bad option and go ahead.
It seems to me analyzing potential impact of these solutions would be good
task for research group, ASRG to be more particular (although doing it as
part of MARID is also possible). Is one of these groups willing to do some
kind of official document on various issues and solutions to roaming user
and forwarding problems and provide a document about it to internet community?
If you answer yes to above, it seems to me we need to do the following:
a. Analyze proposed solutions seen to SMTP identify theft problem
(LMAP options being considered that rely on validating MAIL-FROM or
EHLO do not really do much in fighting spam but only focus on improper
use of your domains in spammer emails but in my opinion that is
already good enough reason to have ASRG work on it considering it
provided original LMAP document). This is not anything new, mostly
this info is already available and even listed as part of each spec,
just make sure to create nice chart on which proposal will create
problem for which type of users. LMAP discussion draft has done some
of it already I think.
b. Analyze each type of user problem that listed above. and list possible
solutions (see A, B, C from John's original post) and which of these
A, B, C solutions will solve which problem then list of CONs for
each solution and possibly assign certain values to difficulty in
implementation and adaptation of each solution. Again nice chart
would help...
If proper research is done on possible effects of proposals and solutions
perhaps we can then see more clearly which one (or combination of several)
is least "undesirable" and pick it as one to use for the future.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net