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).
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.
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 there's no guarantee that
the _incoming_ addresses of the cluster are the same as the outgoing
addresses.
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.
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.
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 :)
I'm not familiar enough with SES to comment. Sounds like I should spend
some time on it, though.
Agreed.
--
dwmw2