Re: Google checkout FP

[Sidney Markowitz <si...@sidney.com>]

Matthias Leisi wrote, On 1/02/10 9:46 AM:
> Does it come from a unique IP range?

In my one example it looks like the vendor sent it themselves to an
address that they were provided ******@checkout.l.google.com and from
there it went through Google's processing. I guess I could test for a To
address of *@checkout.*.google.com as long as I could be sure that it
really went through the google.com MX server rather than have a bogus To
address and Bcc'd to me. I could make use of X-Spam-Relays-Trusted in a
header rule, but I'm not sure how to distinguish between mail sent to
the *@checkout.*.google.com and mail that is Bcc'd to my gmail address
with a bogus checkout To address.

 -- sidney

Re: Google checkout FP

[Sidney Markowitz <si...@sidney.com>]

Adam Katz wrote, On 2/02/10 8:53 AM:
> You spoke of the To: address.  What about the sender?  Would this do?
> 
>     def_whitelist_auth *@checkout.l.google.com

The sender isn't *@checkout.l.google.com

When I buy something paying with Google Checkout, Google provides the
vendor with a single-purpose *@checkout.l.google.com address that they
can use to reach me. The vendor sends mail to that address and Google
forwards it to me.  I tried sending an email to a bogus
checkout.l.google.com address with a Bcc to my gmail address. The copy
to the To address was rejected of course, but the Bcc arrived in my mail
box with headers that I can't distinguish from the mail that I got from
a vendor that was sent to me via the real checkout.l.google.com address.
The MX records for gmail.com and l.google.com are the same.

Of course I can whitelist the vendor, but what I'm trying to do is
figure out if it is possible to find some characteristic of the email
that can be used for a general nice rule for such Google Checkout
forwarded mail.

 -- sidney

Re: Google checkout FP

[Adam Katz <an...@khopis.com>]

Sidney Markowitz wrote:
> Matthias Leisi wrote, On 1/02/10 9:46 AM:
>> Does it come from a unique IP range?
> 
> In my one example it looks like the vendor sent it themselves to an
> address that they were provided ******@checkout.l.google.com and
> from there it went through Google's processing. I guess I could
> test for a To address of *@checkout.*.google.com as long as I could
> be sure that it really went through the google.com MX server rather
> than have a bogus To address and Bcc'd to me. I could make use of
> X-Spam-Relays-Trusted in a header rule, but I'm not sure how to
> distinguish between mail sent to the *@checkout.*.google.com and
> mail that is Bcc'd to my gmail address with a bogus checkout To
> address.

You spoke of the To: address.  What about the sender?  Would this do?

    def_whitelist_auth *@checkout.l.google.com

Google is very good about using DKIM.  That will prevent forgeries.  I
already have this in my local.cf without any worries of spam:

    whitelist_auth *@passport.msn.com *@google.com *@ebay.com

None of these FQDNs have users addresses, and all of them are very
sensitive to what messages they'll send you (especially if on behalf
of a user, like for ebay -- however I may not be able to vouch for msn
as strongly).  MSN customers are user@msn.com and Google's are
user@gmail.com (or user@mail.google.com).

Since these use authentication, forging is almost impossible and I
feel no concern on that front, though perhaps if I were to push for
its inclusion in SA distributions, I'd use def_whitelist_auth.


Thanks to pastebin under-utilization, I've also had to add this  :-)

    whitelist_auth *@spamassassin.apache.org