Jerry,
You will find no-one more sympathetic to your anti-M$ sentiment, but lets try to keep this discussion coolheaded and civil ;) Remember RFC actually stands for Request For Comment, not Rigid Forced Conduct. To quote the RFC-Editor's FAQ: http://www.rfc-editor.org/rfcfaq.html _____ 3) Are all RFCs Internet standards documents? In a word, "NO!". Many RFCs have Informational or Experimental status and do not represent any kind of standard. They contain information that may be useful or important to retain in this archival document series. This is important to understand, because unscrupulous marketeers and a careless trade press sometimes falsely suggest that every RFC represents a standard, or that all standards have equal weight. The relationship among Internet technical specifications is often complex. _____ Anyone is free to follow these guidelines or not. If the RFC is good and effective it makes life a LOT easier for everyone involved if it is followed by everyone, but they are just guidelines. TCP/IP does not folow the "Official/Legal" network intercontectivy OSI model for how networking works. Both are standards, one is observed, one is pounded into every comp-sci major's head then forgotten after graduation. Now in our case, the RFC is not only the most "official" way, but probably the correct way for doing this. Unfortunatly not everyone is following it and since Courier users are minority they are unlikely to change immediatly. Since "They" are probably not going to do anything about this problem, discussing what "we" are going to do is a valid topic. One last thought on the "we." "We" can poll and discuss as much as we want, but Sam can and will do whatever he decides. Long live Open Source! We are not paying him one red cent so he can code however he likes and we are just d@mn lucky he bothers to share it with us and discuss it at all. (Ever tried to talk directly with the coders of Win2000?) "We" on the other hand are free to use his code or not and (if it is gpl?) if "we" have the knowledge and skill, roll up our sleeves and "fix" it how we like it. That said I hope he will give consideration to our suggestions as _I_ can't code my way out of a wet paper bag and will have to "suck it up" or find a new MTA. The Dean is going to have some very unpleasent things to say to me the first time he loses a sale or purchase on E-bay because of the email system I set up. Will he care that E-bay is formatting its messages incorrectly? Nope, he will blame me for picking Email Software that isn't compliant with E-bay. When I show him the RFC will he read it, understand it, and forgive me? No, he will just know that he just lost the $500 he was going to get for Aunt Myrtel's Collectble Dust Collector and is getting a black mark on his record for not completing a transaction. Sometimes being right isn't as important as being flexible. DANG! I'm a windbag. I'm going to shut up for a bit now and let the dust settle. Sorry about all the verbage. Especialy since Tim just said it better with less while I was writing this ;) Thanks! -- David Ehle Computing Systems Manager Illinois Institute of Technology Chicago IL On Wed, 28 Nov 2001, Jerry Amundson wrote: > I like the idea of a poll! > Let's simplifiy things and phrase the question like this, "Do you believe > standards should be followed as the talented, intelligent people who > designed them expect, or should we bend over backwards for Microsoft so Bill > Gates can rule the whole mother f*&^ing world?" > > People, stop bothering Sam, shut up, and point users to > http://pages.ebay.com/help/basics/select-support.html > please! > > Jerry > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Dirk > Kulmsee > Sent: Wednesday, November 28, 2001 11:21 AM > To: [EMAIL PROTECTED] > Subject: AW: [courier-users] Re: 8-bit content, no mime revisited > > > > -----Ursprungliche Nachricht----- > > Von: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]Im Auftrag von Sysop > > Gesendet: Mittwoch, 28. November 2001 17:18 > > An: David > > Cc: [EMAIL PROTECTED] > > Betreff: Re: [courier-users] Re: 8-bit content, no mime revisited > > > > > > David wrote: > > > > > > > > > > > Tim Hosking wrote: > > > > > >> on 27/11/01 11:05 pm, Sam Varshavchik at [EMAIL PROTECTED] wrote: > > >> > > >> > > >>> Tim Hosking writes: > > >>> > > >>> > > >>>> on 27/11/01 5:29 pm, Sam Varshavchik at [EMAIL PROTECTED] wrote: > > >>>> > > >>>> > > >>>>> Sysop writes: > > >>>>> > > >>>>>> Ok, now I'm getting this error from Ebay, what is a good > > >>>>>> resolution for > > >>>>>> this? > > >>>>>> > > >>>>> Get E-Bay to fix their mail software. > > >>>>> > > >>>>> > > >>>>>> Can you explain a bit more what this really is? > > >>>>>> > > >>>>>> Nov 27 14:27:09 anakin courieresmtpd: > > >>>>>> error,relay=::ffff:216.33.156.140,from=<[EMAIL PROTECTED]>: > > >>>>>> 550-This > > >>>>>> message has 8-bit content, but does not have the required MIME > > >>>>>> > > >>>>> Internet E-mail protocols require mail with 8-bit content > > to follow a > > >>>>> certain format. This, admittingly, has been widely violated in > > >>>>> the past due > > >>>>> to sloppy programming, and because simple mail servers of the past > > >>>>> ignored > > >>>>> or didn't care about mail content. > > >>>>> > > >>>>> Courier does care about mail content, since you also have IMAP and > > >>>>> webmail > > >>>>> in there, which does require mail content to be well-formed, in > > >>>>> order to be > > >>>>> able to properly handle it. Mis-formatted mail is therefore > > >>>>> returned as > > >>>>> undeliverable. > > >>>>> Except for rare exception like E-Bay, most of mail bounced for > > >>>>> this reason > > >>>>> is spam E-mail which is typically pumped out by sloppy, > > >>>>> poorly-designed > > >>>>> mailers. Usually from East Asia. > > >>>>> > > >>>>> See also: http://www.courier-mta.org/FAQ.html#esmtperr > > >>>>> > > >>>>> > > >>>> With respect Sam, although I agree wholeheartedly with you on all > > >>>> of the > > >>>> above points, I have noticed that recent versions of Courier seem > > >>>> to be > > >>>> rejecting somewhat more than older versions. I am baffled as to why > > >>>> this > > >>>> might be, as I have done a diff between 0.33 and 0.36 and can't see > > >>>> any > > >>>> obvious differences in the submitN modules. However, version > > 0.36 _is_ > > >>>> rejecting messages that were accepted by 0.33. > > >>>> > > >>>> I have examined some of the messages in question and can see > > >>>> nothing wrong > > >>>> with them. (of course, I don't really know what I'm looking for) > > >>>> > > >>>> Are you aware of any recent changes which could be behind this? > > >>>> After all, > > >>>> this seems to be a recurring thread - more so recently. I can > > >>>> forward some > > >>>> sample messages to you if that would help. > > >>>> > > >>> Well, I can certainly look at some sample messages and see what's > > >>> happening > > >>> there. Looking at the ChangeLog to rfc2045.c since version 0.33, I > > >>> only see > > >>> one possibility: > > >>> revision 1.26 > > >>> date: 2001/04/07 23:31:01; author: mrsam; state: Exp; lines: +31 -1 > > >>> Reject messages with ambiguous nested boundary delimiters. > > >>> > > >>> > > >>> This is a new check that rejects messages with ambiguous nested > > >>> boundary > > >>> delimiters. It's reported as a new bounce: > > >>> > > >>> 550-The RFC 2046 nested multipart MIME boundary delimiters in this > > >>> message > > >>> 550-are ambiguous, and cannot be parsed. See 'IMPLEMENTORS NOTE' in > > >>> 550 section 5.1.1 of <URL:ftp://ftp.isi.edu/in-notes/rfc2046.txt>. > > >>> > > >>> If this is what you're seeing, then that's that. This reference is > > >>> to a > > >>> paragraph that specifies that when looking for MIME boundary > > >>> delimiters, an > > >>> exact match is not required, only a match on the leading portion of > > >>> the MIME > > >>> boundary delimiter string. This is necessary so that a MIME boundary > > >>> delimiter of, for example, "xyz", would match the line "--xyz " - > > >>> that > > >>> contains some superfluous trailing spaces inserted by some oddball > > >>> mainframe > > >>> mail relay that chews mail content as fixed length records. > > >>> > > >>> This check came about when someone noticed that some versions of one > > >>> Windows > > >>> mail client generated multipart MIME content with a boundary delimiter > > >>> string of "foobar", which contained another nested multipart MIME > > >>> content > > >>> section with a boundary delimiter of "foobar.001". The problem here > > >>> is that > > >>> "--foobar.001" could then match either one of these two MIME boundary > > >>> delimiters. > > >>> Previously Courier did not check for this condition, but then the > > >>> mail ended > > >>> up in a folder, and parsed by Courier-IMAP. The boundary delimiters > > >>> would > > >>> then get completely misparsed, and the IMAP client would then end up > > >>> downloading a mangled message, all because some knucklehead hadn't > > >>> read the > > >>> specs. Therefore, the decision was made to bounce this stuff. > > >>> > > >>> Again, I'm assuming that you are referring to this new bounce > > category. > > >>> > > >> > > >> > > >> I have sent you an apparently plain text message that was rejected on > > >> the > > >> grounds that it had 8-bit content without the required headers. It was > > >> finally accepted after I modified submit2.C to skip the 8-bit check. > > >> > > >> As for nested multipart messages, I have encountered no problems with > > >> these > > >> yet (at least I don't think I have - If Courier has rejected any I > > >> didn't > > >> see it in my logs). > > >> > > >> Here's a wild idea: > > >> > > >> Courier receives a badly formed email. It returns a message to the > > >> sender > > >> reporting that it has been rejected for 'cos it sucks: > > >> > > >> 666-This message was generated by Microsoft software and is probably > > >> 666-evil. My mail server is against all evil and the perpetrators of > > >> 666-evil. If you do it again I'll bite yer bum now GO AWAY!! > > >> > > >> However, the evil message could well have been very important to the > > >> recipient who has been sitting up all night waiting to receive it (Yep, > > >> that's what happened in the case of the message I sent you). Courier > > >> therefore zips it up and sends it as an enclosure to the original > > >> recipient > > >> with a covering letter warning them to open it their own risk. This way > > >> Courier has protected itself, the client's email software AND slapped > > >> the > > >> wrists of the offending mailer. > > >> > > >> Alternatively (and probably more realistically) If Courier sees a > > >> message > > >> that doesn't conform, it could of course fix the message before > > >> delivering > > >> it. It can log information about the offending mailer to be included > > >> in a > > >> well published shit list. > > >> > > >> I for one would never condone the kind of rubbish generated by badly > > >> written > > >> mail software, but I also cannot condone a user having their email > > >> censored > > >> because someone sent it using a Microsoft product. Let's face it, MS > > >> software is not as rare as it should be. > > >> > > >> > > > > > > While I also applaud Couriers Strict RFC compliance, I have to agree > > > with Tim on this. In the current situation it may be the fool on the > > > other end who is making the error, but my users who will end up paying > > > the price when important mail is just not delivered. It was the E-bay > > > message rejection that really brought this home for me, as I KNOW that > > > several of my users, including my direct superior use Ebay. Not being > > > able to receive important mail regarding auctions and purchases... > > > that gets into deal breaker territory and starts making Courier seem > > > less attractive. > > > > > > "Courier? Oh, yeah its pretty good... fast, clean, compliant and > > > stable. But its kinda broken and can't recieve mail from Ebay so we > > > use qmail instead. Dang shame" > > > > > > Regardless of the fact that you are right, and they are wrong, that is > > > how its going to be perceived. :( Its unfair, unjust, and stupid, but > > > its true. > > > > > > Either of Tim's suggestions sounded pretty good as a way around the > > > problem. Please consider some flexibility on this issue. > > > > > > Thanks! > > > -- > > > David Ehle > > > Computing Systems Manager > > > Illinois Institute of Technology > > > Chicago IL > > > > > > > > > _______________________________________________ > > > courier-users mailing list > > > [EMAIL PROTECTED] > > > Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users > > > > I agree whole heartedly! > > > > Luckely, this was just a registration conformation email, but some of my > > users have been missing mail from certian places. It's just another > > case of MS making common a non standard that we all have to accept in > > order to get along..... if we don't, we will wind up back in a place > > where only courier users can send/recieve to other courier users, only > > MS users can send/recieve to other MS users, and so on and so forth, not > > a place that I would like to be.... > > > > > > > > _______________________________________________ > > courier-users mailing list > > [EMAIL PROTECTED] > > Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users > > We see the RFC204X problem discussed twice a week. How about a poll about > this? Like: do we want an option for "RFC compliance" or "world compliance" > at server startup? > > Dirk Kulmsee > > > > > _______________________________________________ > courier-users mailing list > [EMAIL PROTECTED] > Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users > > > _______________________________________________ > courier-users mailing list > [EMAIL PROTECTED] > Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users > _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
