headers
Phil Pennock | 1 Oct 2010 04:15

Re: [Bug 1026] New: dnslists doesn't allow underscores

On 2010-09-30 at 12:31 +0200, Sven Hartge wrote:
> They are just not allowed in hostnames. Have a look at

Actually, they are allowed in hostnames, but not if you're intending to
use them in an http: URL (and some other URL schemes), or to send mail
from that host.

RFC 1035 provides a guideline for reducing interoperability problems,
but that's not a mandate.  The guideline is one it is wise to follow,
especially if you ever want to send mail from that host to a system not
under your control, or if you want to run a web-server on it, but that
does not mean "not allowed".

The only current constraints I know of are in RFC 2396, where http is a
Server-based Naming Authority and so underscores are disallowed in the
URI grammar, and in RFC 5321, where the EHLO/HELO command needs to give
a hostname but constrains it to the Domain grammar rule (*sigh*).

-Phil

--

-- 
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at
http://www.exim.org/ ##
Permalink | Reply | 0 comments |
headers
Phil Pennock | 14 Oct 2010 01:47
Favicon
Gravatar

[Bug 1030] New: Header count limits enforcement

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

http://bugs.exim.org/show_bug.cgi?id=1030
           Summary: Header count limits enforcement
           Product: Exim
           Version: N/A
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: wishlist
          Priority: medium
         Component: ACLs
        AssignedTo: pdp <at> exim.org
        ReportedBy: pdp <at> exim.org
                CC: exim-dev <at> exim.org

Per Todd Lyons' mail "RFC 5532 enforcement", we should enforce maximum header
counts.

The actual RFC is 5322, "Internet Message Format". §3.6, "Field Definitions",
contains a table showing min and max counts for various headers.

Exim should have knowledge of this table's contents and be able to react
accordingly.  Admins should not have to manually construct rules for RFC
compliance.

