Actions

Talk

Welcome to the HacDC Wiki: Difference between revisions

From HacDC Wiki

No edit summary
Line 28: Line 28:
13:10 <paul> so other MTAs have an entire codepath where they try to parse an ASCII string of an IP address to stuff it into a connect() <br/>
13:10 <paul> so other MTAs have an entire codepath where they try to parse an ASCII string of an IP address to stuff it into a connect() <br/>
13:10 <paul> which is as bad of an idea as it sounds, securitywise <br/>
13:10 <paul> which is as bad of an idea as it sounds, securitywise <br/>
Fixed - thanks for the heads up!

Revision as of 20:33, 30 April 2009

HacDC's MX record broken, can't send mail to lists

Dangit. I'm sure someone will find this here, as I'm unable to send to any of the mailing lists. Here's a convo between me and my admin:

12:39 <myself> hey, I keep getting this whenever I try to send to hacdc:
12:39 <myself> [email protected]
12:39 <myself> all relevant MX records point to non-existent hosts or (invalidly) to IP addresses
12:40 <myself> but there's plenty of traffic on the list, others obviously have no problems
12:40 <myself> I mentioned it to one of them through his personal email, and didn't hear back. Is this something you can look into?
13:03 <paul> paul@ptimmins-d:~$ host hacdc.org
13:03 <paul> hacdc.org has address 208.72.84.15
13:03 <paul> hacdc.org mail is handled by 0 69.89.31.218.
13:03 <paul> that's invalid
13:03 <paul> cant' fix
13:04 <paul> mx records have to point to names per rfc
13:05 <myself> ahh, okay
13:05 <myself> thanks
13:05 <paul> that should be something like
13:05 <paul> MX 0 mail.hacdc.org.
13:05 <paul> with mail.hacdc.org. IN A 69.89.31.218
13:06 <myself> and everyone else's MTAs just silently accept the misconfiguration and do the right thing anyway
13:07 <paul> where by "the right thing" you mean "do what I mean not what I say"
13:07 <paul> yes
13:08 <paul> they added extra code paths to compensate for the dns calls not returning shit they should
13:08 <paul> when you pull an A record, the IPs get returned in binary
13:08 <paul> when you pull an MX record, it spells out the data in ascii because it's supposed to be another name
13:09 <paul> which you can then do a gethostbyname() on and get an ip
13:10 <paul> so other MTAs have an entire codepath where they try to parse an ASCII string of an IP address to stuff it into a connect()
13:10 <paul> which is as bad of an idea as it sounds, securitywise

Fixed - thanks for the heads up!