headers
Jasen Betts | 2 Jan 2012 23:07
Favicon

[Bug 1193] New: description of valid "bool" operator input excludes empty string

------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1193
           Summary: description of valid "bool" operator input excludes
                    empty string
           Product: Exim
           Version: N/A
          Platform: Other
               URL: http://www.exim.org/exim-html-
                    current/doc/html/spec_html/ch11.html#SECTexpcond
        OS/Version: Linux
            Status: NEW
          Keywords: work:tiny
          Severity: bug
          Priority: low
         Component: Documentation
        AssignedTo: nigel <at> exim.org
        ReportedBy: jasen <at> treshna.com
                CC: exim-dev <at> exim.org

In the description of the bool condition operator it does not mention that the
empty string is treated as false, it lists a few values and states that all
other strings are considered errors, I interpreted that as meaning that the
empty string was an error, however exim sensibly treats it as false.

eg:
$ exim -be '${if bool{}{True}{False}}'
False
(Continue reading)

Permalink | Reply | 2 comments |
headers
Phil Pennock | 3 Jan 2012 08:44
Favicon
Gravatar

[Bug 1193] description of valid "bool" operator input excludes empty string

------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1193

Phil Pennock <pdp <at> exim.org> changed:

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

--- Comment #1 from Phil Pennock <pdp <at> exim.org>  2012-01-03 07:44:08 ---
Oops, thanks, good catch.

Fixed in commit 8ebb1c9ea93eb27500756a578640d890b53264d3.

--

-- 
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email
Permalink | Reply | 0 comments |
headers
Git Commit | 3 Jan 2012 09:17
Favicon

[Bug 1193] description of valid "bool" operator input excludes empty string

------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1193

Git Commit <git <at> exim.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |git <at> exim.org

--- Comment #2 from Git Commit <git <at> exim.org>  2012-01-03 08:17:05 ---
Git commit:
http://git.exim.org/exim.git/commitdiff/8ebb1c9ea93eb27500756a578640d890b53264d3

commit 8ebb1c9ea93eb27500756a578640d890b53264d3
Author:     Phil Pennock <pdp <at> exim.org>
AuthorDate: Tue Jan 3 02:41:57 2012 -0500
Commit:     Phil Pennock <pdp <at> exim.org>
CommitDate: Tue Jan 3 02:41:57 2012 -0500

    bool{} is false for empty strings

    fixes bug 1193
    reported by Jasen Betts.
---
 doc/doc-docbook/spec.xfpt |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/doc/doc-docbook/spec.xfpt b/doc/doc-docbook/spec.xfpt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jorge | 3 Jan 2012 10:27
Picon

[Bug 1160] [PATCH] New feature: remove ASCII NUL from message data

------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1160

Jorge <jnerin <at> gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #502 is|0                           |1
           obsolete|                            |