Perhaps a global option for enforcement.  Perhaps ability to turn on or off
enforcement in the ACL.  Should Exim be able to accept such mails and clean
them up, when acting in Submission mode, by applying policies (keep-highest,
(Continue reading)

Permalink | Reply | 3 comments |
headers
Todd Lyons | 14 Oct 2010 19:28
Gravatar

[Bug 1030] Header count limits enforcement

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

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

Todd Lyons <tlyons <at> ivenue.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tlyons <at> ivenue.com

--- Comment #1 from Todd Lyons <tlyons <at> ivenue.com>  2010-10-14 18:28:50 ---
In my mind, "broken_headers" means more than one header when the spec
mandates only one, however it's likely that a better label could be
created.  I'm just not that creative.  In all of the comments below,
I'm not requesting that these names or labels be used, but rather am
trying to indicate how I would expect to see the knobs I would turn
and what the desired behavior is.

1. Global options for reject_broken_headers
  yes
  no
  quarantine (debugging)
With this global option, the stage is set for being really strict,
doing nothing, or saving a copy for debugging purposes.  I would
really only expect the quarantine to be useful for developers, not
used in a production system.

2. ACL support for reception/relaying
  control = broken_headers/fix_use_first
(Continue reading)

Permalink | Reply | 0 comments |
headers
Axel Rau | 14 Oct 2010 15:03
Picon

[Bug 1031] New: Implement database logging of completed remote delivery

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

http://bugs.exim.org/show_bug.cgi?id=1031
           Summary: Implement database logging of completed remote delivery
           Product: Exim
           Version: 4.72
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: wishlist
          Priority: medium
         Component: Logging
        AssignedTo: nigel <at> exim.org
        ReportedBy: axel.rau <at> chaos1.de
                CC: exim-dev <at> exim.org

Created an attachment (id=408)
 --> (http://bugs.exim.org/attachment.cgi?id=408)
diff against git HEAD

Applications like reputation systems require close integration of exim with a
database. All the infos exim is gathering during reciption are recorded in the
database. This is done using the lookup query facility of exim, which also can
insert/update data in the db.
Information about outgoing traffic is vital for reputation systems.
Unfortunately exim currently has no hook to set up a query at time of completed
delivery.

This enhancement request proposes a small addition to the exim code base,
(Continue reading)

Permalink | Reply | 35 comments |
headers
Todd Lyons | 15 Oct 2010 17:41
Gravatar

[Bug 1031] Implement database logging of completed remote delivery

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

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

--- Comment #1 from Todd Lyons <tlyons <at> ivenue.com>  2010-10-15 16:41:45 ---
On Thu, Oct 14, 2010 at 6:03 AM, Axel Rau <axel.rau <at> chaos1.de> wrote:
> This enhancement request proposes a small addition to the exim code base,
> including one new global option and 4 global variables. The option allows to
> define a query with several variables to be expanded/executed at delivery
> completion time. The 4 variables allow access to delivery details and are used
> in the query.

In the example in the patch, you put a SELECT statement, but it seems
like it would be better illustrated by showing a sample INSERT
instead:

+An example might look like:
+
+dbl_delivery_query = \
+${lookup pgsql {SELECT * FROM record_Delivery( \
+    '${quote_pgsql:$sender_address_domain}',\
<snip>

Because that record doesn't exist yet, right?

For feedback to you personally, I parse logs with a custom script
every two minutes and insert that extracted data into a database, so
this is a much welcome patch for me!  Real time info available for
message log searching, that's invaluable!
(Continue reading)

Permalink | Reply | 0 comments |
headers
Todd Lyons | 15 Oct 2010 17:41
Gravatar

Re: [Bug 1031] New: Implement database logging of completed remote delivery

On Thu, Oct 14, 2010 at 6:03 AM, Axel Rau <axel.rau <at> chaos1.de> wrote:
> This enhancement request proposes a small addition to the exim code base,
> including one new global option and 4 global variables. The option allows to
> define a query with several variables to be expanded/executed at delivery
> completion time. The 4 variables allow access to delivery details and are used
> in the query.

In the example in the patch, you put a SELECT statement, but it seems
like it would be better illustrated by showing a sample INSERT
instead:

+An example might look like:
+
+dbl_delivery_query = \
+${lookup pgsql {SELECT * FROM record_Delivery( \
+    '${quote_pgsql:$sender_address_domain}',\
<snip>

Because that record doesn't exist yet, right?

For feedback to you personally, I parse logs with a custom script
every two minutes and insert that extracted data into a database, so
this is a much welcome patch for me!  Real time info available for
message log searching, that's invaluable!

--

-- 
Regards...      Todd
I seek the truth...it is only persistence in self-delusion and
ignorance that does harm.  -- Marcus Aurealius
(Continue reading)

Permalink | Reply | 1 comment |
headers
Axel Rau | 15 Oct 2010 20:04
Picon

Re: [Bug 1031] New: Implement database logging of completed remote delivery


Am 15.10.2010 um 17:41 schrieb Todd Lyons:

> In the example in the patch, you put a SELECT statement, but it seems
> like it would be better illustrated by showing a sample INSERT
> instead:
>
> +An example might look like:
> +
> +dbl_delivery_query = \
> +${lookup pgsql {SELECT * FROM record_Delivery( \
> +    '${quote_pgsql:$sender_address_domain}',\
> <snip>
>
> Because that record doesn't exist yet, right?
My example uses a stored procedure. A real world example with a  
normalized
schema would be quite complex, because a couple of tables would be  
queried/
updated/inserted.
A simple INSERT might look like:
-----------
dbl_delivery_query = \
${lookup pgsql {INSERT INTO record_Delivery( \
      sa_d, sa_lp, ra_d, ra_lp, rel_ip, rel_fqdn, msg_id) \
      VALUES ('${quote_pgsql:$sender_address_domain}',\
     '${quote_pgsql:${lc:$sender_address_local_part}}', \
     '${quote_pgsql:$dbl_delivery_domain}', \
     '${quote_pgsql:${lc:$dbl_delivery_local_part}}', \
     '${quote_pgsql:$dbl_delivery_ip}', \
(Continue reading)

Permalink | Reply | 0 comments |
headers
Axel Rau | 15 Oct 2010 20:04
Picon

[Bug 1031] Implement database logging of completed remote delivery

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

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

--- Comment #2 from Axel Rau <axel.rau <at> chaos1.de>  2010-10-15 19:04:40 ---
Am 15.10.2010 um 17:41 schrieb Todd Lyons:

> In the example in the patch, you put a SELECT statement, but it seems
> like it would be better illustrated by showing a sample INSERT
> instead:
>
> +An example might look like:
> +
> +dbl_delivery_query = \
> +${lookup pgsql {SELECT * FROM record_Delivery( \
> +    '${quote_pgsql:$sender_address_domain}',\
> <snip>
>
> Because that record doesn't exist yet, right?
My example uses a stored procedure. A real world example with a  
normalized
schema would be quite complex, because a couple of tables would be  
queried/
updated/inserted.
A simple INSERT might look like:
-----------
dbl_delivery_query = \
${lookup pgsql {INSERT INTO record_Delivery( \
      sa_d, sa_lp, ra_d, ra_lp, rel_ip, rel_fqdn, msg_id) \
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Cardwell | 20 Oct 2010 01:52

${index}

http://github.com/mikecardwell/Exim/commit/b4ef92d69ac58a46cbb0babb93d688267fbed443

Provides a ${index{string}{substring}} function to return the location
of a string within a string. Examples:

mike <at> snail:~/git/exim.build/src$ ./build-Linux-x86_64/exim -be
'${index{foobar}{oo}}'
1
mike <at> snail:~/git/exim.build/src$ ./build-Linux-x86_64/exim -be
'${index{foobar}{f}}'
0
mike <at> snail:~/git/exim.build/src$ ./build-Linux-x86_64/exim -be
'${index{foobar}{bar}}'
3
mike <at> snail:~/git/exim.build/src$ ./build-Linux-x86_64/exim -be
'${index{foobar}{woo}}'
-1
mike <at> snail:~/git/exim.build/src$ ./build-Linux-x86_64/exim -be
'${index{foobar}{}}'
-1
mike <at> snail:~/git/exim.build/src$

Use case: Check if the sender address is in the subject line:

condition = ${if >{${index{$h_Subject:}{$sender_address}}}{-1}}

You could use ${match} but then you'd have to worry about special regex
characters in the key such as '.'.

Comments?
(Continue reading)

Permalink | Reply | 3 comments |
headers
Phil Pennock | 20 Oct 2010 03:48

Re: ${index}

On 2010-10-20 at 00:52 +0100, Mike Cardwell wrote:
> http://github.com/mikecardwell/Exim/commit/b4ef92d69ac58a46cbb0babb93d688267fbed443
> 
> Provides a ${index{string}{substring}} function to return the location
> of a string within a string. Examples:

Generally like it.  My main commentary is at the bikeshed-painting
level, so I'll throw it out there, but am not going to protest if you
ignore me.

Note that Exim doesn't really do much sequential work with variables
holding results, although it can of course be so abused, so I'm curious
about the desire to use an expansion operator instead of an expansion
condition for the basic check.  What's the use-case?

At a code-review level: multiple case statements inside a switch which
fall through should usually have a comment stating that this is explicit
and intentional.  Looking for prior art in expand.c, I see both /* Fall
through */ and, as counter-example, ECOND_ISIP/ECOND_ISIP4/ECOND_ISIP6.
I'd argue that it's clear that the ECOND_ISIP* cases are being handled
in common, whereas in this case, I had to go check the documentation for
read_subs() to see the return values, to confirm that the 2 and 3 values
could reasonably be treated the same and this was not accidental code
omission.

Is %d cross-platform safe formatting for a ptrdiff_t type?  I'd be
"impressed" if an Exim string ever holds enough data to have to worry
about wrap-around or overflow of 32-bit here, but it might be safest to
use %ld and a (long int) cast.  FreeBSD uses 64-bit signed ptrdiff_t and
that's a 'long'.  My vague recollection is that this is normal for
(Continue reading)

Permalink | Reply | 2 comments |

Gmane