I was asked to forward this to the list by Eric:
As a practical matter, 'bar.mime-type' had better be a proper DNS entry, or
a lot of places that do a "is the address at least putatively returnable?"
test (which *should* be essentially 100% - does anybody *not* check this?),
they will find it won't go very far.
As a second practical matter, I suspect that all the places that have already
decided that '*.biz' is a cesspool will be even more dubious accepting mail
from 'foo@bar.application.octet-stream'.
I'm still trying to figure out if this was for real, or if it was intended
to be posted 2 weeks ago and ICANN bureaucracy delayed it... 
Are you asking about actual MIME times 'text.plain', 'application.ps', and
so on, or are you asking about the labels that one popular operating system
sometimes uses to denote them, such as .exe, .ps and so on? Some of us use
systems that don't insist on extensions - and the major one that does has
a history of doing so poorly (how many times have we seen something with
a name of foo.exe labelled an image/jpg and ending up executed rather than
displayed?)
> > So this is (yet another) fishing expidition -- as MIME types are a handy
> > list, if any of those strings were present in a header, as in
> > mail-from-foo@bar.MIME-TYPE, would any well-known thingee choke?As a practical matter, 'bar.mime-type' had better be a proper DNS entry, or
a lot of places that do a "is the address at least putatively returnable?"
test (which *should* be essentially 100% - does anybody *not* check this?),
they will find it won't go very far.
It's got some interesting implications if it's: domain.exe ... 'did
you mean to go to domain.exe or execute domain.exe or display
domain.pdf ?' the UI folks will have a headache with that I bet... I
could see a rule set (simplified) like:
1) if -f domain.exe && -x domain.exe ; then exec(domain.exe)
2) if ! -f domain.exe ; then openlocation(domain.exe)
that would be fun in the world of site-finder, eh? I wonder what word
or excel or '$application' does with a random blob of html foo shoved
down it's throat??
Is it still the case that folks thinking about site-finder believe
'all the world is a web-browser' ??? Seriously?
As a second practical matter, I suspect that all the places that have already
decided that '*.biz' is a cesspool will be even more dubious accepting mail
from 'foo@bar.application.octet-stream'.
and here I took the 'bar.mime-type' to be: domain.exe or domain.mp3 or
domain.pdf ... Barry, which do you mean? (or which did Eric mean)
(monday morning list address probs,sorry)
Christopher Morrow wrote:
and here I took the 'bar.mime-type' to be: domain.exe or domain.mp3 or
domain.pdf ... Barry, which do you mean? (or which did Eric mean)
Yup. Infix dots pretty much means the whole label isn't in the DNS root.
It doesn't seem to be a big problem for .com...
It's got some interesting implications if it's: domain.exe ... 'did
you mean to go to domain.exe or execute domain.exe or display
domain.pdf ?' the UI folks will have a headache with that I bet... I
could see a rule set (simplified) like:1) if -f domain.exe && -x domain.exe ; then exec(domain.exe)
2) if ! -f domain.exe ; then openlocation(domain.exe)
Do UI folks today have trouble with:
domain.com
domain.pl
domain.ps
domain.sh
etc.?
Is there an application that treats a local file specifier and a host specifier indistinguishably? If so, how does it deal with strings (like those I listed above) that could potentially be executables as well as domain names?
Thanks,
-drc
oh I've been away from dos for too long (not long enough??)... so sure
maybe this isn't a problem 
or maybe the load from .com-ish things
isn't enough to notice?
-Chris
see previous 'not been using dos in a while ,doh!' sorry 
I suspect
.pl/.sh/.ps things are not normal user-application things (not windows
things) so perhaps these are handled sanely. Or maybe there aren't
reasons to look for this sort of thing over a network today so the
problem doesn't exist?
I know that in some applications (php things) you can open() a file or
a 'url', maybe these things do something sane already? or maybe it's a
corner case that doesnt' get tickled today with .exe or .gif ?
Still, is all the world a web-browser?? (displaying 'web content' to
things not web-browsers has already been proven to be a bad plan)
-Chris
If there's a software program out there currently that manages to conflate
the right-hand side of an e-mail address and a MIME type, it probably deserves
to lose.
By the same token, anybody advocating such conflation probably deserves to lose
as well...
or...
domain.mx
--bill
Is there an application that treats a local file specifier and a host specifier indistinguishably? If so, how does it deal with strings (like those I listed above) that could potentially be executables as well as domain names?
Looking at the 2007 DITL data (traces from DNS roots) its interesting
to see traffic for invalid TLDs that look just like filename
extensions. For example:
% of all TLD/
Queries extension
---------- -----------
0.182 txt
0.055 htm
0.051 c
0.049 lib
0.041 jpg
0.026 gif
0.012 html
0.011 php
0.005 exe
(Note, those really are percentages.)
I have no idea what applications are behind them, but it indicates
that there is software out there that has a hard time telling the
difference between a filename and a hostname. Or maybe its (ab)using
the DNS to help make the decision.
FWIW I was able to find one application, the text browser 'links,'
which accepts either filename or hostnames as its commandline
argument. From what I can tell its algorithm is something like
this:
- if tld/extension has two letters --> URL
- if less than two letters --> File
- if tld/extension is in list of known gTLDs --> URL
- else --> File
DW