Right, so here's the situation: - I changed that entry in the postfix settings to stacktrace.mixxx.org and set up a A record for that subdomain. - We use EveryDNS for the DNS, so I can't do SPF (as far as I can see) - The google mail entries are for Google Apps, which hosts @mixxx.org mail accounts.
What do I need to do? Is it fixed yet? I have no idea what's going on. Thanks, Albert On 24-Feb-08, at 12:18 AM, Tom Jennings wrote: > 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 ------------------------------------------------------------------------- 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
