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.
"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.
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.
This is why you should always have MX backups which are capable of
rejecting mail to unknown users at the domain, for example.
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.
9) Lack of universal compliance.
although of course the way and degree to which these concerns mainifest
depends
on the exact scheme in question.
In particular, number nine does vary to a vast degree; so much so that
it should be considered a separate problem for some of them. There's a
big difference between a scheme which requires _universal_ compliance,
and a scheme which requires only the sending and receiving parties to
participate, without any need for the rest of the world to change.
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.
--
dwmw2