[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
> $ dig -t txt funknet.net
> "v=spf1 ipv4: 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