[colug-432] Uptick in "Foreign Investor" Spam
Rob Funk
rfunk at funknet.net
Wed Dec 23 14:18:08 EST 2009
On Wednesday 23 December 2009 12:03:57 pm R P Herrold wrote:
> On Tue, 22 Dec 2009, Rob Funk wrote:
> > This week I finally gave in and implemented SPF, DKIM, and DomainKeys on
> > funknet.net, just to make it more likely that my mail would go through
> > to sites like Yahoo. But that's a reaction other people's
> > over-filtering, and does little or nothing about the spam coming in to
> > me.
>
> I had been looking at:
> http://www.dkim.org/
> but the load of setting up and maintaining such only benefits
> a third party receiver. I just don't get complaints as to the
> list of inadvertent mis-classification of material client
> domains issue as spam
I'm not sure what you mean about "third party receiver". I did it because
Yahoo was sending my funknet.net mail into people's spam boxes, and Yahoo
seems to want sender-domain verification with DomainKeys or DKIM. (They seem
somewhat inconsistent about whether they support DKIM, but they definitely
support its predecessor DomainKeys, since they invented that.)
BTW, while Yahoo is probably the biggest user of DomainKeys right now, Gmail
is probably the biggest user of DKIM. Facebook is another big DKIM user.
The real benefit isn't directly about spam:
SPF is an attempt to validate that the sending machine is authorized by the
domain to send mail for it.
DKIM and DomainKeys are attempts to authenticate that the message comes from
the domain it says it comes from, and that the message (including significant
headers) hasn't been substantively altered.
If these mechanisms tell you that a message really did come from the domain
it claims (within the uncertainty limits introduced by insecure pieces like
DNS), you might be able to be more definitive about making spam/nospam
filtering decisions. (Remember, spammers were the first to widely publish SPF
records, catching mail admins who mistakenly assume that valid SPF means non-
spam. I'm sure similar assumptions happen with DKIM.)
I haven't really done much with checking incoming DKIM yet. I disabled
checking incoming DomainKeys, and I haven't bothered checking incoming SPF.
> I see your boundry box is running sendmail for the first
> exposed Received in the list, but the VPS running postfix.
> What setup steps were entailed in configuring?
> - Sendmail DomainKeys Filter and
> - Sendmail DKIM Filter
In fact I'm just running Postfix, not Sendmail, but the daemons I'm using for
those two pieces were designed as Sendmail "milters". Postfix supports
Sendmail milters now.
(Hmm, "first exposed Received in the list".... are you sure that's not coming
from lists.colug.net?)
> The first appears to be a milter
> https://sourceforge.net/projects/dk-milter/
> http://www.elandsys.com/resources/sendmail/domainkeys.html
> but also requires coordination adding some content to forward
> DNS TXT records -- last updated Feb 2009 at SF
>
> As does the second
> http://www.dkim.org/
> which curiously also hashes the message body, doing some
> transport security, probably to get a varying set of contents
> to hash, rather than a static or somewhat predictable set of
> headers alone. Again, coordination to publishing a forward
> DNS TXT record
In fact they both use the same DNS TXT records.
The idea of checking the headers is at least partly to prevent forgery, since
the headers are checked with the key published in the domain's DNS. (Of
course, there's still the problem that DNS was never designed as a security
protocol and can be broken.)
I'm pretty sure both DomainKeys and DKIM include the body in their checks.
The background as I understand it: Yahoo introduced DomainKeys, and Cisco
introduced a solution called Identified Internet Mail. The IETF then combined
the two and refined the result to create DKIM. I don't know anything about
the Cisco thing, but DKIM looks *very* similar to DomainKeys.
I'm using dk-milter for DomainKeys, and dkim-milter for DKIM. (dk-filter and
dkim-filter on Ubuntu/Debian.)
I put the dkim-filter on localhost port 8891, and the dk-filter on localhost
port 8892, then in /etc/postfix/main.cf I have these lines:
smtpd_milters = inet:localhost:8891 inet:localhost:8892
non_smtpd_milters = inet:localhost:8891 inet:localhost:8892
# by default, if the milter is not available Postfix will defer messages
milter_default_action = accept
milter_protocol = 2
> $ dig -t mx funknet.net
> funknet.net. 7163 IN MX 10 mail.funknet.net.
> mail.funknet.net. 7163 IN A 72.14.183.217
>
> $ dig -t txt funknet.net
> "v=spf1 ipv4:72.14.183.217 a mx ?all"
That would be the SPF record, saying that IP address is OK, as is anything
that funknet.net's A and MX records point to, but anything else should be
treated neutrally.
(There's also a new "SPF" DNS record type that can be used, but support for
that in both DNS and SPF tools is iffy, and the UI for my DNS service doesn't
support it.)
> $ dig -t txt _domainkey.funknet.net
> _domainkey.funknet.net. 300 IN TXT "o=~\;
> r=postmaster at funknet.net"
That's only the optional policy record for DKIM/DomainKeys. the policy record
is only checked if a message fails DKIM/DomainKeys verification.
The "o=~" means that there may be unsigned legitimate messages (which, like
my SPF policy, basically means neutral on failure), and that there could be
authorize third-parties signing mail. The r= part is the address to notify of
validation failures, if a validator wants to notify someone. (So I might
possibly find out if someone is forging funknet.net mail. Maybe.)
> When attempting to pull the Public key of the external sending
> (here, relaying) host, to be able to do the verification,
> though, I do not receive one:
>
> $ dig -t txt mail._domainkey.funknet.net
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10499
>
> "NXDOMAIN" is short for you asked for a "non-existing domain"
>
> I also tried:
>
> $ dig -t txt hactar.local._domainkey.funknet.net
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1118
>
> I may well be misunderstanding that domain part to query for
> -- I assumed it to be the non-FQ (leftmost) A record name of
> the mail handler, with the 'phantom' intermediate domain part
> of: _domainkey
The trick (and the part it took me a while to grok) is that the piece you're
looking for -- the "selector" -- is specified in the email message's DKIM-
Signature or DomainKey-Signature header. In those headers of my mail, you'll
see "s=default", which tells the validator to use "default" as the selector.
$ dig -t txt default._domainkey.funknet.net
default._domainkey.funknet.net. 300 IN TXT "v=DKIM1\; k=rsa\;
p=MIGfMA0GCSqGSI{a bunch of ugly base64 elided here}1Xcv5gwIDAQAB"
That selector can be anything that's a valid name in DNS, but should not be
considered a secret.
Of course, the mailing list is stripping out the DKIM-Signature and
DomainKey-signature headers that give this information. MailMan is modifying
a bunch of headers as well as the body of the message, so leaving those
headers would make it fail validation. The related headers that you are
seeing (X-DomainKeys and X-DKIM) are purely information about the daemons,
and I can turn those off.
--
==============================| "A slice of life isn't the whole cake
Rob Funk <rfunk at funknet.net> | One tooth will never make a full grin"
http://www.funknet.net/rfunk | -- Chris Mars, "Stuck in Rewind"
More information about the colug-432
mailing list