[courier-users] RFC compliance: goodbye to courier MTA
After two years of courier MTA/IMAP use in a ISP (1k mailboxes), we learned that being so RFC compliant is only a big cost for us, in terms of helpdesk calls and customer unsatisfaction, so we are truly considering to change again our MTA (not the IMAP/POP3 server). Just one thought read RFC 1958, paragraph 3.9 3.9 Be strict when sending and tolerant when receiving. Implementations must follow specifications precisely when sending to the network, and tolerate faulty input from the network. When in doubt, discard faulty input silently, without returning an error message unless this is required by the specification. most of input discarded by courier is certainly faulty, but there is no doubt on how to process it and forward to the right recipient. so courier is not RFC 1958 compliant... I would like to hear some other opinions on this "strict compliance" from other users, especially from ISP. Many Thanks Giovanni --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] RFC compliance: goodbye to courier MTA
Thomas von Hassel wrote: I must say i have no problems with receiving mail, even badly formatted ones, with courier. All that can be turned off if you want to ? /thomas Maybe I forgot something about turning off errors... how ? One year ago I removed ERR8BITCONTENT as specified in the FAQ. The last two customers (in the last 6 days) had a problem in ERRBADBOUNDARY and a syntax error. My doubts are: - can I remove/comment the code for RFC2045_ERRBADBOUNDARY without breaking Courier code ? (according the Courier FAQs, this action does not seem to be healty) - how many times again must I to answer a customer reporting that he/she does not receive mail, wasting 20 minutes and discovering that's a "syntax error" again ? (no ERRBADBOUDARY nor ERR8BITCONTENT) [Usually she must call by phone the sender, ask him to send me a copy of the error... and so on] - I don't like to remove code, recomplie and run on my production server: it's time consuming and error prone. And it's untested. We also maintains ten linux boxes with sendmail + courierIMAP, and 20 boxes with windows + MDaemon and two with Excahnge 2000. Yes, they have only 20-100 users per box, but I never had a problem like the one mentioned with Courier (Exchange 2000 has many other problems ;) Giovanni --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] RFC compliance: goodbye to courier MTA
Eduardo Roldan wrote: Please tell us what are the top problems you face with your customers caused by the strict RFC compliance of Courier. I apologize. Thomas gave me the right solution opt BOFHBADMIME=accept(without spaces between '=' and accept!!!) in /etc/courier/bofh and that solved most, but not all, of my problems: a) Every HTML message sent ftom Outlook Express 5.5 Italian has an invalid 8bit section at the beginning. b) Some MIME body boundaries in OE5.5 italian for Macintosh are invalid. (maybe it's a CR-without-LF matter ???) [if you need, I'll send you the message text of the offending mail] Now, I have only some untested "syntax errors" to solve, but I have no data now. Looking into my logs, I see 20-30 correctly signaled "syntax error" per day, but some customer complained about it. I think the lack of "<>" around the RCPT TO: is the cause, as stated in the FAQs. an example: Mar 6 12:59:10 ns1 courieresmtpd: error,relay=:::68.117.187.56,msg="554 Syntax error - your mail software violates RFC 821.",cmd: RCPT TO: [EMAIL PROTECTED] thanks for all your help and please. update the FAQs !!! All my stress was generated by their advice to modify/recompile the code to remove MIME checks !!! I'll be back as soon as other customers will complain ! :-) Giovanni --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] Re: RFC compliance: goodbye to courier MTA
On Tue, 11 Mar 2003 18:35:00 -0500 Sam Varshavchik <[EMAIL PROTECTED]> wrote: > Giovanni Panozzo writes: > > > and that solved most, but not all, of my problems: > > > > a) Every HTML message sent ftom Outlook Express 5.5 Italian has > > an invalid 8bit section at the beginning. > > File a bug report with Microsoft. As you've noted, normally illegal 8-bit > content gets rejected. Now, it is acceptable, but an IMAP client is > explicitly notified that the 8bit content uses an unknown character set. Be more realistic Sam. Despite M$ has already corrected the bug in OE6.0, there are too many Italian OE5.5 around. We cannot force hundreds of unknown people with low IT knowledge to change its client: the customer will simply complain, complain, and complain again with our (small) helpdesk, and then change ISP. And this mean MONEY LOSS and TIME LOSS and UNSATISFIED CUSTOMER. The matter is simple in my point of view: Courier must accept malformed MIME messages or I'll change MTA. Changing MTA is much simpler and cheaper than changing hundred of OE5.5 around ! > > > b) Some MIME body boundaries in OE5.5 italian for Macintosh > > are invalid. (maybe it's a CR-without-LF matter ???) > > > > [if you need, I'll send you the message text of the offending mail] > > > > > > Now, I have only some untested "syntax errors" to solve, but > > I have no data now. Looking into my logs, I see 20-30 correctly > > signaled "syntax error" per day, but some customer complained > > about it. I think the lack of "<>" around the RCPT TO: is the cause, > > as stated in the FAQs. > > Correct. RFC 821 requires <> around the address. But RFC1958, paragraph 3.9, requires that Courier accepts it ! Giovanni --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
[courier-users] Help ! rfc2045 violations
I have just deployed courier mail server for about 400 users, but here in Italy we have a lot of mail coming into courier with ISO-8859-1 8bit charachters but with wrong headers (or no "Content-Type:" headers at all). I read the FAQ and I will recompile courier without the test code in courier/submit2.C but I would like to know the following: - Why the RFC2045 error notification e-mail is sent to the recipient ?? The fault is on the SENDER side: the recipient has done nothing worng and still cannot read the message... bad behavior ! This has overwhelmed our support tech personnel whith some calls. - I would like to not recompile courier for this option... many thanks for all ideas on this problem ---- Giovanni Panozzo <[EMAIL PROTECTED]> WorkUp SpA - via Capitano Alessio, 189 - 36027 ROSA' (VI) - ITALY Tel. +39 0424 584000 - Fax +39 0424 584099 ___ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
R: [courier-users] Re: Help ! rfc2045 violations
>> - Why the RFC2045 error notification e-mail is sent to the >recipient ?? > >It's not, it's bounced to the sender. > >> The fault is on the SENDER side: the recipient has done nothing > >And that's who receives the bounce. doesn't works maybe I forgot something... I just upgraded to 0.36.1, compiled as-is (without the FAQ's patch for rfc2045 msg) but the sender gets back nothing. I tested it with senders on different mailservers. And,of course, the recipient still receive the message in an attachment (very bad...). The test I have done from two different linux boxes, with sendmail and in two different locations, is: mail -s "8bit break test" [EMAIL PROTECTED] àèèòòàà . (if you can't read it, the line after "mail" contains only accented vowels of ISO8859-1 charset (ASCII CODE >= 128). ___ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
R: [courier-users] Re: Help ! rfc2045 violations / Outlook Express (8bits)
And worse: Outlook Express 5.5 italian version stars each mime HTML email with an accented wowel in the first part of the email. This is rejected by courier, this is only in OE5.5 not in OE6.0 or OE5.0 See the following: - Received: from ns1.avnet.it (ns1.avnet.it [:::195.246.192.14]) by ns1.workup.it with esmtp; Fri, 07 Dec 2001 16:22:15 +0100 Received: (from root@localhost) by ns1.avnet.it (8.11.3/8.11.3) id fB7FHfd18176 for [EMAIL PROTECTED]; Fri, 7 Dec 2001 16:17:41 +0100 Date: Fri, 7 Dec 2001 16:17:41 +0100 Message-Id: <[EMAIL PROTECTED]> From: Giovanni Panozzo <[EMAIL PROTECTED]> Subject: Catalogo Alexander To: Giovanni <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_NextPart_000_0010_01C17E47.CA9191C0" Messaggio in formato MIME composto da più parti. --=_NextPart_000_0010_01C17E47.CA9191C0 Content-Type: multipart/alternative; boundary="=_NextPart_001_0011_01C17E47.CA9191C0" --=_NextPart_001_0011_01C17E47.CA9191C0 ... ___ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
[courier-users] Re: Help ! rfc2045 violations
> >This was changed in 0.36.1. Instead of bouncing, the mail is converted to >a separate attachment. Before that, the message was bounced. >If you want to bounce it, you can still do it quite easily with a simple >mail filter. And the recipient will receive the message in an attachment again, so it will again call our thech support because it's not receiving the mails they are expecting (26 calls only in the first two days of courier !!!) . No, sorry, this is not the right solution. I removed the checks in the code as described in the FAQS, it's better. As I mentioened before, not only bad formatted stupid mailing lists inserts 8bit chars where they can't, also Outlook Express 5.5sp1 italian version, i some cases, does it. There are too much OE55 ita around to filter out these messages. ___ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
