Mailing List Archive

[Bug 455] fakereject behaves differently than deny message
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=455





------- Comment #1 from holmgren@lysator.liu.se 2007-01-26 22:34 -------
On Friday 26 January 2007 12:03, mh+exim-bugzilla@zugschlus.de wrote:
> When an acl accepts a message with control = fakereject, the rejection
> message is not split into continuation lines.

I suggest moving the code that does that with messages set through message
= ... from acl_check() to smtp_respond(). I hope it will cover all cases but
I'm not sure.

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[Bug 455] fakereject behaves differently than deny message [ In reply to ]
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=455


holmgren@lysator.liu.se changed:

What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|ph10@hermes.cam.ac.uk |holmgren@lysator.liu.se
Status|NEW |ASSIGNED




------- Comment #2 from holmgren@lysator.liu.se 2007-01-27 17:50 -------
Created an attachment (id=54)
--> (http://www.exim.org/bugzilla/attachment.cgi?id=54&action=view)
Let smtp_respond() perform the wrapping

I post the full function here as well. It features some improvements over the
old code:
- Can break lines at separators, not just spaces (not necessarily a good idea
since we should probably avoid wrapping email addresses).
- Enforces the maximum response line length (512 bytes).
- Trims off whitespace that ends up at the end or beginning of a line (the
later not necessarily a wanted behaviour).
- Sends one long line if no_multiline_responses is set. Can the software that
can't handle multiline responses handle long lines?

I had an idea that we should only break after a colon if everything thereafter
up to the next newline or the end of the string can fit on the next line, but
that's probably not worth it.

void
smtp_respond(uschar* code, int codelen, BOOL final, uschar *msg)
{
int esclen = 0;
uschar *esc = US"";

if (!final && no_multiline_responses) return;

if (codelen > 4)
{
esc = code + 4;
esclen = codelen - 4;
}

while (isspace(*msg)) msg++;

for (;;)
{
int i;
uschar *eol = NULL, *colon = NULL, *p = msg;

/* Break a long message into a multiline message. This works as follows:
If a newline or terminating null is found, stop.
If the line so far is at least 35 characters and a suitable break point
is found, remember it. Colons are remembered specially.
If the line so far is at least 75 characters and a suitable break point
has been found, stop.
If the maximum line length is reached, stop even if no break point has
been found.
If no_multiline_responses is true, we don't look for places to break,
only newlines. Lines can be long instead.
*/
for (i = 0; (!eol || i < 75) && i < 509 - codelen; i++)
{
if (*p == '\0' || *p == '\n')
{
eol = p;
break;
}
else if (i > 35 && !no_multiline_responses)
{
if (strchr(",;:!?)]}>/&+-=*^|", *(p-1))
|| strchr("([{<#$\\", *p))
{
eol = p;
if (*(p-1) == ':') colon = eol;
}
else if (isspace(*p)) eol = p;
}
p++;
}

/* We prefer breaking after a colon if there is one */
if (colon) eol = colon;

if (!eol) eol = p; /* Last resort */
else p = eol;

if (*msg)
while (isspace(*(eol-1))) eol--; /* Trim end of line */

while (isspace(*p)) p++; /* See if there is anything but space left */

if (*p == '\0' || no_multiline_responses) /* Apparently we found the last
line */
{
smtp_printf("%.3s%c%.*s%.*s\r\n", code, final? ' ':'-', esclen, esc,
(int)(eol - msg), msg);
return;
}
else
{
smtp_printf("%.3s-%.*s%.*s\r\n", code, esclen, esc, (int)(eol - msg), msg);
msg = p;
}
}
}

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[Bug 455] fakereject behaves differently than deny message [ In reply to ]
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=455





------- Comment #3 from holmgren@lysator.liu.se 2007-02-02 16:45 -------
Any comments on this issue, Phil?

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: [Bug 455] fakereject behaves differently than deny message [ In reply to ]
On Fri, 2 Feb 2007, holmgren@lysator.liu.se wrote:

> Any comments on this issue, Phil?

Patience! Should get to it next week sometime.

--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[Bug 455] fakereject behaves differently than deny message [ In reply to ]
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=455





------- Comment #4 from ph10@hermes.cam.ac.uk 2007-02-02 17:02 -------
On Fri, 2 Feb 2007, holmgren@lysator.liu.se wrote:

> Any comments on this issue, Phil?

Patience! Should get to it next week sometime.

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[Bug 455] fakereject behaves differently than deny message [ In reply to ]
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=455





------- Comment #5 from ph10@hermes.cam.ac.uk 2007-02-05 15:15 -------
I'm afraid I do not like this patch. Three reasons: (a) It changes the function
smtp_respond(), which currently does "output this text, respecting newlines"
into one that takes decisions about splitting the text. I'd rather have the
splitting decisions taken separately. (b) The output from an ACL does not
necessarily go through smtp_respond() - for a start, messages from acl_not_smtp
do not do so, nor do messages concerned with batched SMTP. (c) Because the
interaction between ACLs and smtp_respond() isn't clear, I suspect (but have no
hard evidence) that something is sure to break. (I note that you also had
doubts.)

