> First, suggestion, turn off the bug in qmail, it is not the place for it, if > you want it, look to make a filter in ASSP that does this.
I think you have to get back to the basics... First of all qmail's behavior is NOT a bug. That message is not according to specs. Even repairing the message by a mailer is explicitly mentioned as bad behavior. The sender has a bug, so (optionally) refusing these mails in ASSP is a good idea. One should stop a malformed message as early in the chain as possible... Another mailer in the chain could accept the message and later on a mailer doesn't. The only way to inform the sender is through a NDR which may create backscatter.... The only "misconfiguration" on qmail is that it doesn't have extensive logging. Something which hasn't been necessary for 7 years. -----Oorspronkelijk bericht----- Van: Scott Haneda [mailto:talkli...@newgeo.com] Verzonden: zondag 18 oktober 2009 0:44 Aan: ASSP development mailing list Onderwerp: Re: [Assp-test] Bare LF's rejected by Qmail but undetected by ASSP I am not sure I would agree with that. It would create a mess. It is a proxy, and in all reality, 99% of the time, you do not want your MTA to send back much to ASSP. For example, say you have greylisting on in your MTA, which you should not, but every message, of perhaps thousands, is going to send back a message to ASSP, that says, try again later, over and over. The reality of this is, you would have a misconfiguration. You want your MTA to do no rejections of any form. ASSP does the rejections, your MTA, in most cases, should accept all email. First, suggestion, turn off the bug in qmail, it is not the place for it, if you want it, look to make a filter in ASSP that does this. Your problem seems to be that qmail is misconfigured. You previously stated in one of the threads here that the sender would try again. This tells me that qmail is not liking the bare lf, but then sending a temporary failure. There is a 0% chance that the bare LF is going to fix itself, so there is a 100% chance that qmail is responding incorrectly. Bare LF is not a transient error, it is not like greylisting, where there is a need to try again. What you are dealing with, is very much like if you did not have synchronization with your users database from ASSP to qmail. So ASSP passes along a message to user_not_th...@example.com. Qmail gets it, and sees that user_not_there does not exist. Instead of permanent failure, it says, try again. Since the try again rate is not determined by you, but by the sender, this would be a fair vector for DDOS'ing the ASSP proxy. If ASSP starts logging your bare LF return messages from qmail, all I need do is send a few hundred bare lf messages to you, and set the retry interval on the sending mta to 1 second. I will have now started to overload your ASSP by invoking your remote MTA to chatter way too much to ASSP. In most cases, ASSP is on the same subnet as the MTA, it has GB/s lines to use full resources, it is whitelisted by IP, it has full right to pass along the attack. This is also a known bug in qmail, as far as I remember. Search for "qmail bare lf patch". Personally, I would not patch it, just disable it, it is a setting that can not work. Hotmail sends a barelf in almost all their emails. Yes, it is rfc wrong, but there are too many legitimate MTA's out there that are broken. The only acceptable fix for this to me would be for ASSP to suggest the regex for a user to enabled LF checking, and only do so on a weighted basis. If it can not be done in regex, which I would find hard to believe, it is a feature not worth taking the time to implement. Maybe, just maybe, ASSP could have a "rewrite bare lf's" feature, but I am not sure I like that idea much either. My .02 -- Scott * If you contact me off list replace talklists@ with scott@ * On Oct 17, 2009, at 11:49 AM, Jean-Pierre van Melis wrote: > I still think it would improve ASSP if it would log MTA's response > code which it is proxying... ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Assp-test mailing list Assp-test@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/assp-test ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Assp-test mailing list Assp-test@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/assp-test
