On Sat, 23 Feb 2008, Ben Wheeler wrote: > 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.
You're right -- I meant, @mixxx.org in from (not that it matters at that smtp step). This was a distraction. > > 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 :) Duh, I was too lazy to RTFM to see that 'stacktrace' was actually the reported helo name... > > 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. Wull yeah, but by tcpd, it wouldn't have got that far and would not have been in mail.log. > > 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. > 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. Aargh, my bad. Yes, I know quite well they are utterly different zones (mixxx, inaddr), I mis-wrote. I wasn't even in a hurry! The LH dot -- eh -- that was schematic response; I could have no idea what the scope of the in-addr zone that would contain that would be; likely it's simply '139. in ptr mixxx.org.' but that's not illustrative here. Yeah, it was dumb to state it was in mixxx.org! > 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. You are correct that the order of checks at tcpd wrapper time is addr/ptr/addr, but generally speaking, the list of names and numbers must be congruent (a member in each list). That's all I meant. > > 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 SPF is likely crap and used by few; but the cost is a TXT record. And many large sites DO use it. > So in short, the problem is a misconfigured MTA at the sending end. > Not the DNS. :) Yes, you are correct. My bad. The MTA needs to simply utter a valid name for HELO and likely the problem will be solved. ------------------------------------------------------------------------- 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
