Willy Tarreau:
> > Either you need to update the protocol spec (require non-fragmented
> > proxy lines)
>
> I have mixed opinions on this. On the one hand, we can't really impose
> lower layers segmentation behaviour, so from a layering perspective, it
> is not correct. On the other hand, the use cases for the protocol are
> very specific. We're the very first segment over the connection so we
> are always allowed to send at least one MSS. Nobody should sanely use
> this proxy line on connections with an MSS lower than the 116 bytes a
> max line may be for long IPv6 addresses and ports.
>
> So indeed, I'm tempted to follow your suggestion, it will ease processing
> for everyone and ensure that nobody tries sending fragmented lines. We'd
> rely on a sane lower layer and declare other cases out of scope.
It is quite usual that the first deployments of a protocol expose
some unexpected pain points.
Here, a minor protocol tweak (no proxy line fragmentation) makes
it possible to use MSG_PEEK lookahead without going into a busy-wait
loop.
Fragmentation makes no difference for a postscreen implementation
that reads the proxy line one character at a time until it reads
<CR><LF>, before it hands off the file descriptor to a real SMTP
server.
Wietse
