[Asrg] where the message originated (was: DKIM role?) (SM)

[Ian Eiloart]

--On 15 January 2009 18:45:18 -0500 Rich Kulawiec <rsk at gsp.org> wrote:

> On Thu, Jan 15, 2009 at 04:13:20PM +0000, David Wilson wrote:
>> On Thu, 2009-01-15 at 14:57 +0000, Ian Eiloart wrote:
>> > > Depends on what that prevention requires.  ("Sure you can prevent
>> > abuse
>> > > of your domain.  You just need to enter into a bilateral agreement
>> > with
>> > > every receiving mailhost on the net.")
>> >
>> > No, you just need to sign your outgoing email, and publish SPF
>> > records.
>>
>> And make sure that you send from hosts which are permitted by your SPF
>> info:
>
> This still isn't enough to prevent abuse of your domain.  Let's make
> three assumptions, two of which (I think) you're advocating:
>
> 	1. Lots and lots of hosts that are backscattering today don't
> 	fix the fundamental problem (that is, they continue to allow
> 	their systems to bounce instead of rejecting).  Given how
> 	many mail system operators don't even know what backscatter,
> 	aka outscatter, is, and that some have openly declared themselves
> 	"required" to send it, this seems better-than-plausible.

True. I think there's a real need for serious education in how to manage 
email systems. I don't know of any formal course or qualification that you 
can take. Peer pressure can be effective, though. We've seen, for example, 
the end of open relays. We've also seen a lot of providers take up MSA - 
which is also essential to the plan.

> 	2. Lots and lots of hosts adopt something like SPF.

Yep.

> 	3. You -- the keeper of example.com -- set up something like SPF.

Yep.

> 	(Don't take any of this as an endorsement of SPF.)

OK :)

> Let's press on and have some fun with example.com, by way of
> illustrating what I said above:

There's no point to what you describe below, except to create a DoS attack 
on the MX host. Why? Because the messages won't get delivered to sites that 
use sender verification callouts. The callouts should be acceptable when 
there's an SPF pass for domains that are set up properly. Callouts are 
typically cached, which should mitigate the attack. It could be further 
mitigated by use of 5.1.2 replies "Bad destination system address", which 
tells the caller that the domain is incorrect. That means that the DoS 
attack is only good for a single message from any given MTA, you don't have 
significant amplification. In fact, even without any of these measures, my 
server isn't going to amplify your attack, because I'll only bounce any 
message once.

So, spammers should not be able to use this mechanism to deliver email. The 
DoS attack is an issue. Perhaps "reverse" MX records should be published, 
too. So, I can look up an IP address and discover whether it will accept 
email for a particular domain.

Why go to all that trouble when you've already got a botnet that's capable 
of doing the damage directly?

> 	A. I register throwaway domain a1s2d3f5g6h7.info.
>
> 	B. I arrange to have the domain hosted somewhere with, shall we
> 	say, less than stringent oversight.
> 	
> 	C. I set up DNS, including SPF, for a1s2d3f5g6h7.info.
>
> 	D. I send out a kazillion messages from user at a1s2d3f5g6h7.info,
> 	all of which will of course pass SPF checks.  They're addressed
> 	to a kazillion addresses at a kazillion domains.  Maybe some
> 	have malware attached.  Maybe some have boilerplate spam content.
> 	Maybe some are addressed to probably-don't-exist addresses.
>
> 	E. Some of the receiving MX's will reject.  Some will try to bounce.
>
> 	F. And this is where step (C) comes in, because I didn't point
> 	the MX records for a1s2d3f5g6h7.info at my own server: I pointed
> 	them at example.com's MXs.  That's where the bounces will try to go.
>
> 	Oh, sure, the MX's for example.com are rather unlikely to accept
> 	any mail for a1s2d3f5g6h7.info, because of course they're not
> 	configured to, but how do you think those MX's will react when
> 	a kazillion mail systems (nearly) simultaneously all try to
> 	open up connections on port 25 and start shoving mail at them?
> 	G. Since I did all this using someone else's credit card, money
> 	is really no object.  Repeat steps (A) - (D) several hundred
> 	times using diverse registrars, DNS services, hosting services,
> 	outbound message targets, etc.
>
> 	I can make this more interesting with some optional steps:
> 	use of botnets instead of host service, use of fast-flux DNS,
> 	pre-selection of hosts known to backscatter for (D), and/or
> 	making the putative sender of all these messages
> 	user at example.com.a1s2d3f5g6h7.info, which will confuse
> 	the hell out of a significant subset of people.
>
> 	Yes, this behavior will probably get each one of those domains
> 	and originating IP addresses of mine noticed and listed on various
> 	DNSBLs and RHSBLs relatively quickly, not that this will be
> 	much consolation to example.com while they're recovering
> 	from the DDoS attack.
>
> This is one of the more benign possible scenarios.  And yes, there
> are all kinds of ways to counter this particular one, but my general
> point is that anything that lets third parties cause someone's mail
> system to emit outbound SMTP traffic to arbitrary destinations is a
> cause for concern...which is why I think one of the easiest and most
> productive things we could and should be doing is getting our mail
> systems set up to always reject and never bounce -- or as close as
> we can, modulo edge cases I've discussed elsewhere in the thread.
> That doesn't really "fix" anything, per se, but at least it minimizes
> ensuing secondary and tertiary consequences, and avoids adding still
> more SMTP traffic to the excess we already deal with.
>
> ---Rsk
>
> _______________________________________________
> Asrg mailing list
> Asrg at irtf.org
> http://www.irtf.org/mailman/listinfo/asrg



-- 
Ian Eiloart
IT Services, University of Sussex
x3148