--- Comment #1 from Jorge <jnerin <at> gmail.com>  2012-01-03 09:27:49 ---
Created an attachment (id=528)
 --> (http://bugs.exim.org/attachment.cgi?id=528)
Updated strip-nul patch for exim-4.77

Updated patch for exim-4.77, exim compiles cleanly and works ok with this
patch, no problems so far.

The patch creates a new option "strip_nul_char" that can be set in exim.conf to
activate the new feature. If the feature is not active the codepath is exaclty
the same as before, there is only three "if (strip_nul_char) continue;" made in
three places in src/receive.c (2 in read_message_data, 1 in
read_message_data_smtp).

Greetings.

--

-- 
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Arlott | 4 Jan 2012 20:44

[Bug 1195] New: read_message_data_smtp should comply with RFC5321

------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1195
           Summary: read_message_data_smtp should comply with RFC5321
           Product: Exim
           Version: 4.77
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: bug
          Priority: medium
         Component: Mail Receipt
        AssignedTo: nigel <at> exim.org
        ReportedBy: bugzilla.exim.simon <at> arlott.org
                CC: exim-dev <at> exim.org

2.3.8.  Lines

   Lines consist of zero or more data characters terminated by the
   sequence ASCII character "CR" (hex value 0D) followed immediately by
   ASCII character "LF" (hex value 0A).  This termination sequence is
   denoted as <CRLF> in this document.  Conforming implementations MUST
   NOT recognize or generate any other character or character sequence
   as a line terminator.  Limits MAY be imposed on line lengths by
   servers (see Section 4).

In src/src/receive.c:
 FUDGE: It seems that sites on the net send out messages with just LF
 terminators, despite the warnings in the RFCs, and other MTAs handle this. So
(Continue reading)

Permalink | Reply | 1 comment |
headers
Todd Lyons | 4 Jan 2012 21:14
Gravatar

Unintended consequence of accepting LF . LF

A user came on IRC today with a weird error.  He was receiving an
email from hotmail with a jpeg attached, but it was bombing midstream
and exim was complaining about SMTP errors in the conversation.  He
posted a packet dump that I looked at with wireshark.

In packet 4172, exim replied "250 OK id=blah".  So I looked before
that to see if there was a CR LF . CR LF sequence, but didn't find
one.  On a whim, I searched for LF . LF and found it:    In packet
4100 was the sequence 0a 2e 0a, i.e. just line feeds, no carriage
returns.

Confused, I looked through the code in read_message_data_smtp() and
found these comments:

<snip>
If any line begins with a dot, that character is skipped. The input should only
be successfully terminated by CR LF . CR LF unless it is local (non-network)
SMTP, in which case the CRs are optional, but...

FUDGE: It seems that sites on the net send out messages with just LF
terminators, despite the warnings in the RFCs, and other MTAs handle this. So
we make the CRs optional in all cases.
</snip>

So the sequence 0a 2e 0a does in fact get treated by exim as an end of
the DATA phase.  Maybe we need an option to say that the CR is not
optional?  The old drop_cr option is opposite of what seems to be
needed (in this particular case).  What's maybe needed is the ability
to say CR LF . CR LF is required for +hostlist.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phil Pennock | 5 Jan 2012 02:14
Favicon
Gravatar

[Bug 1195] read_message_data_smtp should comply with RFC5321

------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1195

--- Comment #1 from Phil Pennock <pdp <at> exim.org>  2012-01-05 01:14:43 ---
Hrm, I thought Exim only accepted LF as equivalent if this was seen in the
first header lines, looks like I'm remembering the pre-2003 behaviour.

I suspect that the most interoperable approach is going to be to check up until
we reach the second non-header line; if only CRLF has been observed until this
point, then require CRLF going forward.  If a mix has been observed, any
problems are generated entirely by the sending MTA/MUA and its their fault if
they didn't check an attachment for compatibility with the broken way they're
sending mail.

I say second non-header line, in case something is correctly composing the
headers and then doing something different for the body; with libraries for
generating email, this is very possible.

It *might* be worth having an ACL control option to affect this, such as
strict_crlf_lines.

Thoughts, folks?

--

-- 
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email
Permalink | Reply | 0 comments |
headers
Axel Rau | 6 Jan 2012 22:39
Picon

quote_pgsql and PostgreSQL 9.1.2

After upgrading to pgsql 9.1.2 from 8.4, I'm getting:
	test\_underscore
from
	'${quote_pgsql:${lc:$sender_address_local_part}}'
where sender_address_local_part is
	test_underscore
Quote from
	9.21 More about MySQL, PostgreSQL, Oracle, and InterBase:
"The quote_pgsql expansion operator, in addition, escapes the percent and underscore characters."
Why do we take percent and underscore special?
Is this a bug?

Axel
---
PGP-Key:29E99DD6  ☀ +49 151 2300 9283  ☀ computing  <at>  chaos claudius

--

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at
http://www.exim.org/ ##
Permalink | Reply | 2 comments |
headers
Axel Rau | 6 Jan 2012 23:53
Picon

Re: quote_pgsql and PostgreSQL 9.1.2


Am 06.01.2012 um 22:56 schrieb Adam D. Barratt:

> On Fri, 2012-01-06 at 22:39 +0100, Axel Rau wrote:
>> "The quote_pgsql expansion operator, in addition, escapes the percent
>> and underscore characters."
>> Why do we take percent and underscore special?
> 
> They're SQL wildcard characters - see
> http://www.w3schools.com/sql/sql_wildcards.asp for instance.
Only in a LIKE or ILIKE clause.
> 
>> Is this a bug?
> 
> No, it's a necessary feature.
Quote continuing: "This cannot be done
for MySQL because these escapes are not recognized in contexts where these
characters are not special."
Seems to me, pgsql behaviour has changed with 9.x into same direction.

Axel
---
PGP-Key:29E99DD6  ☀ +49 151 2300 9283  ☀ computing  <at>  chaos claudius

--

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at
http://www.exim.org/ ##
Permalink | Reply | 0 comments |
headers
Adam D. Barratt | 6 Jan 2012 22:56
Picon

Re: quote_pgsql and PostgreSQL 9.1.2

On Fri, 2012-01-06 at 22:39 +0100, Axel Rau wrote:
> "The quote_pgsql expansion operator, in addition, escapes the percent
> and underscore characters."
> Why do we take percent and underscore special?

They're SQL wildcard characters - see
http://www.w3schools.com/sql/sql_wildcards.asp for instance.

> Is this a bug?

No, it's a necessary feature.

Regards,

Adam
Permalink | Reply | 1 comment |

Gmane