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

[Dean Anderson <dean@xxxxxxx>]

On Sat, 4 Dec 2004, David Woodhouse wrote:

> 
> On Fri, 2004-12-03 at 15:40 -0500, Dean Anderson wrote:
> > Agree with all except the "port < 1024" part. Back in the old days, when
> > computers were significant resources, this was probably implied a person
> > (eg system admin with root) responsible for a valuable asset. But today it
> > can be assumed that "port < 1024" does not imply anything.
> 
> Still it can be assumed that "port < 1024" implies a user with admin
> rights for the machine with that IP address. So if an IP address of a
> server which also has user accounts is listed, it would make some sense
> to indicate that connections should come from a privileged port.

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. 

Mainly, I'd prefer not to have to remember that IMAP is port 52345. So,
I'd prefer that protocols be assigned low ports. But this is the "listen"
port. I'm not terribly concerned about what port numbers clients connect
from.

> > "Blowback" is the bounces that you get when a spammer forges your address 
> > as the From: address. Much of the spam run will be delivered, but what 
> > isn't, will be bounced.
> 
> Generally, what isn't delivered should be rejected by the first
> recipient it's offered to. It never leaves the spammer's machine and
> there's no bounce.

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.  The relay
information is something that customer gets along with their account
information, and while not secret, its location on a compromised machine
depends on the mail software being used. In other words, the 
spammer/virus/worm operator has to search for it. Much easier to send 
directly.

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. 

> > ISP customer Spammer posts mail to that ISP's relay with a forged return 
> > address. The recipients reject the message due to SPF. Now the relay sends 
> > a bounce to the "from: address".   This message is from the Relay, which 
> > will be valid.  So now instead of a a few bounced messages, you get a 
> > bounce for every message blocked.
> 
> When spammers abuse open relays or ISPs run without any form of antispam
> measures, allowing similar abuse of their own relays, this is indeed
> possible. It's not caused by SPF alone though -- many forms of spam
> checking may cause it, and even the rejection of mail to unknown
> addresses at the destination site. This is a problem with any system
> which attempts to store-and-forward without an authenticated source
> address, and without knowing that its anti-spam policies are at least as
> strict as the next recipient.

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.

> 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 also a problem which, at the victim's side, is trivially fixed by
> implementing SES -- you instantly stop accepting the bounces to mail you
> didn't send.


> > Right. Except that there is typically 3 or more parties to email: The
> > sender, the relay operator, the mailbox operator, and the recipient.
> 
> Yes, that was precisely my point. A useful scheme would be one which
> works properly when it is implemented only by the sender and the
> recipient, and nobody in between.  In fact SES goes one better than that
> -- it actually works to a large extent, allowing you to reject bounces
> to mail you didn't send, when implemented solely at the 'sender' site.

I'm not familiar enough with SES to comment.  Sounds like I should spend 
some time on it, though.


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