spf-discuss
[Top] [All Lists]

Re: Opening Debate on SPF vs. SenderKeys

2004-08-20 17:48:13

That we can debate.  POP gained traction.  Without MUA traction, how  
will you ever get SMTP AUTH?  Without SMTP AUTH, how will you get "-all"  
for SPF domains?  Without "-all", how can you detect forgery with 100%  
certainty with SPF?

You can implement "-all" for SPF domains, without using SMTP AUTH, when  
all users of the domain send email from a webmail interface, or from an  
"internal" IP address.


Agreed on WebMail exclusive providers.  In fact we do not really need SPF for 
that, I already do a specialized reverse dns lookup on hotmail and yahoo and 
assume that:

Agreed also on "internal" IP address, such as email sent exclusively from 
servers, but once you start talking about humans, e.g. the human users of an 
ISP or the human users of a corporation, you really can not be sure they will 
always use the "internal" IP address.  You simply can not know when a human 
will type his email address into a "From:" line in some MUA that you did not 
expect.

Thus these cases are infinitesimal relative to all the possible domains 
spammers are licking their lips to forge.



Domains which cannot implement SMTP AUTH or do not meet these criteria,  
will not use "-all" and will thus forged emails from their domain will not  
be stopped by SPF.


Agreed.  That is where SenderKeys can complement.  And these will be very 
numerous.  In fact, right now I think it is like on the order of 10 million / 
7000.  And that is not accurate because the 7000 is not "-all".  I do not know 
what the "-all" number is right now, do you?

Of course SPF will spread, but I think it will always be at least a factor of 
10 or 100 to 1.



Blacklist-based systems don't stop SPAM.


Here you are evaluating SenderKeys in terms of the authority's algorithm  
for when to auto-respond.  What you assume is that for example, AccuSpam  
is blacklisting individual addressses, which is not the case.  AccuSpam  
is counting the disapproval vs. approval ratio for a domain, then if it  
is a spammer domain (one that sends > 99% spam from a probablistic  
metric ... not pure ratio), then it blacklists the entire spammer domain  
(e.g. gooddeals.com, a001.com, etc).  The statistics theory prevents  
blacklisting of domains that send some non-spam.

So the blacklisting of AccuSpam does stop spam.  In fact, 91% as of last  
measurement on average for all our users!

So, to be clear: AccuSpam is the "authority", whereas SenderKeys is this  
mechanism for authenticating a message.


AccuSpam as discussed above is anti-spam.  That anti-spam happens to use SPF 
now (or a similar variant like reverse dns).  AccuSpam might also decide to be 
an authority for SenderKeys or might not.  Even if AccuSpam is not an authority 
for SenderKeys, it could still use SenderKeys and a poll the authorities quoted 
in the incoming email, just as it polls the DNS to do SPF now.

So please do not say that AccuSpam is the authority.  SenderKeys is a mechanism 
for many authorities.  I will be just as happy if Pobox.com is the authority 
which AccuSpam decides to trust, especially is Pobox.com sees more incoming 
email than AccuSpam.



Given a message with a missing SenderKeys signature, SenderKeys will pass  
the message to the "authority" (AccuSpam or spamassassin, perhaps)


More likely than AccuSpam and Spam Assassin are anti-spam processing the 
incoming message, then they will past the From: address off to an authority 
they trust.  As the Overview says, the disposal of the message is unspecified.  
AS or SA can do what ever they normally do with a message that has no 
anti-forgery indication.


and the  
authority will use whatever additional heuristics it chooses.


The authority is just an authority for private key, public key, From: address 
records.

It does not make an decisions about disposal of incoming messages.  Verifiers 
do that.  The anti-spam is a verifier.

I see now one mistake is we need to make some better definitions of our terms 
in the SenderKeys Overview.  Thanks for insight.


 If the  
message has an invalid or incorrect signature, SenderKeys will presumably  
block the message (bounce, drop, whatever the user wants at that point).


SenderKeys does not do anything, just as SPF does not do anything.

Verifiers decide what do with the information gleemed from the SenderKeys 
header or lack thereof.

I am suggesting the lack of a SenderKeys header is just like a lacking SPF 
record.

I am suggest a invalid signature is handled by verifiers similar to how a 
invalid IP for SPF "-all" is handled.  But verifiers are flexible to interpret 
as they desire.  Remember their may be more than one SenderKeys headers and 
thus more than one authority and thus different answers.  It is possible 
although not likely to get mixed answers on the question of "is it forged" and 
then verifier has to decide which authority to trust and what to do. 




If the message fails the tests, it will be returned to the sender with the  
recommendation that they upgrade to SenderKeys because someone is using  
their address to send spam messages, or their messages look too much like  
spam.


If no SenderKeys header is present this will happen, but if there is a invalid 
signature, then it is probably deemed to be forgery by the verifiers and 
deleted without further hassling the forged sender.  Just as for SPF "-all".


In this mode, SenderKeys acts as a 'whitelist' mechanism for the  
authority, allowing messages through filters.


No.  Read above.  SenderKeys acts just like SPF "-all".


I am very happy to elaborate if you can please appeal to the list to  
reinstate me.  I have turned off my auto-respondeer.

Well I'll include your plea in my reply and Cc it to the list,


Thanks.

but I'm not  
exactly too sympathetic given that you have been rude and adversarial  
during your time on the list, whereas I prefer a more positive tone.

Of course I think most posters have been to me also.  I said I think Mozilla is 
not worth it.  That started a religious war.  I guess my opinions are 
adversarial and others' opinions are fact.

It is always that way when "not invented here" syndrome exists.

It is a nature of man to try to kill any competitor.  The key is for you all to 
see that SPF and SenderKeys are going to help each other succeed.  If you can 
get out of the myopia of "he wants to destroy my work" into "he wants to make 
us very successful" then we all become best friends.

Thanks,
Shelby 


<Prev in Thread] Current Thread [Next in Thread>