dar...@chaosreigns.com wrote:
I apparently need to clarify that I think this is a good idea because I am
concerned about the number of people (who control DNS records) who are very
strongly against creating SPF records specifically because of forwarding
breakage.  The email I got in response to my request for my employer to
create an SPF record included the word "abomination".  From a friend.
I don't entirely agree, but it is a problem for adoption.

This is entirely an attempt to replicate the functionality of SPF without
breaking forwarding, and without causing other problems that might
discourage adoption.


I set this up for my mail server (using mtx instead of designatedsender):

$ host -t PTR 64.71.152.40
40.152.71.64.in-addr.arpa domain name pointer panic.chaosreigns.com.

$ host -t A 40.152.71.64.mtx.panic.chaosreigns.com
40.152.71.64.mtx.panic.chaosreigns.com has address 127.0.0.1

All it took was creating a single record in bind:

40.152.71.64.mtx.panic.chaosreigns.com. IN A 127.0.0.1


I'll define it slightly differently:
127.0.0.1 is a pass (negative SA score).
not found is a fail (positive SA score).
127.0.0.0 is a fail (positive SA score).
Anything else is undefined (0 SA score) for future options.


I'd still appreciate feedback on the format of the A record.

Can you be a little more detailed on exactly which pieces of information you're looking at, and where you're getting them from?

So far as I've been able to make out from your descriptions so far, this is a smallish subset of the functionality SPF provides, without the disadvantage of overloading TXT records.

Consider: Spammer has control of a PC on a small(ish)-business LAN whose NAT gateway also handles their mail. (Exchange server, for instance - far too common a configuration IMO.)

Spammer mail originates from 10.0.0.2 (static IP assigned by ISP).

PTR record is 2.0.0.10.in-addr.arpa -> exchange.smallbusiness.com

2.0.0.10.mtx.exchange.smallbusiness.com -> 127.0.0.1 because this is the recognized designated outbound relay for Small Business's legitimate mail, and they've followed your proposal.

How is the spam to be *not* considered a legitimate sender in this case? Even if the Exchange server isn't actually processing the email, its public IP will still be the originating IP of the message.

SPF at least ties some aspect of the message itself to the relay IP in some way. (Whether that's good or bad I'll ignore for the moment.)

-kgd

Reply via email to