Differences between revisions 4 and 5
Revision 4 as of 2009-12-22 12:42:29
Size: 2451
Editor: 130
Comment:
Revision 5 as of 2009-12-23 11:34:33
Size: 2556
Editor: 130
Comment:
Deletions are marked like this. Additions are marked like this.
Line 11: Line 11:
The outgoing filters also do incoming verification; we should probably turn this on for final delivery (and possibly ext-mx if it can do rejections rather than bounces). According to [MSH] the signature validates with ext-mx then breaks after it goes through antivirus. The outgoing filters also do incoming verification. Signatures that sign the Received-SPF header (e.g. Google Groups messages) validate from ext-mx then break after returning from antivirus. [MSH] is investigating.

At this stage we don't drop any messages.
Line 19: Line 21:
Mooneye now has dkim-filter 2.6.0 installed. It does verification on all mail (including ext-mx) and signing on outgoing mail. The conditions for signing outgoing mail have been left as the defaults (i.e. only mail from mooneye and authenticated SMTP). Because all mail delivered over unauthenticated SMTP is checked by the spam filter, any messages with "@ucc.asn.au" in the from line are signed. This is bad. Mooneye now has opendkim 1.1.0 (backported from testing) installed. It does verification on all mail (including ext-mx) and signing on outgoing mail. The conditions for signing outgoing mail are a) the mail must come over SMTP and either b) the client is authenticated or c) the client is from the machine room network.
Line 21: Line 23:
The other problem is that if you send mail from UCC that then gets redirected to your UCC address, it gets signed twice. This is due to the same problem. Because all mail delivered over unauthenticated SMTP is checked by the spam filter, which reinjects the messages using the local delivery method, messages sent via the local delivery method on Mooneye do not get signed. This largely only affects cron mail (mailman uses SMTP).
Line 35: Line 37:
Should we start doing SRS on .forward files? Apparently we should be doing [http://www.libsrs2.org SRS] on mail sent through .forward files. This will need bigtime testing.

It is probably a good idea to start implementing some of the antispam tools usable by domains; e.g. DKIM, SPF.

DKIM

[http://en.wikipedia.org/wiki/DomainKeys_Identified_Mail]

Gmail and the other big providers sign all outgoing mail with DKIM.

Incoming

The outgoing filters also do incoming verification. Signatures that sign the Received-SPF header (e.g. Google Groups messages) validate from ext-mx then break after returning from antivirus. [MSH] is investigating.

At this stage we don't drop any messages.

Mailman breaking existing signatures - possibly a non-issue, will poke.

Outgoing

Debian has dkim-filter ([http://sourceforge.net/projects/dkim-milter/ dkim-milter]) in stable and both dkim-filter and [http://www.opendkim.org/ OpenDKIM] in testing. OpenDKIM is a fork of dkim-milter, and is actively maintained, but would need backporting to stable (the testing packages require a new version of OpenSSL) or compiling from source.

Mooneye now has opendkim 1.1.0 (backported from testing) installed. It does verification on all mail (including ext-mx) and signing on outgoing mail. The conditions for signing outgoing mail are a) the mail must come over SMTP and either b) the client is authenticated or c) the client is from the machine room network.

Because all mail delivered over unauthenticated SMTP is checked by the spam filter, which reinjects the messages using the local delivery method, messages sent via the local delivery method on Mooneye do not get signed. This largely only affects cron mail (mailman uses SMTP).

SPF

SPF seems a bit more likely to cause Issues. None of the big providers seem to have hard FAIL policies yet.

Incoming

Do we want to add verification checks to incoming mail? Does it matter? Would have to be on ext-mx only (or maybe whitelist 130.95/16).

Outgoing

No mail goes out RESNET, so could publish 130.95/16 with SOFTFAIL (or even hard FAIL?) Hard FAIL actually seems preferable in some ways; users will get a bounce from their local server rather than the message being filtered into "probable spam".

Apparently we should be doing [http://www.libsrs2.org SRS] on mail sent through .forward files. This will need bigtime testing.

Does anyone use their personal or ISP mail server to send mail with a UCC from address? Gmail doesn't matter because that uses the Sender header and a sensible envelope header. Mailman overwrites Sender from Gmail.

We should publish instructions on how to do SMTP AUTH to UCC regardless.