Andy wrote:
> Minor correction; replace "then" with "than".
>
> Also, RFC 5322 2.1.1 does not "require" that the lines be no more than
> 78 bytes, only that it's highly recommended that they not exceed that.
> The actual line limit is 998 bytes.
Good catches, thank you!
And thank you, Phillipp.
Thus said David Levine on Sun, 17 Sep 2023 21:51:04 -0400:
> How about this?
>
> mhbuild now folds header field bodies to avoid lines with more
> then 78 bytes.
>
> This is required by RFC 5322 2.1.1. Line Length Limits.
>
Minor correction; replace "then" with "than".
Also, RFC
[2023-09-17 21:51] David Levine
> > A format-patch is attached.
>
> Thanks. I think that the commit message should note that only header field
> bodies are folded. And because folding can only occur a
> t whitespace, it is possible to end up with more than 78 bytes in a line.
> How about
Philipp wrote:
> A format-patch is attached.
Thanks. I think that the commit message should note that only header field
bodies are folded. And because folding can only occur at whitespace, it is
possible to end up with more than 78 bytes in a line. How about this?
mhbuild now folds
[2023-09-17 18:32] David Levine
> Philipp wrote:
>
> > Good to hear. Do you want a format-patch of the final version?
>
> Sure, that would be great. Or, all I need is the commit message. I just
> verified that I'm using your last code submission with no
> changes.
A format-patch is attached.
Philipp wrote:
> Good to hear. Do you want a format-patch of the final version?
Sure, that would be great. Or, all I need is the commit message. I just
verified that I'm using your last code submission with no changes.
> > One issue to resolve first: the References header field at the end of
[2023-09-16 12:36] David Levine
> Phillipp, I've been using your header field folding for a few weeks and I
> really like it. I think that it should be committed, it's big step forward.
Good to hear. Do you want a format-patch of the final version?
> One issue to resolve first: the
Phillipp, I've been using your header field folding for a few weeks and I
really like it. I think that it should be committed, it's big step forward.
One issue to resolve first: the References header field at the end of this
message ends with:
Philipp wrote:
> This was to vague asked by me. I was woundering about the API. Should
> fold construct a string of the complete field or only the body.
I think the wwy you have it currently implemented is fine: only the body
but it accounts for the length of the name.
David
[2023-08-31 22:14] David Levine
> Philipp wrote:
>
> > I have a version with charstring_t attached. I'm unsure if it's better
> > to only fold the body or include the field name. The version attached
> > only fold the body.
>
> RFC 5322 §2.2.3 only mentions folding the body. And field names
>
Philipp wrote:
> I have a version with charstring_t attached. I'm unsure if it's better
> to only fold the body or include the field name. The version attached
> only fold the body.
RFC 5322 §2.2.3 only mentions folding the body. And field names
can't have whitespace. So I think that only a
[2023-08-28 11:53] Philipp
> [2023-08-27 22:00] David Levine
> > Philipp wrote:
> >
> > > [2023-08-27 09:29] David Levine
> > > >
> > > > My only comment on the code itself is that I prefer functions that
> > > > just do one thing. So I would implement a fold function that just
> > > >
Philipp wrote:
> One question about charstring_t: Why does charstring_push_back_chars()
> not use memcpy?
It has the side effect of advancing cur: s->cur++.
David
Philipp wrote:
> Ah, I forgott the early continue. The attached version sould work.
It does. I'm sending this message using it.
David
[2023-08-27 22:00] David Levine
> Philipp wrote:
>
> > [2023-08-27 09:29] David Levine
> > >
> > > My only comment on the code itself is that I prefer functions that
> > > just do one thing. So I would implement a fold function that just
> > > modifies a string, and leave the fprintf/fwrite to
[2023-08-27 22:00] David Levine
> > For the blank lines you mentioned: Can you test the attached version of
> > my patch. If this don't fix your problem, can you provide a sample mail?
>
> The patch didn't fix it. The attached sample shows the added line
> when run through mhfixmsg:
>
> $
Philipp wrote:
> [2023-08-27 09:29] David Levine
> >
> > My only comment on the code itself is that I prefer functions that
> > just do one thing. So I would implement a fold function that just
> > modifies a string, and leave the fprintf/fwrite to output_headers().
>
> I have thought about
[2023-08-27 09:29] David Levine
> Philipp wrote:
>
> > Do you only test the patch or have you looked at the code? It would
> > be nice to get some feedback on the implementation.
>
> My only comment on the code itself is that I prefer functions that
> just do one thing. So I would implement a
I wrote:
> There is a bigger issue, however. output_headers() gets called by
> other code, such as mhfixmsg via output_message_fp(). So the change
> as-is interferes badly with it. I haven't looked for a better place
> to fold the header fiels, but we'll have to find one.
Alternatively, maybe
Philipp wrote:
> Do you only test the patch or have you looked at the code? It would
> be nice to get some feedback on the implementation.
My only comment on the code itself is that I prefer functions that
just do one thing. So I would implement a fold function that just
modifies a string, and
[2023-08-26 17:42] David Levine
> Philipp wrote:
> I agree. I'm sending this message using your patch. I'd like to
> exercise it for a few days before committing.
No problem, take your time.
Do you only test the patch or have you looked at the code? It would
be nice to get some feedback on
Philipp wrote:
> That said, my code detects lines without WSP (and are longer then 78
> bytes). Some rfc 2047 encoding could be added there. But first the
> folding should be implemented.
I agree. I'm sending this message using your patch. I'd like to
exercise it for a few days before
[2023-08-25 23:46] Steffen Nurpmeso
> Steffen Nurpmeso wrote in
> <20230825213130.xthnk%stef...@sdaoden.eu>:
> |Philipp wrote in
> | <93c190b84a23e620d07b9504f619b1f2.phil...@bureaucracy.de>:
> ||[2023-08-24 21:07] Philipp Takacs
> ||> [2023-08-23 14:29] Philipp
> ||>> [2023-08-20 22:14]
Steffen Nurpmeso wrote in
<20230825213130.xthnk%stef...@sdaoden.eu>:
|Philipp wrote in
| <93c190b84a23e620d07b9504f619b1f2.phil...@bureaucracy.de>:
||[2023-08-24 21:07] Philipp Takacs
||> [2023-08-23 14:29] Philipp
||>> [2023-08-20 22:14] David Levine
||>>> Ken Hornstein wrote:
| ...
Hello.
Philipp wrote in
<93c190b84a23e620d07b9504f619b1f2.phil...@bureaucracy.de>:
|[2023-08-24 21:07] Philipp Takacs
|> [2023-08-23 14:29] Philipp
|>> [2023-08-20 22:14] David Levine
|>>> Ken Hornstein wrote:
...
|I have tested this and fixed some bugs. A commit with a test is
[2023-08-24 21:07] Philipp Takacs
> [2023-08-23 14:29] Philipp
> > [2023-08-20 22:14] David Levine
> > > Ken Hornstein wrote:
> > >
> > > > [Phillip wrote:]
> > > > >Or in output_headers(). I'm not sure if there an extra options would be
> > > > >required.
> > > >
> > > > That is one option.
[2023-08-23 14:29] Philipp
> [2023-08-20 22:14] David Levine
> > Ken Hornstein wrote:
> >
> > > [Phillip wrote:]
> > > >Or in output_headers(). I'm not sure if there an extra options would be
> > > >required.
> > >
> > > That is one option. Another is that repl(1) could do a better job; I
> > >
Philipp wrote:
> I have had a quick look at fold() and just calling fold() would produce
> incorrect results. fold() just insert '\n ' after 76 characters[0]. But
> to correct fold a field you must insert a '\n' befor a whitespace.
>
> I'll try to implement a corrent fold funktion on the weekend.
[2023-08-20 22:14] David Levine
> Ken Hornstein wrote:
>
> > [Phillip wrote:]
> > >Or in output_headers(). I'm not sure if there an extra options would be
> > >required.
> >
> > That is one option. Another is that repl(1) could do a better job; I
> > suppose that is the fault of mhl.
>
> mhl is
Ken Hornstein wrote:
> [Phillip wrote:]
> >Or in output_headers(). I'm not sure if there an extra options would be
> >required.
>
> That is one option. Another is that repl(1) could do a better job; I
> suppose that is the fault of mhl.
mhl is used for display. And a user can substitute their
Philipp wrote:
> Thanks for pointing this out, but now I'm more confused. Whats the point
> of LENERR (in contrast to FMTERR)? But this is a diffrent discussion.
There isn't much point to differentiaing LENERR from FMTERR. The error
messages are different when they're set, which might help the
>> Thank you for pointing that out. Header field folding does need to be
>> properly implemented. It would be a great contribution if someone has
>> the bandwidth.
>
>I have looked a bit at it. I found two places where this could be
>implemented:
>
>Either as part of encode_rfc2047(), this
[2023-08-18 21:48] David Levine
> > I have noticed that mhbuild don't implement header field folding.
> > Specialy for the References field this might cause problems, when you
> > use it to feed a mail build by mhbuild to a tool which checks the
> > line length.
>
> Thank you for pointing that
Philipp wrote:
> I have noticed that mhbuild don't implement header field folding.
> Specialy for the References field this might cause problems, when you
> use it to feed a mail build by mhbuild to a tool which checks the
> line length.
Thank you for pointing that out. Header field folding
Hi
I have noticed that mhbuild don't implement header field folding.
Specialy for the References field this might cause problems, when you
use it to feed a mail build by mhbuild to a tool which checks the
line length.
Also I don't get the code. In uip/mhbuildsbr.c:359 a LENERR is handled
with
35 matches
Mail list logo
