Re: [vox-tech] mail / DNS question
On Thu, Jul 04, 2002 at 12:14:10PM -0700, Peter Jay Salzman wrote: [...] ok, keep in mind i'm new at this sort of thing. what's going wrong? why isn't an IP address ok to use on the right hand side? I cannot tell from the above; as you said, it looks fine. Are you using BIND or Mara? Would you mind sending me the zone file? -- Henry House The attached file is a digital signature. See http://romana.hajhouse.org/pgp for information. My OpenPGP key: http://romana.hajhouse.org/hajhouse.asc. msg03063/pgp0.pgp Description: PGP signature
Re: [vox-tech] mail / DNS question
Hey Pete: Maybe point your MX record at belial.ucdavis.edu? I know very little about this, but from looking at RECEIVED stamps on email: Received: from web9102.mail.yahoo.com (web9102.mail.yahoo.com [216.136.128.239]) It looks like the exchanger knows about the DN and the IP, so if there is a DN that points to the correct IP, the DN is all it needs? I don't know why it's true, I only know what is :) I don't know why you would need a DN instead of an IP, but that is the way that our records come up: # nslookup set type=MX dminfo.com Server: xx.xx.xx.xx Address:xx.xx.xx.xx#53 Non-authoritative answer: dminfo.com mail exchanger = 5 mail.dminfo.com. Authoritative answers can be found from: dminfo.com nameserver = the.big.nameserver dminfo.com nameserver = another.big.nameserver. mail.dminfo.com internet address = xx.xx.xx.xx the.big.nameserver internet address = xx.xx.xx.xx another.big.nameserver internet address = xx.xx.xx.xx Seems a bit weird to me. HTH, jan --- Peter Jay Salzman [EMAIL PROTECTED] wrote: hi all, oddly, i'm a newbie at this sort of thing... belial.ucdavis.edu is hosting the virtual domain roselug.org. i think i set up the MX records correctly. at least, nslookup looks good: p@satan% nslookup set type=MX roselug.org Server: 206.13.31.12 Address:206.13.31.12#53 Non-authoritative answer: roselug.org mail exchanger = 60 169.237.43.86. -- * correct IP * Authoritative answers can be found from: roselug.org nameserver = A.NS.JOKER.COM. roselug.org nameserver = B.NS.JOKER.COM. roselug.org nameserver = C.NS.JOKER.COM. A.NS.JOKER.COM internet address = 194.176.0.2 B.NS.JOKER.COM internet address = 194.245.101.19 C.NS.JOKER.COM internet address = 194.245.50.1 i reconfigured exim to include roselug.org as a local domain: local_domains = localhost:belial.ucdavis.edu:roselug.org yet mail to [EMAIL PROTECTED] is giving an error message which i don't really understand: A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: [EMAIL PROTECTED] all relevant MX records point to non-existent hosts: it appears that the DNS operator for this domain has installed an invalid MX record with an IP address instead of a domain name on the right hand side ok, keep in mind i'm new at this sort of thing. what's going wrong? why isn't an IP address ok to use on the right hand side? pete -- GPG Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Question: mod_dav.1.0.3 + apache.1.3.26 and CR/LFissues w/ MacOS+MSWin
On Thu, 4 Jul 2002, Micah Cowan wrote: HTTP (RFC 2616) specifically excludes text/* media types from having to be in canonical form, in sect. 3.7.1. Therefore, your arguments are unfortunately incorrect; a server is 100% within its rights to send CRLF, CR or LF- terminated output (in the entity-body, that is - naturally, headers and such are CRLF terminated). Every server I've ever come across (including Apache, which I have a great deal of respect for) sends text media exactly as it finds it, which is perfectly acceptable. It is required of the client to correctly interpret any of the above as line terminators (which is why pretty much every browser will display a text URL correctly, regardless of the EOL terminator - it's required to). However, the clients described above (at least, the ones I know about) don't do any parsing or display of text at all, and so aren't beholden to recognize *any* EOLs (even though they're being incredibly stupid not to). Yeah, I included this part of the RFC in one of the earlier message in this discussion here and in the WebDAV workgroup. I don't like it that the WebDAV isn't be considered an HTTP application with local OS rewriting of line breaks for saved text files. The item of arguement used by the workgroup effectively stated that they see that rule only applying when displaying the content in the browser and there is no explicit policy on how the files should be saved. (Not my ideas on ths subject.) I have enough evidence gathered to show files are sent with their own breaks over the wire to no longer feel any need to convince others of it. (Used a sniffer for testing to verify and saved content from various web browsers.) Perhaps web browsers other than Apache for Linux (like MS IIS) do the CRLF on the wire for body content transmission when the original text files do not have CRLF? I might expect something like that. I'm shocked that so many DAV clients have this mindset. And didn't one of them cite FTP? FTP *does* support transliteration, of course, so they don't seem to know what they're talking about - but how can they expect their products to be useful if they don't accomadate the OS? And it's such a trivial thing to do, too. I agree that it should be in the clients. Well, I now I have a proof of concept unweildly hack for the Apache web server with mod_dav to allow the server to deal with text files that have known text extentions. When they are puled from the server, the files are modified on the fly to meet the line breaks of the OS associated with the DAV client. When the DAV client pushes a file with same known text extentions to the server, the file is also modified to be stored in the server's line-break format. (Bi-directional linebreak conversion.) This of course does mean that the text file's content is at risk for change but only with linebreak chars (CR,LF). In addition to parsing being set to use only explicitly included extention names, it also only works on clients by their offered name - so if the clients ever get fixed, the routine for this can be removed/changed and left to the client to deal with appropriately. I have verified the files are changed as I wish, but there is one error box I need to eliminate that pops up when you store the files over DAV to the server. After it works for my users, I'll see what I can do about changing some clients out there and then throw up a web page to show how it was done. ]: -ME -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/CM$/IT$/LS$/S/O$ !d--(++) !s !a+++(-) C++$() U$(+$) P+$+++ L+++$(++) E W+++$(+) N+ o K w+$+ O-@ M+$ V-$- !PS !PE Y+ !PGP t@-(++) 5+@ X@ R- tv- b++ DI+++ D+ G--@ e+++ h(++)+ r*? z? --END GEEK CODE BLOCK-- decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Question: mod_dav.1.0.3 + apache.1.3.26 and CR/LFissues w/ MacOS+MSWin
ME writes: On Thu, 4 Jul 2002, Micah Cowan wrote: HTTP (RFC 2616) specifically excludes text/* media types from having to be in canonical form, in sect. 3.7.1. Therefore, your arguments are unfortunately incorrect; a server is 100% within its rights to send CRLF, CR or LF- terminated output (in the entity-body, that is - naturally, headers and such are CRLF terminated). Every server I've ever come across (including Apache, which I have a great deal of respect for) sends text media exactly as it finds it, which is perfectly acceptable. It is required of the client to correctly interpret any of the above as line terminators (which is why pretty much every browser will display a text URL correctly, regardless of the EOL terminator - it's required to). However, the clients described above (at least, the ones I know about) don't do any parsing or display of text at all, and so aren't beholden to recognize *any* EOLs (even though they're being incredibly stupid not to). Yeah, I included this part of the RFC in one of the earlier message in this discussion here and in the WebDAV workgroup. I don't like it that the WebDAV isn't be considered an HTTP application with local OS rewriting of line breaks for saved text files. The item of arguement used by the workgroup effectively stated that they see that rule only applying when displaying the content in the browser and there is no explicit policy on how the files should be saved. (Not my ideas on ths subject.) They're absolutely right, too - but that's no excuse. The goal of any piece of software is hopefully to be somewhat useful, and by not saving text files in an appropriate format, they're not being that. To me, it's analagous to mail clients - according to RFC822 or RFC2822, messages must be sent in canonical form; however, in practice, most mail clients are very forgiving toward other formats. Regardless of whether they accept them in canonical form, however, have you *ever* seen a mail client for UNIX that fails to save text/* messages in LF format? Not me. Same for the Mac and CR format. Because they'd be stupid to save them in any other format. Same for WebDAV clients - but apparently they haven't figured that out yet. Well, I now I have a proof of concept unweildly hack for the Apache web server with mod_dav to allow the server to deal with text files that have known text extentions. When they are puled from the server, the files are modified on the fly to meet the line breaks of the OS associated with the DAV client. When the DAV client pushes a file with same known text extentions to the server, the file is also modified to be stored in the server's line-break format. (Bi-directional linebreak conversion.) This of course does mean that the text file's content is at risk for change but only with linebreak chars (CR,LF). That reverse conversion shouldn't be necessary. But I don't count linebreak transliterations as content modifications, especially since they're probably allowed. In addition to parsing being set to use only explicitly included extention names, it also only works on clients by their offered name - so if the clients ever get fixed, the routine for this can be removed/changed and left to the client to deal with appropriately. You shouldn't use extensions at all - you should be basing it on the MIME type, no? (for receiving, that is - not sending, where the MIME type will be based on the extension anyway). -Micah ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] html question
Jim Angstadt writes: Table rows may be grouped into a table head, table foot, and one or more table body sections, using the THEAD, TFOOT and TBODY elements, respectively. This division enables user agents to support scrolling of table bodies independently of the table head and foot. When long tables are printed, the table head and foot information may be repeated on each page that contains table data. In practice, I've not seen these used in that way. Yeah - I always thought that'd be cool; especially with very large tables. Using them could also help provide hints to audio web browsers; or audio style sheets could be specifically written to take advantage of them. -Micah ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Question: mod_dav.1.0.3 + apache.1.3.26 and CR/LFissues w/ MacOS+MSWin
On Fri, 5 Jul 2002, Micah Cowan wrote: That reverse conversion shouldn't be necessary. But I don't count linebreak transliterations as content modifications, especially since they're probably allowed. Jeff pointed out that having bi-diretcional support might be a good idea in case I should ever want to edit them on a server or re-export them with another service. I figured it would be work my time too. :-) In addition to parsing being set to use only explicitly included extention names, it also only works on clients by their offered name - so if the clients ever get fixed, the routine for this can be removed/changed and left to the client to deal with appropriately. You shouldn't use extensions at all - you should be basing it on the MIME type, no? (for receiving, that is - not sending, where the MIME type will be based on the extension anyway). I did not want to have it adjust all text/* files because some (uu, hqx, etc) may be better off not modified. This allows me to specify which text/? to map over to alter. I may change to text/* over the long term, but for now, extention specific seems to work rather well 8-D -ME -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/CM$/IT$/LS$/S/O$ !d--(++) !s !a+++(-) C++$() U$(+$) P+$+++ L+++$(++) E W+++$(+) N+ o K w+$+ O-@ M+$ V-$- !PS !PE Y+ !PGP t@-(++) 5+@ X@ R- tv- b++ DI+++ D+ G--@ e+++ h(++)+ r*? z? --END GEEK CODE BLOCK-- decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Question: mod_dav.1.0.3 + apache.1.3.26 and CR/LFissues w/ MacOS+MSWin
On Fri, 5 Jul 2002, ME wrote: I did not want to have it adjust all text/* files because some (uu, hqx, etc) may be better off not modified. This allows me to specify which text/? to map over to alter. I may change to text/* over the long term, but for now, extention specific seems to work rather well 8-D q should not be there. hqx should have read hx. -ME -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/CM$/IT$/LS$/S/O$ !d--(++) !s !a+++(-) C++$() U$(+$) P+$+++ L+++$(++) E W+++$(+) N+ o K w+$+ O-@ M+$ V-$- !PS !PE Y+ !PGP t@-(++) 5+@ X@ R- tv- b++ DI+++ D+ G--@ e+++ h(++)+ r*? z? --END GEEK CODE BLOCK-- decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
