[ale] Gmail accepts spam when you use email forwarding
Sean McNealy
sean.mcnealy at gmail.com
Tue Dec 15 16:18:21 EST 2009
If you're already forwarding all the mail on your domain to gmail, I
highly recommend using Google Apps. I just have my MX and SPF records
pointing to Google itself (and SRV for XMPP/Jabber points at them
too). Yeah they're doing things that I should be doing myself, yes...
but it's so much easier this way.
Anyway, that would solve your SPF checking problem.
-Sean
On Tue, Dec 15, 2009 at 3:41 PM, Brandon Checketts
<brandon at brandonchecketts.com> wrote:
> That is true, but I don't see that as a failing of DKIM. In fact, it seems like
> a positive feature that the spam-filtering software would know that it was sent
> from domain.tld instead of hotmail.
>
> Without DKIM, the spam filtering service has no reliable way to determine whose
> reputation is at stake.
>
> Going back to Richard's original issue, if the message was signed with DKIM,
> Gmail's spam filtering would see the DKIM Signatures, and could validate the
> authenticity of the sender, regardless of how many untrusted mail servers the
> message went through.
>
> Thanks,
> Brandon Checketts
>
> On 12/15/2009 3:14 PM, Jim Popovitch wrote:
>> spammer at hotmail.domain.tld can DKIM sign the email and it would pass
>> Google's DKIM test if the email was signed on a host that had the keys
>> for the settings announced in DNS for domainkey.domain.tld
>>
>> -Jim P.
>>
>> On 2009-12-15, Brandon Checketts <brandon at brandonchecketts.com> wrote:
>>> Are you are saying that spammer at baddomain.com can set the From or Sender
>>> header
>>> to be 'bob at freecreditreport.com'?
>>>
>>> I suppose he could fake that header, and then sign it with DKIM, but he
>>> would
>>> have to use his own private key to sign the message. It is impossible for
>>> him
>>> to sign the message as @freecreditreport.com without having their private
>>> key.
>>>
>>> The public key used to validate the signature is pulled from DNS from the
>>> Sender
>>> header (freecreditreport.com in this example), so I don't see how a spammer
>>> could get a message to validate using a key that doesn't belong to the
>>> sender's
>>> domain.
>>>
>>> Maybe I'm misunderstanding what you are saying, but I still submit that DKIM
>>> is
>>> much superior to SPF and is a fundamentally sound way to verify the sender.
>>>
>>> Thanks,
>>> Brandon Checketts
>>>
>>>
>>>
>>>
>>>
>>> On 12/15/2009 1:37 PM, Jim Popovitch wrote:
>>>> DKIM does NOT validate the integrity of the msg headers, it only
>>>> establishes that the msg headers have not changed in transit. If you
>>>> trust the connecting client IP, you can trust the DKIM signed headers.
>>>>
>>>> -Jim P.
>>>>
>>>> On 2009-12-15, Brandon Checketts <brandon at brandonchecketts.com> wrote:
>>>>> I don't believe that DKIM is subject to the same problem.
>>>>>
>>>>> DKIM provides a cryptographic signature to validate the sender of a
>>>>> message.
>>>>> If
>>>>> it says it is from somebody at freecreditreport.com, you can be pretty
>>>>> certain
>>>>> that
>>>>> it is, in fact, from that user. (Unless a private key is compromised,
>>>>> etc).
>>>>> You
>>>>> can then reliably build a reputation system around that specific address
>>>>> or
>>>>> domain.
>>>>>
>>>>> The DKIM signature validates the message body, as well as several headers
>>>>> (Sender, From, Date, etc). It can go through any number of intermediary
>>>>> mail
>>>>> servers and the signature will remain valid (provided of course that the
>>>>> intermediary mail server doesn't tamper with any of those headers or the
>>>>> message
>>>>> body)
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Brandon Checketts
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 12/15/2009 12:11 PM, Jim Popovitch wrote:
>>>>>> DKIM is just as much as a problem. Google/Yahoo/Hotmail can only
>>>>>> trust the header lines that they themselves inject. A spammer can set
>>>>>> any header line and DKIM sign the email and send it from a host with
>>>>>> proper SPF, happens all the time (look no further than free credit
>>>>>> report spam).
>>>>>>
>>>>>> -Jim P.
>>>>>>
>>>>>> On 2009-12-15, Brandon Checketts <brandon at brandonchecketts.com> wrote:
>>>>>>> This is a weakness of SPF, and why Google, Yahoo, and others are
>>>>>>> championing DKIM.
>>>>>>>
>>>>>>> Also, remember that attempts at sender validation (ie: SPF and DKIM)
>>>>>>> don't indicate whether a message is spam or not (spammers can use them
>>>>>>> too). It just makes it possible to build a reputation based on the
>>>>>>> sender address.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Brandon Checketts
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Jim Popovitch wrote:
>>>>>>>> >From Google's perspective, Line 08 could always be spoofed so Google
>>>>>>>> only relies on what Google knows to be true.
>>>>>>>>
>>>>>>>> -Jim P.
>>>>>>>>
>>>>>>>> On 2009-12-15, Richard Bronosky <Richard at bronosky.com> wrote:
>>>>>>>>> Let me know if Google is in the wrong, or I am crazy.
>>>>>>>>> What I have is a postfix server on slicehost that I use solely for
>>>>>>>>> the
>>>>>>>>> purpose setting up @bronosky.com email forwarders for members of my
>>>>>>>>> family, and as an outgoing mail server (which I have Gmail using!).
>>>>>>>>> Most of us are using Gmail now, but some of the stragglers are still
>>>>>>>>> on Hotmail or Yahoo!. For the past week 15 times a day I have been
>>>>>>>>> receiving and reporting as spam the same message (nearly) with very
>>>>>>>>> similar heads.
>>>>>>>>>
>>>>>>>>> line01: Delivered-To: richardbronosky at gmail.com
>>>>>>>>> line02: Received: by 10.220.108.106 with SMTP id e42cs49574vcp; Tue,
>>>>>>>>> 15 Dec 2009 00:24:04 -0800 (PST)
>>>>>>>>> line03: Received: by 10.216.90.196 with SMTP id
>>>>>>>>> e46mr2408469wef.194.1260865444149; Tue, 15 Dec 2009 00:24:04 -0800
>>>>>>>>> (PST)
>>>>>>>>> line04: Return-Path: <nmike at bronosky.com>
>>>>>>>>> line05: Received: from slice1.bronosky.com (slice1.bronosky.com
>>>>>>>>> [174.143.204.116]) by mx.google.com with ESMTP id
>>>>>>>>> t12si19704611gvd.5.2009.12.15.00.24.02; Tue, 15 Dec 2009 00:24:03
>>>>>>>>> -0800 (PST)
>>>>>>>>> line06: Received-SPF: pass (google.com: best guess record for domain
>>>>>>>>> of nmike at bronosky.com designates 174.143.204.116 as permitted sender)
>>>>>>>>> client-ip=174.143.204.116;
>>>>>>>>> line07: Authentication-Results: mx.google.com; spf=pass (google.com:
>>>>>>>>> best guess record for domain of nmike at bronosky.com designates
>>>>>>>>> 174.143.204.116 as permitted sender) smtp.mail=nmike at bronosky.com
>>>>>>>>> line08: Received: from alixpartners.com (unknown [116.68.243.172]) by
>>>>>>>>> slice1.bronosky.com (Postfix) with SMTP id 6D0A017643 for
>>>>>>>>> <deadmail at bronosky.com>; Tue, 15 Dec 2009 08:26:44 +0000 (UTC)
>>>>>>>>> line09: From: VIAGRA ® Reseller <deadmail at bronosky.com>
>>>>>>>>> line10: To: deadmail at bronosky.com
>>>>>>>>> line11: Subject: Deal of the Day: Save 76%
>>>>>>>>> line12: MIME-Version: 1.0
>>>>>>>>> line13: Content-Type: text/html; charset="ISO-8859-1"
>>>>>>>>> line14: Content-Transfer-Encoding: 7bit
>>>>>>>>> line15: Message-Id: <20091215082645.6D0A017643 at slice1.bronosky.com>
>>>>>>>>> line16: Date: Tue, 15 Dec 2009 08:26:44 +0000 (UTC)
>>>>>>>>>
>>>>>>>>> the part that really sucks are line06 and line07. All mail for
>>>>>>>>> @bronosky.com is going to come to Google forwarded from
>>>>>>>>> slice1.bronosky.com because that's the way it is. Where I believe
>>>>>>>>> Google is goofing up is that they are SPF checking the IP from line05
>>>>>>>>> instead of the IP from line08. So, the trick to spamming any Gmail
>>>>>>>>> user who forwards from another domain is the set the From: header to
>>>>>>>>> an address @ that domain. Seems like a huge fail to me.
>>>>>>>>>
>>>>>>>>> Please opine.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> .!# RichardBronosky #!.
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Ale mailing list
>>>>>>>>> Ale at ale.org
>>>>>>>>> http://mail.ale.org/mailman/listinfo/ale
>>>>>>>>> See JOBS, ANNOUNCE and SCHOOLS lists at
>>>>>>>>> http://mail.ale.org/mailman/listinfo
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Ale mailing list
>>>>>>>> Ale at ale.org
>>>>>>>> http://mail.ale.org/mailman/listinfo/ale
>>>>>>>> See JOBS, ANNOUNCE and SCHOOLS lists at
>>>>>>>> http://mail.ale.org/mailman/listinfo
>>>>>>> _______________________________________________
>>>>>>> Ale mailing list
>>>>>>> Ale at ale.org
>>>>>>> http://mail.ale.org/mailman/listinfo/ale
>>>>>>> See JOBS, ANNOUNCE and SCHOOLS lists at
>>>>>>> http://mail.ale.org/mailman/listinfo
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Ale mailing list
>>>>>> Ale at ale.org
>>>>>> http://mail.ale.org/mailman/listinfo/ale
>>>>>> See JOBS, ANNOUNCE and SCHOOLS lists at
>>>>>> http://mail.ale.org/mailman/listinfo
>>>>>
>>>>> _______________________________________________
>>>>> Ale mailing list
>>>>> Ale at ale.org
>>>>> http://mail.ale.org/mailman/listinfo/ale
>>>>> See JOBS, ANNOUNCE and SCHOOLS lists at
>>>>> http://mail.ale.org/mailman/listinfo
>>>>>
>>>>
>>>> _______________________________________________
>>>> Ale mailing list
>>>> Ale at ale.org
>>>> http://mail.ale.org/mailman/listinfo/ale
>>>> See JOBS, ANNOUNCE and SCHOOLS lists at
>>>> http://mail.ale.org/mailman/listinfo
>>>
>>> _______________________________________________
>>> Ale mailing list
>>> Ale at ale.org
>>> http://mail.ale.org/mailman/listinfo/ale
>>> See JOBS, ANNOUNCE and SCHOOLS lists at
>>> http://mail.ale.org/mailman/listinfo
>>>
>>
>> _______________________________________________
>> Ale mailing list
>> Ale at ale.org
>> http://mail.ale.org/mailman/listinfo/ale
>> See JOBS, ANNOUNCE and SCHOOLS lists at
>> http://mail.ale.org/mailman/listinfo
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
More information about the Ale
mailing list