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