On Tue, 2010-02-09 at 11:42 -0500, 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. > > How does this idea authenticate mail from domain ? SPF is aimed at doing that.
IMHO the SPF-breaks-forwarding argument is misplaced What about SRS. If SRS implementation is not going to be easy because mailservers have been there too long for adopting anything new then can your be sure MailServer IP validation will be adopted ? Anyway I block spams from almost all non-mailservers by using RBL's I dont see any value add in implementing this Thanks Ram > 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. > > > On 02/09, RW wrote: > > You've mixed-up A record and PTR record. > > Yes. Embarrassing. > > > Checking for full-circle DNS already does most of this. > > My home dynamic cablemodem address passes full-circle DNS. But not this. > So this is far more useful for checking if an IP is a legitimate sending > mail server. > > > What your > > scheme would do is check for otherwise legitimate servers that have > > been compromised and are delivering direct-to-mx. > > An otherwise legitimate but compromised mail server would not be detected > by this. I'm curious why you interpreted it differently. > > > On 02/09, Charles Gregory wrote: > > On Mon, 2010-02-08 at 22:08 -0500, dar...@chaosreigns.com wrote: > > > What you describe here is functionally similar to an SPF lookup with a > > 'pass' result..... The server provides positive verification that the > > listed IP is a legitimate sender for that domain. > > Yes. > > > As long as 'otherwise' is a definitive 'fail' response from an SPF (or > > equivalent) server, and not merely an absence of SPF server.... > > Yes. Definitive "fail". > > > Your method would allow 'spoofing' so that a spammer who hacks a > > legitimate server can use a valid return address on a different domain, > > but still the mail would receive a 'passing' grade. At least, with SPF, > > the spammer must forge an address on the hacked domain, which increases > > the likelihood of detection.... > > Yes. I would blacklist domains that "pass" hacked servers. Just as IPs of > hacked servers are blacklisted. They're sending spam, and need to be > fixed. > > >> Forwarding doesn't break. > > > > Ah, so you want to allow 'legitimate' forwarding, but not allow spammers > > to 'forward' their mail? Good luck with that. The only way to make it > > work for the legitimate sender, but not for spammers is to have a > > mechanism built-in to the forwarding server that encapsulates or rewrites > > the envelope 'From' address..... > > Encapsulating or rewriting the envelope 'From' address seems significantly > less likely to be adopted from what I've read. > > >> Obviously you'd need a blacklist of spammer domains that list spamming > >> IPs as legit senders. > > > > And you would be playing the same 'musical chairs' game with new domains > > created by spammers on a daily basis. All the same flaws of SPF, and no > > greater benefit. > > Same domain blacklisting issues as SPF, yes. > > I am not very concerned about the throw-away domains because > I'll reject all mail from domains not at least 10 days old. 10+ > day old domains are already listed as 127.0.2.3 records from > example.com.hostkarma.junkemailfilter.com. > > I believe the benefit of not breaking forwarding is sufficient to make it > much more useful than SPF for spam filtering. I've come across enough > people, personally, recently, in trying to block (some = positive SA > score) emails without an SPF "pass", who are not willing to ever implement > SPF due to breaking forwarding that I believe this would be useful. > > >> Is there any way this wouldn't be very useful? > > > > Is there any place where SPF does not do the same job, other than mail > > forwarding? > > No. But as I said, I am concerned about the potential for wide spread > adoption of SPF due to forwarding breakage enough that I think this would > be much more useful. > > > On 02/09, Matus UHLAR - fantomas wrote: > > On 08.02.10 22:08, dar...@chaosreigns.com wrote: > > > So it's not tied to the SMTP MAIL FROM or anything. > > > Forwarding doesn't break. > > > > What do you mean by this? > > Do you want to implement new way of defining which hosts are permitted to > > send e-mail? > > Yes. > > > There already are attempts to do this, with false positives and > > negatives. > > How is this not better than the other attempts? > > > Yours is a bit complicated > > How is it complicated? You need to create 1 record per sending mail > server, in the form: > > <IP of mail server>.mtx.<hostname of mail server> > > (And the IP needs to be reversed as in all other A records that list IPs.) > > > and new which means everyone would > > need to implement this (otherwise he'd get false positives on his outgoing > > mail). > > Yes. > > > Therefore I think it won't work this way. > > This is why I said SA scores for a fail should be small at first. > > > Do you see any reason this wouldn't be more quickly adopted than SPF? >
