Re: [spf-discuss] SPF, DKIM, and NIH

--On 16 October 2009 08:08:22 -0700 David MacQuigg 
<macquigg(_at_)ece(_dot_)arizona(_dot_)edu> wrote:
> Ian Eiloart wrote:
> > --On 14 October 2009 15:08:15 -0700 David MacQuigg
> > <macquigg(_at_)ece(_dot_)arizona(_dot_)edu> wrote:
> >
> > > OK, I think I understand now what you mean by "sender".  Sender
> > > (individual author) addresses are worthless to identify bad senders.
> > > See above.
> > That's simply not my experience. I've seen spear phishing attacks from
> > gmail accounts that are listed on blacklists. The blacklisting of
> > sender addresses does have value to me.
> I wasn't aware of any blacklists of individual sender addresses.  I would
> like to give it a try.  Where can I find one?
<http://www.scamnailer.info/> has a script that will update spamassassin or 
clamav configurations with a list of about 14k addresses that have been 
used for scamming. I think the S/A rules generalises from those addresses a 
little.
> > But, there's a bigger picture here. I'd like to rate-limit new senders
> > that haven't earned a good reputation. I can do that for individual
> > gmail users, but can't apply the same rate limit to all gmail users.
> I would rather not try to separate good from bad within Gmail.  That is
> really Gmail's responsibility.  I just rate the entire mailflow from
> Gmail to our receivers.  Whitelisting of individual Gmail authors can be
> done by our individual recipients.
Absolutely, but you want to check the DKIM signature before applying the 
whitelist. Otherwise, every whitelist entry is an invitation to spam.
> > Therefore, I need a reputation system that allows me to key on sender
> > addresses. However, to do that, I need some sort of assurance that the
> > author address hasn't been spoofed.
> Without having some kind of worldwide individual identity system, it just
> can't be done.  You will always have to rely on the mail submission agent
> (MSA) to verify its user accounts.  Some are strict, and have no spammers
> among their users.  Others, like Gmail, are more concerned about getting
> new accounts.  We need to make the cost of that decision higher than the
> cost of losing a few legitimate accounts when new subscribers find it
> inconvenient to provide strong individual identification to their MSAs.
> We can do that by holding the MSA responsible.
No, we can. What I mean by "spoofed" is that the email was sent from the 
account that it claims to be sent from. For gmail, for example, a valid 
DKIM signature is enough that I can assign reputation to the purported 
author. I don't need a worldwide ID system, I just need to know that the 
account that I'm judging is the correct one.
As an admin, I can't just reject all gmail email. I have no choice but to 
try to distinguish between good and bad senders. However, I can assign a 
default reputation to ESPs like gmail, for previously unseen users in their 
domain.


> A global individual ID system will also have major problems with privacy
> and anonymity issues.  Organizations operating Internet transmitters have
> no legitimate reason to hide their identity.
>
> A reliance on individual IDs will also produce a weak reputation system.
> There are far too many IDs to keep track of, and the data for each one is
> too sparse.  Reputation is best accumulated at the highest level which
> still has some authority over its domain.  az.us is too high.  Nobody in
> Arizona can control what all the domains do.  (Theoretically they could,
> but there is no actual delegation of authority to az.us (no SOA record).)
> We have chosen pima.az.us as the optimum level.  Pima county can enforce
> standards for anyone operating a transmitter under their name.
>
> -- Dave
>
>
>
> -------------------------------------------
> Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
> Modify Your Subscription: http://www.listbox.com/member/
> [http://www.listbox.com/member/]
>
> Archives: https://www.listbox.com/member/archive/735/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/735/
> Powered by Listbox: http://www.listbox.com


--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/


-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ 
[http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com