Re: [Asrg] VPNs

Alessandro Vesely wrote, On 7/6/09 6:35 AM:
> Bill Cole wrote:
> > > For example, assume someone trusts Gmail's egress filtering
> > I'll play along. It is certainly possible that for some recipients,
> > the stream of mail from Google's sewer is cleaner than what I see...
> Upthread, you also wrote that they "have shunned the entire notion of
> accountability". What do you see?
The overwhelming majority of mail I am offered by the Gmail outbounds is 
spam. Google has played games with how they will accept abuse reports, 
giving the appearance of not really wanting them.

> Of course, one cannot compare one of those freemail providers with a
> private mail domain, operated by skilled staff, where new accounts are
> added wittingly, used by an elite of cautious people who rarely catch
> viruses, if ever. In the latter case, you don't have to resort to
> statistics to measure the quality of messages.
>
> The big four, much like connection providers' default mailers, have to
> operate some kind of surveillance on what their users send. I wonder if
> they have specific conventions or settings to relay mail from one to
> another, since that probably accounts for a large chunk of their traffic.
Large cheap and free mail providers understand the advantage they get from 
their scale in not needing to do as well with egress filtering as smaller 
mixed sources of mail. There is very little risk to them of missing 95% of 
their outbound spam, as long as they never drop legitimate outbound mail and 
keep their outbound legitimate mail volume large enough that it is hard for 
many sites to treat their mail as presumptive spam.
> > > skip content filtering for mail coming from there. What work is required
> > > to accomplish (and maintain) that task, on typical MTA software?
> > This is a situation where SPF is a useful tool. If I want to make sure
> > that SpamAssassin never deems mail from a *(_at_)gmail(_dot_)com address to be
> > spam as long as it gets an affirmative SPF match (i.e. is coming from
> > what Google says are its normal gmail.com outbounds) I would just add
> > this to my local SpamAssassin config:
> >
> > whitelist_from_spf *(_at_)gmail(_dot_)com
> That kinds of setting cleverly enable whitelisting by domain. However,
> compared to the VPN paradigm, that setting is unilateral. At Gmail, they
> don't now they're whitelisted.
For the vast majority of receiving sites, they have no significant reason to 
care. The number of receiving systems whose mail filtering policies matter 
to large freemail providers is small enough to be managed as a collection of 
bilateral relationships rather than through public open standards.
In my direct experience working on middling corporate mail systems and 
dealing with people handling much larger cheap/free "consumer" mail systems, 
I had some tests of whether they cared about how we treated their mail, and 
saw no sign that they did. At least some don't even seem to care when fairly 
prominent corporations urge their smaller business partners to avoid their 
non-free mail service. What they care about in getting their users' mail 
delivered is the dozen peers to whom they send 80% of their messages and 
maybe the next score down in size that handle another 15%. It's not rational 
for them to care about systems with 10k users or less.
> > For complex senders who have complex and dynamic outbound
> > environments, refuse to publish SPF records, but do use DKIM (e.g.
> > Yahoo) there is probably some way to use DKIM as the authentication
> > that a message is coming from a system that you trust. I can't say how
> > easy or hard that would be, since I've never seen enough marginal
> > value in DKIM to bother with it.
> Browsing docs[1], it seems that
>
> whitelist_from_dkim *(_at_)yahoo(_dot_)com
>
> should work similarly. Domain Keys (whitelist_from_dk) is the 3rd one of
> the three types of whitelist from authentication (whitelist_auth) that
> SA does. So, if a sender knows that you filter with SA, they may try all
> of them in turn, blindly.
DK is obsolete, FWIW.

Using SPF to vouch for a SMTP client IP and/or DKIM signatures to make some 
headers believable is valuable between the big providers because it is 
useful for them to have some easy basis for trusting each other that is hard 
to fake. Others who use those tools for domain-wide trusting of the large 
providers may or may not be acting rationally, depending on the sort of mail 
they actually see from the large providers. No mail system I've worked on in 
the past decade has had a mail stream from any major freemail provider that 
has been less than 50% spam, and that makes any means of domain-wide 
whitelisting for them hard to rationalize.
That said, the general idea of domain-wide whitelisting is widely useful for 
better-run domains and while many domains for which it makes sense are 
simple enough to whitelist without SPF or DKIM, it does not hurt to have 
those tools available. Perversely, they have significantly reduced the 
marginal value available for any new tools that do slightly different sorts 
of domain-wide authentication. Put more directly: the practical value of 
VHLO is reduced by the fact that SPF and DKIM are widely available.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg