On Fri, Feb 22, 2008 at 09:19:34AM -0800, Tom Jennings wrote: > > I tried it again last night and it's still working for me. I wonder if your > > mail server isn't accepting the mail because our MX record corresponds to > > google's servers and not our actual mixxx.org webserver. We run "Google > > Apps" > > for our mixxx.org mail, and so some mail servers might notice that the wiki > > email is not coming from the mail server it expects. > > Yeah, mixxx.org's mail is not configured right. Should be an > easy fix though. Here's an area I can contribute to mixxx :-) > DNS I know.
I do not think you know it as well as you think you know it ;) > from splatter.wps.com's mail/err log, line breaks added by me > for readability: > > Feb 21 10:00:00 splatter postfix/smtpd[21697]: > NOQUEUE: reject: RCPT from 208-78-101-139.slicehost.net[208.78.101.139]: > 504 5.5.2 <stacktrace>: Helo command rejected: need fully-qualified hostname; > from=<[EMAIL PROTECTED]> to=<[EMAIL PROTECTED]> proto=ESMTP > helo=<stacktrace> > > My server says: your server claims to be mixxx.org, but is > really 208-78-101-139.slicehost.net, pants on fire, go away. No it's not saying that. It's saying "your server didn't say HELO with its fully qualified domain name". No more, no less. > *** The very first line of defense against spoofed hosts is > consistent cross-checked DNS, since that's very hard to fake up. Yes, but the check is as follows: PTR record is looked up for the IP A record is looked up for the hostname returned by the PTR. Does it point to the same IP? If yes, it's all good. It matters not one jot whether the server has anything to do with the alleged mail domain[*], as long as the server isn't nefariously claiming to *be* in some other domain. [*] Unless the receiving MTA honours SPF, but we'll come to that. > My server is not logging alleged HELO names, so I can't > tell you what it says it's name is, but likely it's > saying "208-78-101-139.slicehost.net". In this case I'm afraid your guess has led you up a blind alley :) > Your MTA is > 208.78.101.139 which maps to > 208-78-101-139.slicehost.net which maps to > 208.78.101.139 so that's clean. Exactly. So there's no reason why the connection would be refused on that basis. > You can fix this one of two ways: > > ONE: > > You have an A record that says mixxx.org is 208.78.101.139, > but an in-addr lookup of 208.78.101.139 does NOT return > "mixxx.org". Add a resource record to zone file mixxx.org > that does > > 139.101.78.208.in-addr.arpa IN PTR mixxx.org. That will do nothing in the zone file for mixxx.org. It would need to be in the zone file for 101.78.208.in-addr.arpa. (and you lose 5 points for forgetting the trailing dot on the LHS.) And it's not the problem here anyway. In fact, it's generally Not A Problem if a lookup chain [hostname]-A->[addr]-PTR->[hostname] results in different hostnames. This is entirely normal. The situation that matters is if an [addr]-PTR->[hostname]-A->[addr] does not return the same IP address. > Last, I strongly suggest that you comply with the irritating > and kludgey SPF crap This doesn't really have anything to do with the problem at hand. The jury's still out on whether SPF has any point, I certainly wouldn't go so far as to "strongly suggest" implementing it without firm evidence that its lack is causing a problem, or unless you like the idea of SPF and *want* to implement it. So in short, the problem is a misconfigured MTA at the sending end. Not the DNS. :) Ben ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
