-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Friday 23 July 2004 09:48 am, Paul Howarth wrote:
Jonathan Gardner wrote:
On Thursday 22 July 2004 04:03 pm, Jef Poskanzer wrote:
Jonathan Gardner <jonagard(_at_)amazon(_dot_)com>:
SPF does indeed solve the spam problem. SPF will bring spammers to
justice.
Wrong and wrong.
Please refute my arguments. Just telling me I'm wrong won't show me
where I went wrong. I laid out my chain of arguments most clearly, and
I want to see where I'm wrong, or at least where we disagree.
I've been away for a couple of days and haven't yet caught up on my old
emails so apologies if I'm re-hashing something that's been done to death
recently, but:
how does SPF stop a spammer using throwaway domains with SPF records
allowing any zombie to send for the domain, where the domain was
registered using false information and phished credit card details?
The registrar shouldn't be registering people with false information. Any
registrar that does should be held accountable.
How do we hold registrars accountable? Punish the registrar with the law.
Revoke their rights to be a registrar. Blacklist all the domains registered
by that registrar.
A registrar that knowingly cooperate with criminals are accomplices. They
will get the book thrown at them when the criminals get theirs. They will
be held just as accountable by the community as the spammers. I think
registrars will think twice before registering criminals when they realize
(A) they may serve time and pay huge fines (B) the rest of the domains they
have registered will be blacklisted.
If they used phished credit cards, then all of a sudden the stakes got
higher. They are committing a serious crime and when the hammer comes down,
it is going to come down hard. Now instead of just email system
administrators that want these people punished, we'll have credit card
companies on their tail as well. I encourage spammers and criminals to
commit more serious crimes. That way they will pay larger fines and stay in
prison longer. It will also make them easier to track down and convict.
If they are using someone else's virus infected machine, it won't matter. We
won't abandon the IP based reputation system we have now - only add on top
of it. Notice that AT&T (or whatever they are called - Comcast?) has
seriously cleaned up their act?
We can also do things like not accept any email from domains that have
recently registered, or subject such mail to extreme scrutiny.
(Grey-listing) Only those people who have shown themselves to be
responsible will get a free pass to the inbox.
If we do this, the spammers have to spend significant resources turning
their grey-listed new throw-away domains into golden trusted domains. That
is not easy. It takes a serious investment of time and legitimate, real
email. You can't fake that. (If you do, you will get caught. For instance,
at eBay, they buy and sell AOL CDs to raise their reputation. Guess what?
That's a red flag.)
Accreditation services can come along and move you into the golden zone for
a fee. Of course, the accreditation services will have a level of trust, or
their word won't matter. If the spammer goes to a trusted accreditor, then
the accreditor will verify their information (or we wouldn't trust it,
would we?). When they spam, we will have a trail through the accreditor.
If a spammer sets up an accreditation service, then they will have to spend
significant resources building up the trust of that service. When they
finally use the domains accredited by that service to spam, we will lose
trust in the accreditation service. In fact, we will assign negative
reputation to domains accredited by that accreditor. (Oh, you are
accredited by WeAccreditSpammers? Then your mail goes into the black hole.)
Also, the people involved in establishing that accreditation service will
be well-known to the community. Nothing makes it easier for the feds to
lock you up than when you commit fraud on a large scale.
- --
Jonathan M. Gardner
Mass Mail Systems Developer, Amazon.com
jonagard(_at_)amazon(_dot_)com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFBAUdnBFeYcclU5Q0RAuibAKC7+CKoR8dDzLhI+OjfE5vn6MMqNwCfdxHD
nmgTailFQtNjuu/bJXxuZGI=
=4M5p
-----END PGP SIGNATURE-----