ietf-mxcomp
[Top] [All Lists]

Re: It it worth changing SMTP to deter joe jobs?

2004-05-09 14:09:17

Just one cotton pickin' second!  :)

I agree, we haven't discussed the 'is it worth it' question enough.

However, the thread I started about CSV+NBB (just earch for CSV in the subject) is all about this and how CSV (one of the LMAP proposals) imposes virtually none of the costs you complain about below, while (with some tweaks) accomplishing the important stuff that SPF+SRS(+RHSBLs, of course) accomplishes. Any thoughts on that? Basically, I argue why & how it addresses the joe-job problem and spam problem in general about as well as other proposals that cost way more.


On 5/9/04 7:33 AM, John Levine sent forth electrons to convey:

I realize this issue has come up a few times before, but it's clear
from the discussion that it still hasn't been addressed adequately.

[ with respect to roaming users ] The only question, then, is: Are institutions like IEEE/ACM able to
change their systems to interoperate in an LMAP-aware world?

That's not the question.  Of course they can change their systems.
They could set up outbound servers for their users, or in some flavors
of LMAP they could say that their mail can come from anywhere.  The
real question is whether the benefits of LMAP are worth the cost and
hassle to them and their users.  If it's not worth the hassle, it
doesn't matter whether they're able to make those changes, they just
won't.

I don't see much opposition to LMAP from those sites [whose domains
are forged], but instead only from domains not getting abused.

I suppose we all see what we want to.  Yahoo gets forged all over the
place, and they're interested in signatures, not LMAP.  My abuse.net
system should be a poster child for LMAP, since all the real mail
comes from two fixed IPs and it's forged in vast amounts of spam, but
I have yet to be persuaded that the benefits of LMAP are equal to its
costs.

I recently realized that I personally deal with all of the problematic
LMAP situations every day.  I have lots of remote users with mailboxes
here.  Some send mail through their own ISPs, while others use SUBMIT
and AUTH or ssh tunnels to use my outbound MTA.
All their

In the other
direction, my wife uses an alumna address at cornell.edu but sends
mail from here.  The main abuse.net setup is a mail forwarder that
remails messages from users domains all over the world.  I also have
indirect customers on other servers who send mail to their (quite
clean) lists using their own return addresses on other networks.

Having all this stuff actually running in production lets me come to
concrete conclusions about how much work it'd be to change it to match
up with various versions of LMAP, and how much benefit there'd be if,
among other things, the amount of abuse.net spam blowback decreased.

You know what?  As things stand now, and as they're likely to be in
the forseeable future, it's not worth it.  I am not thrilled that I
have to deal with up to 300,000 blowback bounces per day, but dealing
with them is a lot easier than all of the other stuff I'd have to do
if all of the bounce addresses had to be LMAP compliant.  The
abuse.net forwarder used to do bounce address encapsulation similar to
what's proposed for LMAP, but I stopped because doing so was far more
trouble than it was worth.  (The administrative burden of dealing with
third parties' bounces was far more than I expected.)
Being able to use the bounce address to route spam complaints would be
a minor benefit, but not a huge one compared to routing by IP address
or rDNS which is what I do now.  Spammers would adapt to LMAP as
they've adapted to every other anti-spam hack, so I don't expect that
the amount of spam would decrease.


Having said all this, I still think that the only way to find out if
network operators in general find LMAP worthwhile is to define a
version of it for people to try and let us know how they like it.  My
guess is they'll say that if they're going to make all these changes
to their mail systems, they'll want more benefits than IP-based bounce
address checking offers, but none of us knows.
Yes, for some LMAP proposals.

ASRG doesn't have the critical mass to get people to try stuff, but an
experimental or 0th stage standard RFC might.  If they find it useful,
or say it'd be useful with some changes (e.g., per user data), fine,
if not, we know it's time to move on to something else.  But I don't
think the details of the flavor of LMAP matter anywhere near as much
as having a stable proposal for people to try.
Except that the different flavors differ vastly in how much they cost to implement.
I argued in the thread that it's a couple orders of magnitude difference!
Again, we need to further discuss how successful various proposals will be at convincing early adopters and stragglers to get on board. E.g. if the stragglers are last not because they're lazy, but because they have vastly more work to do than the early adopters, it won't become feasible to reach the stage where noncompliant senders mail generally gets flatly refused (shoulds turn to musts).