STARTTLS and sp*m (was: Re: current usage of AAAA implicit MX?)

[Michael Taht]

David Malone wrote:
> On Tue, Apr 15, 2008 at 12:12:06PM +0930, Michael Taht wrote:
>   
>> I implemented three ipv6/ipv4 dual stack email servers a while back. The
>> ONLY connections I've ever seen on it from the public internet have been
>> IPv4, except from my own machines.
>>     
>
> Excluding locals, I see about 100 different hosts doing incomming
> IPv6 SMTP each month for about 14K smtp sessions. Now, I probably
> see about 1000000 different IPv4, but I suspect alot of those are
> bots who try a couple of sessions and move on, as I only see maybe
> 5000000 smtp sessions in total.
>
> (I guess this is an indication that IPv6 deployment is higher among
> mail server operators than bots.)
>
> On the outgoing side, about 50 domains that we deliver to with IPv6
> SMTP over the last month.
>   
I am curious as to what sort of percentages are being seen with/without
STARTTLS encryption,
with or without a valid offer. (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)

With IPv6 perhaps we could convince a bot-battered world to get email
working "right" this time.

As "Joseph T. Klein" wrote earlier:

"The [email over ipv6] floodgates will open when gmail, yahoo, and
hotmail decide to take the plunge."

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.

 What (new or proven) practices could be put in place on the (currently
tiny) ipv6 email backbone to make it a better place for humans to
interoperate?

Perhaps this is not the right list for this...

Some thoughts:

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.

Pushing back the MTA into the clients (most linux distros still include
a MTA by default) would shrink the list of available recipients to
manageable levels on the client at the expense of hoping for correct
configurations on zillions of clients...

A webtool that checked the sanity of your ipv6 email configuration
(working certs, mx's, a postmaster alias, etc, etc) would be nice,
perhaps one exists...

Requiring reverse DNS to work would be nice but is a terrible pain to
setup for autoconfigured ipv6 clients (at present)

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....

Rotating mail servers around a set of ipv6 addresses, and
updating/expiring the mx record appropriately would "secure by
obscurity", making it much harder for a bot to find a working relay in
the first place, and ensure that only MTAs that actually look at MX
records get mail out - (however this technique could also be used by the
bad guys for sending mail, and makes greylisting harder)

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.


> To get you some test mail over IPv6, we need to get the cluenet list
> delivered over IPv6 SMTP ;-)
>   
The irony!
> 	David.
>   


-------------- 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/684d25e9/attachment.sig>