Hi Albrecht,
On 04/05/2017 01:29:16 PM Wed, Albrecht Dreß wrote:
Hi Peter:
Am 04.04.17 22:32 schrieb(en) Peter Bloomfield:
Oh, that is strange - actually, it should show the real counts here (i.e "..exceeds
the maximum allowed length 998").
Yes, it was actually "reply length 1153 exceeds the maximum allowed length 998"
Ouch. So someone is just violating the standard...
Anyway, a fix would be easy...
RFC 5322 also says that "Receiving implementations would do well to handle an arbitrarily
large number of characters in a line for robustness sake." To be "liberal in what [we]
accept from others", I feel that we should not treat an overlong line as a failure.
I see - I should read the standards *completely*... :-/
Attached is a simple patch, on top of the original package, which removes the
line length limit for POP3. It also removes the respective tests from the unit
test application.
I ran an older Balsa to download and delete that message from the server, and
it rendered just fine--I can send you a copy, but of course the long line(s)
might get cropped along the way!
As you are right that we should be liberal in accepting somewhat broken data, I
don't think it's necessary... Probably some broken spam, not worth the time to
investigate it!
Thanks for the patch! I'm using it, and I expect it to handle the next
violating mail, but I don't expect to get one for a week or so.
Would it be simpler to define MAX_POP_LINE_LEN as G_MAXSIZE? Or to keep the
NetClientPrivate struct opaque, perhaps NetClient could export
NET_CLIENT_MAX_LINE_LEN, and define MAX_POP_LINE_LEN as NET_CLIENT_MAX_LINE_LEN?
Best,
Peter
_______________________________________________
balsa-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/balsa-list
