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 ***[email protected] 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 *[email protected]
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 *[email protected] *[email protected] *[email protected]
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 [email protected] and Google's are
[email protected] (or [email protected]).
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 *[email protected]
