Re: A new SMTP "3821" [Re: FTC stuff...........]

On Mon, 6 Dec 2004, David Woodhouse wrote:

> On Mon, 2004-12-06 at 13:28 -0500, Dean Anderson wrote:
> > Just about everyone has admin rights over a machine these days.  Some few 
> > machines have such rights limited. But even then, that's no indication 
> > that the admin is responsible or trustworthy.  Not that I guess I feel 
> > very strongly about it either way.  But, certainly, spammers can get port 
> > < 1024 if they want. 
> 
> I think we're talking at cross purposes here. I'm suggesting that one of
> the flaws in the SPF draft -- that anyone with an account on a machine
> which is listed can send 'authorised' mail -- could be alleviated by
> having an _option_ to say that mail is only authorised if it comes from
> a privileged port. I'm not suggesting that one should trust all mail
> from a port < 1024 and not accept any from unprivileged ports, because
> those with admin rights are 'responsible for a valuable asset' (to use
> your terminology).

Not at cross purposes. I understand exactly what you mean. However, for
all practical purposes _anyone_ who wants to send mail has already or can
obtain administrative control over their machine.  Put another way, nearly
all mail is sent from PC's or some sort of appliance-like machine.  The
sender and the "administrator" are the same person.  They can send from
any port they want.  Sending from a port < 1024 means nothing.  

Last night, though, I did think of one reason this isn't such a good idea:  
Most unix/linux machines still enforce a requirement that to open a port
less 1024 one must be root. This is a remnant of the days when machines
were expensive, and it was thought that having "privileged" ports was a
security feature. Presently, many mail systems give up root privilege as
soon as possible to reduce root exploits, and so that mail queueing on
such machines is performed by unprivileged processes. 

Putting your requirement into SPF would necessitate either removing the
ancient "privileged ports" enforcement from the Linux/Unix kernel
altogether, or reducing the security of the system.

Non-linux/unix systems usually don't implement any notion of "priviledged
ports". Even on Unix/Linux systems, its generatlly been more of security 
flaw than a feature.

> > This is only true if no relay is involved.  Every spammer has the right
> > (at least until their account is terminated) to use their ISP's relay, if
> > the choose. I think at present spammers and viruses send directly because
> > it easier than figuring out the right relay to use at the ISP.
> 
> And also because ISPs do rate limiting and spam checking on outgoing
> mail.

This is another myth.  It is extremely difficult (to the point of
practically impossible) to do rate limiting on outbound email for mail
systems of any size.  There was a rate-limiting freeware posted on the net 
some time ago, but it didn't work.

I know of no ISPs that do Spam checking on outbound email, either.  The 
notion of 'what is spam' depends on the recipient, not on the sender.

> > Ironically, SPF makes this problem much easier for the virus operator, by
> > identifying the outgoing relays in DNS.  These are the same relays that 
> > will accept outgoing customer email. 
> 
> Not necessarily. You may need SMTP AUTH and 

SMTP AUTH does not help. That information is already on the compromised 
machine. Or if its a disposable account, then it was given to the spammer.

The spammer/abuser has _ALL_ the privileges and capabilities of the user 
of the ISP.  

> there's no guarantee that the _incoming_ addresses of the cluster are
> the same as the outgoing addresses.

There is no guarrentee other than the economics that ISPs don't buy
unnecessary mail servers.  Mail servers are expensive, and cost money to
operate and maintain. Separating inbound from outbound mail servers makes
sense becaue the inbound mailservers have extra load of the mailboxes, and
creating a separate set of outbound mailservers conveniently helps
distribute load.  But one would be unlikely to put in additional
unnecessary layers.  Economics would soon reverse such a decision.

> > Yes, this is true of traditional address forgery. People forget that there
> > is no difference between open relays and closed relays, except that closed
> > relays only accept email from a particular address range.  Spammer always 
> > has a relay available if they choose.
> > 
> > But with ordinary (non-SPF enhanced)  forgery, the forged recipient
> > usually only gets _SOME_ bounces.  With SPF, they get _ALL_ messages sent
> > by the spammer/abuser.  This was one of the problems stated as to be
> > solved by SPF. SPF doesn't solve it, but makes it worse.
> 
> Not really. Hardly anybody actually rejects for an SPF failure anyway.
> You can't -- you'd throw away too much valid mail.  But you could say
> the same for _any_ spam filtering. SpamAssassin makes it worse far more
> than SPF does, because _far_ more people will reject for having a high
> SA score than they will for SPF. You're right, but I think it's a red
> herring. It's going to be the case for _any_ scheme which causes mail to
> be rejected by the ultimate recipient, when the relay may have accepted
> it.

Yes: You can't reject bcause not everyone uses SPF.  But the _goal_ of SPF
is to /reject/ forged mail, and thereby prevent forgery.

	SPF rejects forged mail
	We can't use SPF to reject email
	thereore, we have no rejection problem.

This is only true as long as no one uses SPF to reject mail. But if no one
uses SPF to reject forged mail, then it didn't prevent forgery.

If you use SPF to reject forged email, it is now trivial for the abuser to
arrange for 100% of the bounces to hit the forged sender's mailbox.  That
makes the problem _much_ worse. Spamassasin doesn't do anything like that.

Its only "not worse" if SPF isn't used.  And to the extent that SPF is
used, its made worse. Suppose yokel.com starts rejecting mail based on SPF
records. Now, abusers can forge mail to to yokel.com. Yokel.com rejects
the mail, and the target gets 100% of the email.

I saw exactly this sort of abuse of open relays. Abusers would queue up
mail to a domain that blocked open relays. The relay then bounced every
message.  Through testing with different IP addresses and detailed
logging, I found that the abuse was usually performed by people associated
with open relay blacklists.  I've learned a lot over the years about open
relay abuse and abuse detection.  I'll just summarize that the most
effective tool was to block the open relay blacklists. They were the only
ones scanning for open relays.  Abuse only happened after the blacklists
successfully scanned a relay.  Preventing the scans prevented the abuse.  
Finally, the blacklists shut down, and abuse dropped off almost 
completely.

SPF basically turns every relay into an open relay, and allows the same
sort of abuse, only worse, but without the need to scan for open relays.  
If one were to determine authorship of SPF by its effects, one would think
that open relay abusers wrote SPF.

> > > This is why you should always have MX backups which are capable of
> > > rejecting mail to unknown users at the domain, for example. 
> > 
> > This doesn't help with forged mail targeted at an existing address, which 
> > I think is the goal of SPF/Sender-ID. Rejecting mail to unknown users is 
> > implemented without SPF/Sender-ID. Its the forged mail to real users that 
> > causes the subject problem.
> 
> It's just another example of the general case -- anything the primary
> will reject, the backup should reject too. That's why you should be
> running identical spam and virus checking, for example.

I agree that its not necessarily specific to SPF. 

> You're right, but it's still not specific to SPF; that's all I'm saying.
> Give me a break here -- it's rare that I defend SPF, utterly broken as
> it is :)

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000