Re: Find abandoned packages
# [EMAIL PROTECTED] / 2002-11-26 13:41:36 -0800: Roman Neuhauser [EMAIL PROTECTED] writes: 4. You have already shown that you (falsely) think MIME email == HTML email. I surely didn't think that, but HTML was all I mentioned because I did (falsely) think that MIME email was almost always either HTML or complex stuff like MSFT Word or multipart things with images, etc. I didn't know it could be as simple as a non-MIME message with a MIME-Version: 1.0 header inserted, with or without a Content-type: text/plain; charset=something header. Per your suggestion, I've just read some of RFC-2045, but not all 31 pages or the several other RCFs which are essentially parts of it. But I think I've learned a few things new to me and, apparently, you. not so new, but I obviously misread the 8BITMIME stuff in RFC 2821 (which obsoletes 821). also, see e. g. SevenBitInput and EightBitMode Sendmail options. AFAIK, this has changed with MIME. RFC 822 restricts email messages to 7 bits (ASCII), ... Looks like we're both wrong, if non-STMP MTAs are allowed. MIME hasn't changed anything at the level I was thinking about (MTA) -- after MIME encoding, if any. First, both non-MIME and MIME messages MUST have only 7-bit data if they want to get thru a SMTP system. RFC-2045 says: RFC 821 (SMTP) restricts mail messages to 7bit US-ASCII data with lines no longer than 1000 characters including any trailing CRLF line separator. RFC 2821: The [SMTP BODY] content is textual in nature, expressed using the US-ASCII repertoire [1]. Although SMTP extensions (such as 8BITMIME [20]) may relax this restriction for the content body, and: Eight-bit message content transmission MAY be requested of the server by a client using extended SMTP facilities, notably the 8BITMIME extension [20]. 8BITMIME SHOULD be supported by SMTP servers. However, it MUST not be construed as authorization to transmit unrestricted eight bit material. 8BITMIME MUST NOT be requested by senders for material with the high bit on that is not in MIME format with an appropriate content-transfer encoding; servers MAY reject such messages. BTW, RFC 2045 specifies a way to pass non-ASCII messages through MTA's that assume all-ASCII world: the Content-Transfer-Encoding header. Yes. The default MIME encoding is none; the message must be 7-bit clean for SMTP MTAs. The offending message used quoted-printable which is almost like 7-bit, except that 8-bit characters (and a few 7-bit'ers) are encoded as =#, where # is the 8-bit value encoded as two ASCII HEX digits. (The offending message had that OK.) A more reliable (but unreadable) 7-bit encoding is base64. I know both q-p and base64. BTW, did you know that MSFT messaging programs use one or the other based on a handful of criteria? The content doesn't seem to matter, however. I haven't reliably tracked the decision process down, yet. Other encodings allow for encodings to 8-bit data, no encoding, etc. There's a whole other aspect of this that deserves mention. Even if MSFT software worked correctly, telling the truth about its weird character set and properly encoding it, it's unlikely that my MUA (Xemacs) would know how to decode it properly. If it did, it would need to either decode to the original weird character and support the display of that, or translate the decoded character set to some other character set, like probably Unicode. (Which Xemacs might even support, I don't know -- I HAVE noticed that has started displaying trademark symbols, for instance where it probably used to show it as an octal number (\###).) Mutt has IIRC provisions to get around this drain bamage: you can tell it to display messages from a particular messaging software that claim to use charset X using charset Y. I don't use this feature, though. -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Find abandoned packages
Roman Neuhauser [EMAIL PROTECTED] writes: 4. You have already shown that you (falsely) think MIME email == HTML email. I surely didn't think that, but HTML was all I mentioned because I did (falsely) think that MIME email was almost always either HTML or complex stuff like MSFT Word or multipart things with images, etc. I didn't know it could be as simple as a non-MIME message with a MIME-Version: 1.0 header inserted, with or without a Content-type: text/plain; charset=something header. Per your suggestion, I've just read some of RFC-2045, but not all 31 pages or the several other RCFs which are essentially parts of it. But I think I've learned a few things new to me and, apparently, you. 2. 3. and 4. lead me to the conclusion that it *was* a MIME message, despite 1. You are corrrect. I've been missing that fact that MIME is often used for (sort of) plain text messages. Here are the offending message's key headers with the false claim of charset, like you said: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable AFAIK, this has changed with MIME. RFC 822 restricts email messages to 7 bits (ASCII), ... Looks like we're both wrong, if non-STMP MTAs are allowed. MIME hasn't changed anything at the level I was thinking about (MTA) -- after MIME encoding, if any. First, both non-MIME and MIME messages MUST have only 7-bit data if they want to get thru a SMTP system. RFC-2045 says: RFC 821 (SMTP) restricts mail messages to 7bit US-ASCII data with lines no longer than 1000 characters including any trailing CRLF line separator. Second, non-MIME messages MAY have 8-bit data if they are using less restrictive transports (than SMTP). RFC-2045 says: In the absence of a MIME-Version field, a receiving mail user agent (whether conforming to MIME requirements or not) may optionally choose to interpret the body of the message according to local conventions. Many such conventions are currently in use and it should be noted that in practice non-MIME messages can contain just about anything. ... but MIME allows different charecter sets, like UTF8. What is still a possibility is that such a message will get mangled on its way by an MTA that assumes all data is ASCII, but I don't remember seeing anything like that happen. But assuming SMTP MTAs, those different character sets are in the same category as any other non-7-bit data; they require encoding to 7-bit data so that those ASCII-assuming MTAs won't mangle them. MIME has options for other (eg, 8-bit) encodings or no encoding, but they are likely to be mangled on the Internet. BTW, RFC 2045 specifies a way to pass non-ASCII messages through MTA's that assume all-ASCII world: the Content-Transfer-Encoding header. Yes. The default MIME encoding is none; the message must be 7-bit clean for SMTP MTAs. The offending message used quoted-printable which is almost like 7-bit, except that 8-bit characters (and a few 7-bit'ers) are encoded as =#, where # is the 8-bit value encoded as two ASCII HEX digits. (The offending message had that OK.) A more reliable (but unreadable) 7-bit encoding is base64. Other encodings allow for encodings to 8-bit data, no encoding, etc. There's a whole other aspect of this that deserves mention. Even if MSFT software worked correctly, telling the truth about its weird character set and properly encoding it, it's unlikely that my MUA (Xemacs) would know how to decode it properly. If it did, it would need to either decode to the original weird character and support the display of that, or translate the decoded character set to some other character set, like probably Unicode. (Which Xemacs might even support, I don't know -- I HAVE noticed that has started displaying trademark symbols, for instance where it probably used to show it as an octal number (\###).) Thanks for the education-inducing dialog. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Find abandoned packages
# [EMAIL PROTECTED] / 2002-11-21 12:57:32 -0800: Liquid [EMAIL PROTECTED] writes: If you check out /var/db/pkg it lists what ports are installed essentially. I don't know how to tell whether or not it?s a dependency though, so maybe someone else can answer that. I'd like to know that too come to think of it. Please keep non-ASCII characters out of list mail; we're not all MSFT-compliant, yet. (The ? above was a byte valued 222, octal.) From more info: http://www.cs.tut.fi/%7Ejkorpela/www/windows-chars.html Actually, it's not non-ASCII characters or MSFT products that causes problems. It's fucked up mail clients that send messages that fallaciously claim to be using charset X when they're really in Y. Incidentally, these mail clients are MSFT products. -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Find abandoned packages
Roman Neuhauser [EMAIL PROTECTED] writes: Actually, it's not non-ASCII characters or MSFT products that causes problems. It's fucked up mail clients that send messages that fallaciously claim to be using charset X when they're really in Y. Incidentally, these mail clients are MSFT products. Please correct me if you really know better (I'm no email expert), but I'm fairly sure that e-mail is still supposed to be 7-bit clean so it can go (without encoding/decoding) through 7-bit lines (maybe with parity on the 8th line), etc. Or has this been officially changed? What you say about MSFT's fallacious charset claims is certainly true of HTML/HTTP, except that more often they make no claim of charset at all, expecting the world to conform to their charset by default. As for HTML/MIME, I don't know if MIME supports the encoding of non-7-bit HTML characters into 7-bit code, or if it expects 7-bit-clean HTML. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Find abandoned packages
On 2002-11-25 11:49, Gary W. Swearingen [EMAIL PROTECTED] wrote: Roman Neuhauser [EMAIL PROTECTED] writes: Actually, it's not non-ASCII characters or MSFT products that causes problems. It's fucked up mail clients that send messages that fallaciously claim to be using charset X when they're really in Y. Incidentally, these mail clients are MSFT products. Please correct me if you really know better (I'm no email expert), but I'm fairly sure that e-mail is still supposed to be 7-bit clean so it can go (without encoding/decoding) through 7-bit lines (maybe with parity on the 8th line), etc. Or has this been officially changed? Partly true. Mail servers, at least those who conform to the established standards, go at great lengths to maintain compatibility with their peers that do not support the full range of 8-bit ASCII. It is also true though, that flawed mail clients can push down into the connection to their outgoing SMTP server messages that do not have proper headers to allow the server to parse and convert the 8-bit characters correctly. This is often cause by either a) bugs in the mail client software, or b) misconfigured clients. Outlook is infamous for its habit of sending 8-bit characters unencoded in MIME messages that lack proper Content-Type: headers. The result is rather interesting to look upon, when the message passes through multiple SMTP servers, with different settings each. As for HTML/MIME, I don't know if MIME supports the encoding of non-7-bit HTML characters into 7-bit code, or if it expects 7-bit-clean HTML. MIME supports anything. 7-bit US ASCII characters. 8-bit characters in a multitude of encodings and character sets. Even UTF8 or Unicode. MIME itself doesn't dictate anything about the way a client handles the representation of the characters that are shown to the user. It only defines a standard way of converting and encoding these in a smaller character set, that is guaranteed to be easy to transmit over links that support ASCII. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Find abandoned packages
Giorgos Keramidas [EMAIL PROTECTED] writes: It is also true though, that flawed mail clients can push down into the connection to their outgoing SMTP server messages that do not have proper headers to allow the server to parse and convert the 8-bit characters correctly. This is often cause by either a) bugs in the mail client software, or b) misconfigured clients. I thought SMTP mail servers didn't touch the body of messages. One mail client encodes stuff via MIME protocols to 7-bit data which it places in the body, servers pass it around (changing headers), and another client decodes the 7-bit body via MIME. You seem to imply that servers mess with the body. Why would it need to? Mind explaining? Outlook is infamous for its habit of sending 8-bit characters unencoded in MIME messages that lack proper Content-Type: headers. The result is rather interesting to look upon, when the message passes through multiple SMTP servers, with different settings each. I didn't realize that the other poster was referring to MIME mail (partially because the message I complained about didn't use MIME). Yes, I've seen really messed up MIME mail. But are you sure that the 8-bit data was put there by SMTP servers, or by the receiving client which has been confused by MSFT-errant headers or by the MSFT client that didn't properly 7-bit-encode it to begin with? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Find abandoned packages
On 2002-11-25 15:52, Gary W. Swearingen [EMAIL PROTECTED] wrote: Giorgos Keramidas [EMAIL PROTECTED] writes: It is also true though, that flawed mail clients can push down into the connection to their outgoing SMTP server messages that do not have proper headers to allow the server to parse and convert the 8-bit characters correctly. This is often cause by either a) bugs in the mail client software, or b) misconfigured clients. I thought SMTP mail servers didn't touch the body of messages. One mail client encodes stuff via MIME protocols to 7-bit data which it places in the body, servers pass it around (changing headers), and another client decodes the 7-bit body via MIME. You seem to imply that servers mess with the body. Why would it need to? Mind explaining? They shouldn't mess with it, unless told to. You're right. I was referring to the way input characters are treated by the program that implements the SMTP service. If the program makes stupid assumptions about the size of character data, and uses data types in C like `char' instead of `int' then it's not just the client's fault when 8-bit data get mangled. Outlook is infamous for its habit of sending 8-bit characters unencoded in MIME messages that lack proper Content-Type: headers. The result is rather interesting to look upon, when the message passes through multiple SMTP servers, with different settings each. I didn't realize that the other poster was referring to MIME mail (partially because the message I complained about didn't use MIME). Yes, I've seen really messed up MIME mail. But are you sure that the 8-bit data was put there by SMTP servers, or by the receiving client which has been confused by MSFT-errant headers or by the MSFT client that didn't properly 7-bit-encode it to begin with? It's usually the sending clients that don't properly encode messages, and assume that the receiving end will Know What To Do(TM). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Find abandoned packages
# [EMAIL PROTECTED] / 2002-11-25 11:49:17 -0800: Roman Neuhauser [EMAIL PROTECTED] writes: Actually, it's not non-ASCII characters or MSFT products that causes problems. It's fucked up mail clients that send messages that fallaciously claim to be using charset X when they're really in Y. Incidentally, these mail clients are MSFT products. Please correct me if you really know better (I'm no email expert), but I'm fairly sure that e-mail is still supposed to be 7-bit clean so it can go (without encoding/decoding) through 7-bit lines (maybe with parity on the 8th line), etc. Or has this been officially changed? AFAIK, this has changed with MIME. RFC 822 restricts email messages to 7 bits (ASCII), but MIME allows different charecter sets, like UTF8. What is still a possibility is that such a message will get mangled on its way by an MTA that assumes all data is ASCII, but I don't remember seeing anything like that happen. BTW, RFC 2045 specifies a way to pass non-ASCII messages through MTA's that assume all-ASCII world: the Content-Transfer-Encoding header. What you say about MSFT's fallacious charset claims is certainly true of HTML/HTTP, except that more often they make no claim of charset at all, expecting the world to conform to their charset by default. As for HTML/MIME, I don't know if MIME supports the encoding of non-7-bit HTML characters into 7-bit code, or if it expects 7-bit-clean HTML. Looks like you confuse HTML and MIME, which are two distinct things that have moreless nothing in common. For example, this message is a MIME message (as opposed to an RFC 822 message, yet it doesn't contain any HTML). If we restrict this to MIME: I routinely see messages from Outlook and its brethren claiming they're ISO-8859-2, but containing characters from outer space. -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Find abandoned packages
# [EMAIL PROTECTED] / 2002-11-25 15:52:42 -0800: Giorgos Keramidas [EMAIL PROTECTED] writes: It is also true though, that flawed mail clients can push down into the connection to their outgoing SMTP server messages that do not have proper headers to allow the server to parse and convert the 8-bit characters correctly. This is often cause by either a) bugs in the mail client software, or b) misconfigured clients. I thought SMTP mail servers didn't touch the body of messages. One mail client encodes stuff via MIME protocols to 7-bit data which it places in the body, servers pass it around (changing headers), and another client decodes the 7-bit body via MIME. You seem to imply that servers mess with the body. Why would it need to? Mind explaining? Please read RFC 2045. It's pretty short and easy to parse. -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Find abandoned packages
# [EMAIL PROTECTED] / 2002-11-25 15:52:42 -0800: Giorgos Keramidas [EMAIL PROTECTED] writes: Outlook is infamous for its habit of sending 8-bit characters unencoded in MIME messages that lack proper Content-Type: headers. The result is rather interesting to look upon, when the message passes through multiple SMTP servers, with different settings each. I didn't realize that the other poster was referring to MIME mail (partially because the message I complained about didn't use MIME). 1. I don't have the original message because my maildrop filter sends all list posts from MSFT email programs to /dev/null. 2. That particular bug I've seen quoted in your reply to the original message is an Outlook [Express]-specific thing. I haven't seen it produced by the Lotus Notes client (at least as broken as OE, possibly more) or anything else. 2. I'm not aware of any method (and doubt there is one) to make Outlook send an RFC 822 message. All it can create is it's crippled idea of MIME. 4. You have already shown that you (falsely) think MIME email == HTML email. 2. 3. and 4. lead me to the conclusion that it *was* a MIME message, despite 1. -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Find abandoned packages
In the last episode (Nov 21), Pascal Giannakakis said: If you check out /var/db/pkg it lists what ports are installed essentially. I don't know how to tell whether or not it?s a dependency though, so maybe someone else can answer that. I'd like to know that too come to think of it. pkg_info or pkg_version - would be quite the same in this situation. What i need is an intelligent programm that finds old stuff, and best even offers a yes / no dialog to uninstall it. Lots of packages don't have dependencies because they are standalone programs, like netcat. You probably don't want to prompt to deinstall those. Yes, that is what i want. On my system there aren't a lot of packages, and usually i know which i installed. The solution to my original problem is very easy - i found it by accident, when i was reading docs out of boredom and curiosity! :) pkg_deinstall -rn *portname* -r will show all packages that require *portname* to be installed -n will prevent pkg_deinstall from actually performing the actions It may also be run with -Rn instead of -rn to find what packages *portname* needs to run. Yet this does not show a list, i still need to pick the port manually out of the pkg_version or pkg_info list. Though better than nothing. What you really need is a flag somewhere in the package list saying I was force-installed because of a dependency, so you can look for packages with this flag but no dependant packages. Unfortunately, this flag doesn't exist :) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
RE: Find abandoned packages
If you check out /var/db/pkg it lists what ports are installed essentially. I don't know how to tell whether or not its a dependency though, so maybe someone else can answer that. I'd like to know that too come to think of it. -SM -Original Message- From: [EMAIL PROTECTED] [mailto:owner-freebsd- [EMAIL PROTECTED]] On Behalf Of Pascal Giannakakis Sent: November 21, 2002 8:00 AM To: [EMAIL PROTECTED] Subject: Find abandoned packages Lo folks, how do you find installed ports / packages on your system, that are not required by others? Thanx. -- +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
RE: Find abandoned packages
If you check out /var/db/pkg it lists what ports are installed essentially. I don't know how to tell whether or not its a dependency though, so maybe someone else can answer that. I'd like to know that too come to think of it. pkg_info or pkg_version - would be quite the same in this situation. What i need is an intelligent programm that finds old stuff, and best even offers a yes / no dialog to uninstall it. -- +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Find abandoned packages
Liquid [EMAIL PROTECTED] writes: If you check out /var/db/pkg it lists what ports are installed essentially. I don't know how to tell whether or not it?s a dependency though, so maybe someone else can answer that. I'd like to know that too come to think of it. Please keep non-ASCII characters out of list mail; we're not all MSFT-compliant, yet. (The ? above was a byte valued 222, octal.) From more info: http://www.cs.tut.fi/%7Ejkorpela/www/windows-chars.html Back to the question: The following is from my ports notes. It doesn't solve the problem, but should provide some clues. Try just pkg_tree -v. -- To make list of ports listed from most-dependent to not dependent (best make order). pkg_tree -v | sed -e 's/\\__/ /' | tr '|' ' ' | sort -u | tr -d ' ' |/tmp/pkgup To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Find abandoned packages
In the last episode (Nov 21), Pascal Giannakakis said: If you check out /var/db/pkg it lists what ports are installed essentially. I don't know how to tell whether or not it?s a dependency though, so maybe someone else can answer that. I'd like to know that too come to think of it. pkg_info or pkg_version - would be quite the same in this situation. What i need is an intelligent programm that finds old stuff, and best even offers a yes / no dialog to uninstall it. Lots of packages don't have dependencies because they are standalone programs, like netcat. You probably don't want to prompt to deinstall those. What you really need is a flag somewhere in the package list saying I was force-installed because of a dependency, so you can look for packages with this flag but no dependant packages. Unfortunately, this flag doesn't exist :) -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