I would rather arrange that fake_response_text was split up at the end of
acl_check(), in the same way that user_message is now. An obvious approach is
to to put the current inline text into a subroutine that is called for both
variables. That fixes the bug without disturbing anything else.

I don't particularly like the idea of breaking lines at separators. The
no_multiline thing is for *really* broken clients; I don't think they should be
sent long lines.

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[Bug 455] fakereject behaves differently than deny message [ In reply to ]
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=455





------- Comment #6 from holmgren@lysator.liu.se 2007-02-05 16:04 -------
Regarding (a): It's true that it changes the semantics of smtp_respond(), but
I thought that smtp_respond() is the right level to do the wrapping on. *If*
the wrapping is something necessitated by the SMTP protocol, that is.
Considering that RFC 2821 allows 512-character lines, wrapping at around 80
characters doesn't seem really necessary. But in that case there shouldn't be
any automatic wrapping at all; the admin should make sure that any customized
messages have line breaks where he wants them. The same goes for (b): if the
wrapping is SMTP specific, then of course messages from acl_not_smtp or
batched SMTP are of no concern (and those messages would better be wrapped to
$COLUMNS).

But if the wrapping is where it is because it is generally a good idea to keep
individual lines of text shorter than 80 characters, independently of the
protocol, then it is wrong to put the wrapping in smtp_respond().

Which of my remarks did you construe as doubts regarding the interaction
between ACLs and smtp_respond()?

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: [Bug 455] fakereject behaves differently than deny message [ In reply to ]
On Mon, 5 Feb 2007, holmgren@lysator.liu.se wrote:

> Considering that RFC 2821 allows 512-character lines, wrapping at around 80
> characters doesn't seem really necessary.

Exactly. It is done for human readability. After all, that's the whole
idea of these messages - though we all know users don't actually read
them. :-)

> But in that case there shouldn't be any automatic wrapping at all; the
> admin should make sure that any customized messages have line breaks
> where he wants them.

They aren't all completely admin-specified messages: some may contain
inserted Exim error texts, etc. This wrapping was introduced by request,
IIRC.

> But if the wrapping is where it is because it is generally a good idea to keep
> individual lines of text shorter than 80 characters, independently of the
> protocol, then it is wrong to put the wrapping in smtp_respond().

Quite.

> Which of my remarks did you construe as doubts regarding the interaction
> between ACLs and smtp_respond()?

The one about not being sure of catching all cases.


--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[Bug 455] fakereject behaves differently than deny message [ In reply to ]
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=455





------- Comment #7 from ph10@hermes.cam.ac.uk 2007-02-05 16:58 -------
On Mon, 5 Feb 2007, holmgren@lysator.liu.se wrote:

> Considering that RFC 2821 allows 512-character lines, wrapping at around 80
> characters doesn't seem really necessary.

Exactly. It is done for human readability. After all, that's the whole
idea of these messages - though we all know users don't actually read
them. :-)

> But in that case there shouldn't be any automatic wrapping at all; the
> admin should make sure that any customized messages have line breaks
> where he wants them.

They aren't all completely admin-specified messages: some may contain
inserted Exim error texts, etc. This wrapping was introduced by request,
IIRC.

> But if the wrapping is where it is because it is generally a good idea to keep
> individual lines of text shorter than 80 characters, independently of the
> protocol, then it is wrong to put the wrapping in smtp_respond().

Quite.

> Which of my remarks did you construe as doubts regarding the interaction
> between ACLs and smtp_respond()?

The one about not being sure of catching all cases.

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[Bug 455] fakereject behaves differently than deny message [ In reply to ]
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=455





------- Comment #8 from holmgren@lysator.liu.se 2007-02-05 19:09 -------
I'm in favour of modularity, so I agree that the wrapping should be done in a
separate function. But it can still be argued whether that function should be
called near where the strings needing wrapping are constructed, or where they
are presented to the user. We obviously need more than one call in any case.

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[Bug 455] fakereject behaves differently than deny message [ In reply to ]
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

http://www.exim.org/bugzilla/show_bug.cgi?id=455


ph10@hermes.cam.ac.uk changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED




------- Comment #9 from ph10@hermes.cam.ac.uk 2007-02-07 11:26 -------
I have committed a patch that splits up the fakedefer and fakereject responses
in the same way that other "message" texts in ACLs are split.

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##