How to whitelist ebay but not ebay spoofs?

George Schlossnagle george@omniti.com
Thu Dec 16 05:52:47 UTC 2004


On Dec 15, 2004, at 7:49 PM, Vernon Schryver wrote:

>> From: George Schlossnagle <george@omniti.com>
>
>> While the technology has some flaws, I think that you might feel
>> different if you consider it simply as stab at an authentication
>> technology and not as an authorization technology.  Or maybe not.  :)
>
> Authentication without authorization is worse than snakeoil if you are
> expected to issue blank check authorizations based on the 
> authentication
> of perfect strangers as in ActiveX, SPF, and Sender-ID.  Authentication
> without authorization is like a password without a username.

But no one (with a clue) suggests that you use these things without a 
separate authentication component.  All these technologies give you is 
the ability to trust the accuracy of the represented domain.  It allows 
you (in the authenticated case) to act on data in the message envelope. 
  You currently can't do that.  I can't just whitelist 'ebay.com' as a 
envelope sender, because anyone can forge it.  However, ebay's spf 
record allows me to say 'if the connection is coming from these IPs, 
then I can believe that it is actually from ebay', and then whitelist 
if I so choose (since I know ebay.com is a domain I want mail from).

You need separate checks to implement authorization.  Those 
authorization schemes lie outside of the authentication frameworks.  
All the implementors of these authentication frameworks buy into that.  
The reason they have value is that accurate authentication is a 
prerequisite for any name (domain)-based authentication scheme to work 
though.




>
> Authenticating the unknown sender of an incoming message tells you
> nothing about whether substanitally identical copies of the message
> are being sent to 30,000,000 of your intimate friends.  Authenticated
> strangers are almost the same as unauthenticated strangers.  The most
> SPF might do is reduce bounces of forged mail that should have been
> rejected during the original SMTP transaction.  If you reject instead
> of bounce, there's probably no point in checking SPF RRs.  If you
> bounce, your time would probably be better spent trying to reject.
>
> On the other hand, there are existing mechanisms that do better jobs
> than SPF of authenticating mail senders that are not strangers, as in
>
>> if authenticated():
>>   if domain is trusted:
>>     accept
>> else:
>>    do whatever I normally do

Well, the nice thing about pseudo-code is that it can mean many things. 
  :)  authenticated() can mean SPF-passed, DK-passed, SenderID-passed, 
IIM-passed, CSV-passed, BATV-passed, submitted over TLS, submitted via 
SMTP-AUTH, etc.

> You could use SMTP-AUTH, SMTP-TLS, PGP, or S/MIME, just to name 4.  If
> eBey sent with SMTP-TLS or SMTP-AUTH, you could add their certificates
> to your sendmail cert directory, and use `hackmc -T` to DCC-whitelist
> mail that arrives with validated keys.  That machinery has been in use
> longer than the years that SPF realsoonnow been going to become
> standardized and deployed for real (really checking SPF RRs instead
> of merely publishing them).
>
> Does eBay use STMP-TLS or SMTP-AUTH?

No. How would they use SMTP-AUTH to send mail to my (tiny) domain?  TLS 
is a possibility, but it doesn't handle relaying/forwarding and 
requires a big key-checking scheme on all sides.  Both those 
technologies are really designed for submitters, not for MTA-to-MTA.

S/MIME is not a bad solution, though people who know more about it than 
I seem to think DomainKeys or IIM are better solutions.  Fundamentally 
they do really similar things.

George




More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.