In any case, this is not the major case, because how many times has your
address been forged recently?
Well actually, I get a fair amount of mail from my own address as well as
randomly generated users at my same domain name. If both of these were
blocked as forgeries that would be a significant difference.
That is priority for spammer to try (because it gets past many whitelists) and
trivial to filter. You do not need SPF of SenderKeys for that.
Filter all email from yourself. If you need to send email from yourself, then
use a tunnel password, send to secret address which forwards back, or some
other simple mechanism.
Your blacklist should be told which other address are valid on your domain.
Once my address was being used as the sender address for a bunch of spam,
and I did receive about 700 bounces over the period of a week or so.
Yes that happened to me once months ago or perhaps it was last year. And
similarly it stopped. I think the spammers found out that was not effective.
I have not seen it since.
It
was frustrating and I was emailing different abuse(_at_)interbusiness(_dot_)it
addresses, but I think it just ended of its own acccord.
If it continued, then you (and I) would have needed SPF or SenderKeys from
perspective of a sender. Mostly right now, SPF is needed by anti-spam
recipients more than it is needed by senders. The only senders who need it
real bad are the corporations being phished.
This goes right back to my economic analysis of adoption...
You are defending SenderKeys with features of AccuSpam!
Not intentionally.
As I said, think of SenderKeys as:
1. No SenderKey header, then authority sends private key back to sender mailbox.
2. If MUA that reads the mailbox is SenderKey aware, then SenderKey is
automatically enabled for sender.
3. Else sender reads a message explaining how to upgrade his MUA.
Simple.
Nevermind what the verifier does with the SenderKeys answer, just as we can
nevermind what the verifier does with the SPF answer. Verifiers see a
SenderKeys header, they ask authority for public key, so they can compute the
answer, just as they ask DNS for IPs in SPF so they can compute the answer.
You should prefix
these with "when used with AccuSpam...". I don't need SenderKeys to get
the benefits of AccuSpam, and I shouldn't need AccuSpam to get the
benefits of SenderKeys. If you want to merge the two ideas, perhaps this
could be called AccuSpam+SenderKeys or whatever new name suits.
Correct. I am trying to do that, it is just that I am being asked questions
that lead that direction.
The degree and volume (not you) of misunderstanding and oblique accusation
makes it somewhat difficult to respond in perfect orthogonality of AccuSpam and
SenderKeys. I am trying to make it clear they are orthogonal.
I wasn't being precise enough, I'll amend it: if the receiver uses
SenderKeys, but the sender does not, the receiver is not protected from
that user's spam.
Well in the same sense that if receiver does not use SPF, then receiver is not
protected from that user's spam.
But bear in mind, that verifiers may use multiple algorithms and techniques to
stop spam, just as they do now. But agreed, this is orthogonal to SenderKeys,
just as it is orthogonal to SPF.
If the sender uses SenderKeys and receiver does not,
the receiver is again unprotected from spam using that user's forged
address (by SenderKeys).
Yes in the same sense that if we replace "SenderKeys" with "SPF" in above
paragraph.
Thus they have to fall back on their other
anti-spam & anti-forgery solutions (AccuSpam or spamassassin).
Or SPF or ... Yes agreed. SenderKeys is just like SPF in this regard.
This is the same as SPF, though, you're right: both parties have to
implement SPF (in DNS for senders and in the MTA for receivers). There
are fewer parties involved with SPF though, and they are more tech-savvy.
I think actually it is almost the same, except one big difference.
In SenderKeys, the sender has to upgrade his MUA. In SPF "-all", the sender
has to upgrade and/or configure his MUA in most scenarios (we can debate this
okay to make it clear okay?).
In SenderKeys, some people have to establish authorities and these are tech
savvy, just as the receiving MTA are done by tech savvy for SPF.
The difference is that for personal domains, the sender has to do nothing more
for SenderKeys, but for SPF they have to do DNS configuration (and
maintenance!) and they will very often not be tech savvy.
But the bigger difference is in the ongoing use. With SenderKeys, the user
just chugs along ignorantly with his SenderKeys enabled MUA. Upgraded once and
forget it. But with SPF, the sender may change ISPs (need to update DNS
record), change email programs (need to reconfigure for SMTP AUTH), change or
buy new domains, etc.. All of these things require no ongoing maintenance with
SenderKeys, as it is automated *FOREVER* once vast majority of MUAs are.
This ongoing cost is going to kill SPF as explosion of use of domains occurs,
just as maintaining DNS will become more nightmare with the explosion of
available IPs in IPv6. SPF is fundamentally flawed for this purpose because
the granularity of domains is actually more than the granularity of DOMAIN x
IPs is more than MUAs looking into future.
As a said, SPF is perfect for solving phishing and for first line of defense
(without "-all"). Widespread "-all" is impractical for many, many reasons.
Eventually we all will face that reality. It is difficult to accept that SPF
can not be the end all solution, but if we can get past that and we can start
to apply SPF more aggressively where it is best and develop the solutions for
the rest of the cases.
There actually was wisdom in the original SMTP (as proved by the fact that
email is most popular application in the world). You should be very careful
not to break it. I think it is better to keep the freedom of SMTP and fix the
problem of forgery with SenderKeys like mechanism.
The only reason I am interested in SPF is to decrease my spam reception.
Agreed. Senders do not have much motivation, only receivers of forged spam do.
That is another reason why widesread SPF "-all" will not happen.
If I wanted receivers of mail to be able to ascertain that I was truly the
sender of a message, I would use PGP.
Are you saying you do not like SenderKeys because you want your receivers to
still have some doubt whether you are being forged?
Because the goal of SPF "-all" is to tell your receivers whether you are truely
the sender (well within any possible sender on your IP which in all likelihood
is true else we could not delete forgery on SPF "-all"). It is circular logic.
As soon as messages are blocked instead of being delivered with a security
warning, you've converted an anti-forgery system to an anti-spam system;
albeit by considering forgeries to be unwanted/unsolicited email.
You just wrote that you want to reduce your spam. Wouldn't that include
deleting forged emails?
Remember that SenderKeys is no different than SPF in that verifiers can decide
how to dispose of a message. SenderKeys verifiers can also be at the MTA and
mark a message as "Security Risk" if you prefer.
- SenderKeys allows an address to be whitelisted only if its messages
are
cryptographically signed
SenderKeys has nothing to do with the decision of what gets whitelisted.
Sorry, I'm using the word 'whitelisted' when perhaps I should have said
'bypass filters' ?
Verifiers decide what to do with the SenderKeys answer, just as they do with
SPF answer. There is nothing special about SenderKeys in that regard that is
different than SPF.
- SenderKeys can be installed without adminstrating a server (except the
authority server, perhaps)
Yes but much less authorities needed as compared with SPF DNS records.
I think the operation of the authorities deserves some elaboration.
They seem to be responsible for:
1. Deciding what to do with unsigned messages
No. Verifiers do that just as they do with SPF.
2. Providing private keys & authority urls to SenderKeys users
Yes. Think of authority as the DNS databases for senders instead of domains.
And SenderKeys has a mechanism for automatically configuring the MUA of a
sender from an email from an authority.
3. Backing the authority URL in some way (website?)
Or certificate as mentioned in the Overview. Or simply reputation, since
verifiers (e.g. Spam Assassin, AccuSpam, SourceForge projects, etc) will
probably know who the popular authorities are.
This area of the specification is more open at this time to input.
- SenderKeys uses cryptographic signatures to identify the sender, SPF
uses the IP address of the delivering server
Correct. Very important point because for example this is why SPF
breaks forwarding and SenderKeys does not.
Perhaps you can elaborate on this point?
If I use forwarding to deliver mail (e.g. I delegate mail delivery to some
other mail server) then I can add that mailserver to my SPF record.
As a sender yes you can do that. But as a receiver you can not. For example
(and there are many, many others), some sender goes to a website submission
form and sends you one of those cutsy messages "I like this web site, come
check it out". Or think of greeting cards, etc..
You and I might think that crap is spam, but there are 10 million AOL users who
will mace with you with hairspray if you mess with their beloved hobbies and
daily email fix.
If I use forwarding to receive mail (e.g. I have an external SMTP server
relaying to internal mailboxes on seperate servers) then I can check SPF
on the first server the mail arrives at.
As stated above, you can not know all the IP address of all the web submission
forms that could forward you can email from a sender.
Is there some other kind of forwarding you are thinking of?
Yes see above.
Also a mailing list. You and I might be savvy enough to add the mailing list
to our DNS (what a maintenance headache), or some verifiers might whitelist
mailing lists (but then they become open relays for spammers), but your average
Joe User just goes to mailing list and sends and then wonders why (probably
*SILENTLY*) half the list did not receive his email.
You want me to try to think of others?
In essense, AccuSpam is ...
not SenderKeys?
AccuSpam is the verifier.
SenderKeys is the specification of how authorities, verifiers, and senders/MUAs
interopt. SenderKeys gives great flexibility to what each of those do within
the protocol of that interaction.
And I am saying it is going to very, very difficult to get "-all" for
all domains. Much better to have a sender granularity, since it is the
sender that is most harmed by forgery of his address. Realize that an
ISP can not "-all" until **ALL** (every single one) customer has been
confirmed to be using exclusively the mailservers of the ISP.
The sender is only protected from forgery when all receivers also have
SenderKeys.
Ditto for SPF.
How is the ISP going to confirm that?
Here's a way: disable mail delivery; when they call to complain, explain
how to set it up. Users usually notice within a short time if their mail
has stopped functioning.
That does not guarantee that Joe User does not go type his ISP email address
into From: line in some free email webmail (e.g. hotmail, yahoo, or zillion
others) when traveling without his computer.
With SenderKeys, the webmail will know it must check the sender's mailbox
before sending.
With arbitrary website submission form, both SenderKeys and SPF fail. I do not
have a good answer to that one, because I do not think users will give their
mailbox password to an arbitary website form.
Thanks,
Shelby