STARTTLS and sp*m

[Michael Taht]

Tim wrote:
>> (Postfix has a sane setting:
>> "smtpd_tls_security_level=may") which  tries initiating TLS if a
>> STARTTLS offer is recieved, then falls back to plain text if that fails)
>>     
>
> OT: Is that really sane?  
Got to start somewhere.
> What is your goal in using TLS with email? 
Prove out interoperability of various MTAs.  Annoy the men in the
middle. See who else has implemented TLS. And: To hope that a sufficient
number implement it to one day turn the knob up to the next level.
> Is
> it to protect the contents?  Authenticate the source server?  If an
> attacker wanted to read the mail and STARTTLS wasn't required, he could
> just strip that option from the initial conversation and Postfix would
> accept the cleartext communication.  What's the point in supporting
> STARTTLS again?  The same goes for man-in-the-middle attacks with
> unvalidate certificates.  It really is an all-or-nothing venture, using
> TLS in this case.  Opportunistic encryption here provides no security
> without authentication, and merely slows down communications all the
> while providing a false sense of security.
>
>   
It's not quite that black and white, as per above and below.
> Do I use STARTTLS?  Sure, but I require it's use between hosts I have
> authenticated.  Do I allow opportunistic encryption with it?  Sure, but
> only because it causes mail to be stamped with a few key words that my
> bayesian filters might benefit from.  
I use it for the same reasons.
> My point is, once the spammers
> feel TLS will help them, they'll just connect and anonymously spam with
> TLS.  We're in the same boat.
>
>   
Anything that increases the computational or memory footprint of a
spambot aids detection and removal. Also, known spammer certs could be
blacklisted just as we blacklist via rbls. Generating new certs takes
non-trivial time and cpu.
>   
>> With IPv6 perhaps we could convince a bot-battered world to get email
>> working "right" this time.
>>     
>
> I'm all for that, but unfortunately there isn't much fundamentally
> different about SMTP over IPv6.  More on that in a minute.
>
>   
I tend to think SMTP needs to go away, but by myself I can't think of
what could replace it. To a large extent, email has been replaced by IM.
I probably could abandon email entirely, actually, only cutting myself
off from the very few that I know that rely on it.

My point about IPv6 and SMTP was not that IPv6 had anything in it that
made the spam problem simpler, it was that the current number of the
ipv6 email MTAs  was small enough to perhaps develop some "best
practices" - something more coherent to cope with email issues such as
spam, authentication, crypto, etc, etc.

This is pretty OT for this list, but solving it here would help increase
ipv6 adoption.

(although your cookie-in-ipv6 idea is interesting, I'll get to that in a
second email)
>> If they took the plunge now, it would be worse than eternal september;
>> it would be "bot heaven", as the existing rbl mechanisms would fall over
>> and die.
>>     
>
> Well, yeah, if a lot of ISPs and other services started supporting IPv6
> but had no RBLs to support it, there would be a problem.  I imagine any
> large mail provider that took the plunge would have some mitigations in
> place before doing this though.
>   
Sure hope they share those... When I think of all the worldwide effort
spent fighting this rearguard action in the spam battle, I wish that we
all had an extra 10% to think about winning the war.
>> Greylisting helps, but the explosion of email address/ipv6 tuples would
>> swamp most databases. Perhaps weaker greylisting, based solely on the
>> email address, would help.
>>     
>
> Greylisting itself works ok right now, but slows down mail and I suspect
> will become less effective in the future.  If everyone were using it,
> the bots will just try multiple times.  It's inherently a tit-for-tat
> game.  You're shooting yourself in the foot a little bit right now
> (slower delivery of initial email, having to track sources, etc) and
> it's currently working because most spammers aren't bothering to get
> past it.  When they do try to do it, their bots will only be getting
> hurt as much as you're hurting yourself (within a costant factor of
> course).  At that point, one might as well throw it out.
>   
The goal is to expend less effort on defense than the bots can spend on
offense.

Turning a "drive by shooting" - a classic spam attack without greylisting
into a "stalker attack" - I think will always be a good thing.

Having bots repeat a spam attempt gives more time for more defense
mechanisms to kick in.

>> Requiring all email connections be auth/crypted via starttls would (at
>> the very least) increase the footprint of an ipv6 capable bot... but
>> would annoy certain agencies of 3 letters....
>>     
>
> See above.  The 3 letter agencies wouldn't be bothered much, since they
> can just MitM stuff if they really need to with most server
> configurations.
>   
Well, the endgame would give them a headache, but I imagine that they
are just as sick of spam as civilian sysadmins.
>   
>> On my bad days I tend to write off email as a good idea overwhelmed by
>> events, and that we should just give up on it, and outsource it all to
>> gmail et. al.
>>     
>
> It is becoming increasingly painful, isn't it?
>   
I don't want to talk about how I spent last Christmas day.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20080416/91842cd0/attachment.sig>