Well, a bit of resistance yes, here's the _real_ issue: 1- if you don't put boundaries, attackers can leverage that 2- if you put boundaries with length=N someone will send a line with N+1
I can tell you that 1- is not even an option... which leaves us with 2-. We currently use a constant N value which is supposedly high enough that no client should ever hit it unless the message is badly crafted, or the SMTP protocol is not correctly implemented. The constant value has a ton of benefits too but lets put that aside, just keep in mind that it's set to the highest number of bytes we want to accept on a line. If we switch to a configurable M it will not solve the problem, you will simply have moved the issue elsewhere. It will still be possible to have a line that's M+1, you will just have pushed the boundary further... but if there's a rationale that M is better than N, despite the fact that it doesn't fix the problem, why wouldn't we update N instead ? There's no end to this because the _real_ issue is that some clients are not respecting standards. We can't fix that. We can be slightly tolerant and accept some obvious things (\n instead of \rn, slightly larger line, etc ...) but at some point we still have to put limits to how broken the clients are allowed to be when they communicate with us :-) On Fri, Aug 09, 2013 at 02:08:01PM -0700, Jason Barbier wrote: > Please indulge my ignorance would there be any resistance to making that a > configured item that you could configure exceptions to? > > Gilles Chehade <gil...@poolp.org> wrote: > >On Fri, Aug 09, 2013 at 05:45:52PM +0000, Craig Jones wrote: > >> Hello! > >> > > > >Hey, > > > > > >> I have slowly been migrating away from US based cloud services, and > >now run my mail off of a dedicated OpenBSD machine (logically with > >OpenSMTPD ;) ). For the transition phase, I have set up my cloud > >provider to forward and delete email to an account on my server. > >> > >> I just popped in the cloud provider to check out how things are > >going, and noticed a "500 Line too long" failure returned from > >OpenSMTPD for one of my forwards. This could be by design, but I > >thought it was worth mentioning since it's still a new offering of the > >project. The mail in question was just a simple billing email without > >anything fancy. I'll be happy to share more of the returned mail > >privately if needed. > >> > > > >No need to send the mail ;-) > > > >The problem is simple, we limit the length of lines so that they can > >fit > >in a fixed-length buffer. The RFC recommends that we accept lines up to > >about 1k: > > > >4.5.3.1.6. Text Line > > > > The maximum total length of a text line including the <CRLF> is 1000 > > octets (not counting the leading dot duplicated for transparency). > > This number may be increased by the use of SMTP Service Extensions. > > > >In practice, we bumped this and accept lines that are up to 2k because > >a > >lot of implementations were slightly off. You received the Line too > >long > >error because at least one line has exceeded the 2k limits. > > > > > >> Also, OT, but I've had a great time running popa3d with relayd for a > >secure connection, but it seems a bit hackish. Are there any drawbacks > >to using relayd as an ssl wrapper for pop3s? > >> > >> Cheers! > >> > > > >I am not too familiar with relayd, I used it a lot with http a while > >ago > >but I wasn't even aware you could use it in front of pop3. > > > >I don't see why there would be any drawback but what pop3d are you > >using > >that doesn't support SSL by default ? > > > >-- > >Gilles Chehade > > > >https://www.poolp.org > >@poolpOrg > > > >-- > >You received this email because you are subscribed to the > >"misc@opensmtpd.org" list > >To unsubscribe, send mail with subject: [misc@opensmtpd.org] unregister > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- Gilles Chehade https://www.poolp.org @poolpOrg -- You received this email because you are subscribed to the "misc@opensmtpd.org" list To unsubscribe, send mail with subject: [misc@opensmtpd.org] unregister
