[105447] in North American Network Operators' Group
RE: Cloud service [was: RE: EC2 and GAE means end of ip
daemon@ATHENA.MIT.EDU (Frank Bulk - iNAME)
Mon Jun 23 22:36:02 2008
From: "Frank Bulk - iNAME" <frnkblk@iname.com>
To: "'Joel Jaeggli'" <joelja@bogus.com>
In-Reply-To: <4860104F.6030109@bogus.com>
Date: Mon, 23 Jun 2008 21:35:49 -0500
Cc: nanog@merit.edu
Reply-To: frnkblk@iname.com
Errors-To: nanog-bounces@nanog.org
Right, port 587 would require SMTP authentication.
I'm no routing expert, but can tens of thousands of /32s be excluded using
BGP communities?
I don't know if spammers are going to be using TLS in a big way soon, though
I'll admit I've not measured. As long TLS usage is low, examining TCP port
25 traffic would likely be effective without redirecting SMTP traffic and
making it effective for all customers downstream.
Frank
-----Original Message-----
From: Joel Jaeggli [mailto:joelja@bogus.com]
Sent: Monday, June 23, 2008 4:06 PM
To: frnkblk@iname.com
Cc: nanog@merit.edu
Subject: Re: Cloud service [was: RE: EC2 and GAE means end of ip address
reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)]
Frank Bulk wrote:
> Thanks. Even with TLS, the destination port (either 25 or 365) is
> well-known, right, as is the source IP?
And 587 though that's generally your customers, who are going authenticate.
> At the minimum RBLs could be used
> for that encrypted traffic.
Yeah, given that that point you're basically filtering by ip again, you
can do that with a bgp community. That's not really smtp filtering anymore.
> Frank
>
> -----Original Message-----
> From: Joel Jaeggli [mailto:joelja@bogus.com]
> Sent: Monday, June 23, 2008 2:20 PM
> To: frnkblk@iname.com
> Cc: nanog@merit.edu
> Subject: Re: Cloud service [was: RE: EC2 and GAE means end of ip address
> reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)]
>
> <snip>
>
> dpi boxes from a number of vendors can do that sort of thing... whether
> they can do it fast enough to be inline with your compute cloud is
> another question entirely.
>
> That said the result is fairly perilous when rejecting a message
> involves forging packets. and of course tls supporting mta's will be
> opaque to the network traffic inspecting device.
>
>
