<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.mail.exim.devel">
    <title>gmane.mail.exim.devel</title>
    <link>http://permalink.gmane.org/gmane.mail.exim.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.exim.devel/6256"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.exim.devel/6255"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.exim.devel/6254"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.exim.devel/6253"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.exim.devel/6252"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.exim.devel/6251"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.exim.devel/6250"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.exim.devel/6249"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.exim.devel/6248"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.exim.devel/6247"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.exim.devel/6246"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.exim.devel/6245"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.exim.devel/6244"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.exim.devel/6243"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.exim.devel/6242"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.exim.devel/6241"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.exim.devel/6240"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.exim.devel/6239"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.exim.devel/6238"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.exim.devel/6237"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.exim.devel/6256">
    <title>Re: logging of fakereject</title>
    <link>http://permalink.gmane.org/gmane.mail.exim.devel/6256</link>
    <description>&lt;pre&gt;
I don't know if it's a normal thing or not, but none of my servers
deliver fake rejected emails to the same place as normal ones; they
always run through their own router/transport which makes them quite
obvious.

You can also use logwrite or similar to write your own line to the log
file which will have the same message id.

Changing the logfile format is always an issue. It's like changing a
well known and stable API. It certainly shouldn't break something as
fundamental as "&amp;lt;=".



&lt;/pre&gt;</description>
    <dc:creator>Ted Cooper</dc:creator>
    <dc:date>2013-05-13T13:44:09</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.exim.devel/6255">
    <title>Re: logging of fakereject</title>
    <link>http://permalink.gmane.org/gmane.mail.exim.devel/6255</link>
    <description>&lt;pre&gt;
Well, we could do something like " &amp;lt;=F " rather than " &amp;lt;= ",
perhaps, if enought people care.  Or add a doc note.
&lt;/pre&gt;</description>
    <dc:creator>Jeremy Harris</dc:creator>
    <dc:date>2013-05-13T12:22:04</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.exim.devel/6254">
    <title>Re: logging of fakereject</title>
    <link>http://permalink.gmane.org/gmane.mail.exim.devel/6254</link>
    <description>&lt;pre&gt;
Coincidentally I'm using fakereject to drip-feed sa-learn with messages
we have classified as spam in other ways.

The message is logged in its entirety, from "&amp;lt;=" to "Completed".

I've put in a separate logwrite line to log it to the reject log:

   accept condition   = ${if eq{$acl__c_test}{true}}
          logwrite    = :main,reject: Message rejected (but fed to
sa-learn): LBORO-DENY-LOCAL - Local Listing &amp;lt;other stuff snipped&amp;gt;
          control     = fakereject/Your message has been rejected due to
the sending host ($sender_host_address) having the following local
listings: &amp;lt;other stuff snipped&amp;gt;
          control     = queue_only

But aside from the logwrite line, the message logging is perfectly
normal.

I'm not 100% sure what you could do to change that, really...

Graeme


&lt;/pre&gt;</description>
    <dc:creator>Graeme Fowler</dc:creator>
    <dc:date>2013-05-13T08:21:09</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.exim.devel/6253">
    <title>[Bug 425] Put captured subexpressions of regex and mime_regex ACL conditions in $1, $2 etc.</title>
    <link>http://permalink.gmane.org/gmane.mail.exim.devel/6253</link>
    <description>&lt;pre&gt;------- You are receiving this mail because: -------
You are the QA contact for the bug.

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

Jeremy Harris &amp;lt;jgh146exb&amp;lt; at &amp;gt;wizmail.org&amp;gt; changed:

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




--- Comment #3 from Jeremy Harris &amp;lt;jgh146exb&amp;lt; at &amp;gt;wizmail.org&amp;gt;  2013-05-12 18:40:40 ---
Created an attachment (id=626)
 --&amp;gt; (http://bugs.exim.org/attachment.cgi?id=626)
Mk. 2: supports mime_regex also.

I've noted an issue:  this may be regarded as an incompatible change as it
modifies variables which were previously untouched.


&lt;/pre&gt;</description>
    <dc:creator>Jeremy Harris</dc:creator>
    <dc:date>2013-05-12T17:40:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.exim.devel/6252">
    <title>logging of fakereject</title>
    <link>http://permalink.gmane.org/gmane.mail.exim.devel/6252</link>
    <description>&lt;pre&gt;Am I right that a fakereject still gets a "&amp;lt;=" line logged?
Should we make it distinguishable in some way?
&lt;/pre&gt;</description>
    <dc:creator>Jeremy Harris</dc:creator>
    <dc:date>2013-05-12T15:02:33</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.exim.devel/6251">
    <title>Re: Embedding Python</title>
    <link>http://permalink.gmane.org/gmane.mail.exim.devel/6251</link>
    <description>&lt;pre&gt;
I've been experimenting with this.  So far I cannot get path
manipulation to work using the list methods.  I can only get it to
work using string methods.

Doing this works:

char *path, *newpath;
path = Py_GetPath();
newpath = (char *)string_sprintf("%s:%s", syspath,"/etc/exim");
PySys_SetPath(newpath);
/* Now check it */
path = Py_GetPath();

And using the list method (again, very simplified, no error checking
yet) does not:

char *path;
PyObject *syspath, *pName;
syspath = PySys_GetObject("path");
pName = PyString_FromString("/etc/exim");
PyList_Insert(syspath, 0, pName);
PySys_SetObject("path", syspath);
/* Now check it */
path = Py_GetPath();

When I print out the path string, the "/etc/exim" is not in it.


It will depend upon if Py_Initialize() does the site loading (which in
my googling seems to imply that it does).  To answer a second part of
your question, my plan was to take the python_startup setting (for
example "/etc/exim/exim_python.py"), split the path and filename, then
load the module "exi&lt;/pre&gt;</description>
    <dc:creator>Todd Lyons</dc:creator>
    <dc:date>2013-05-09T13:52:21</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.exim.devel/6250">
    <title>[Bug 1353] New: Automated checks for unsorted optionlists</title>
    <link>http://permalink.gmane.org/gmane.mail.exim.devel/6250</link>
    <description>&lt;pre&gt;------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1353
           Summary: Automated checks for unsorted option lists
           Product: Exim
           Version: N/A
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: bug
          Priority: medium
         Component: Release process
        AssignedTo: nigel&amp;lt; at &amp;gt;exim.org
        ReportedBy: nigel&amp;lt; at &amp;gt;exim.org
                CC: exim-dev&amp;lt; at &amp;gt;exim.org


Exim option lists (in the exim C code) must be in a lexicographically sorted
order.
If they are not sorted bad things can happen - see bug #1352

We need some automated checking to check all of the sets of option lists, and
alert should an option be inserted in a position that makes the option list
unsorted.


&lt;/pre&gt;</description>
    <dc:creator>Nigel Metheringham</dc:creator>
    <dc:date>2013-05-08T12:58:35</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.exim.devel/6249">
    <title>[Bug 1352] Exim configuration error: main option"dns_retry" unknown</title>
    <link>http://permalink.gmane.org/gmane.mail.exim.devel/6249</link>
    <description>&lt;pre&gt;------- You are receiving this mail because: -------
You are on the CC list for the bug.

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

Todd Lyons &amp;lt;tlyons&amp;lt; at &amp;gt;ivenue.com&amp;gt; changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tlyons&amp;lt; at &amp;gt;ivenue.com
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #2 from Todd Lyons &amp;lt;tlyons&amp;lt; at &amp;gt;ivenue.com&amp;gt;  2013-05-08 13:49:48 ---
Fix commited and pushed.


&lt;/pre&gt;</description>
    <dc:creator>Todd Lyons</dc:creator>
    <dc:date>2013-05-08T12:49:49</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.exim.devel/6248">
    <title>[Bug 1352] Exim configuration error: main option"dns_retry" unknown</title>
    <link>http://permalink.gmane.org/gmane.mail.exim.devel/6248</link>
    <description>&lt;pre&gt;------- You are receiving this mail because: -------
You are on the CC list for the bug.

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




--- Comment #1 from Todd Lyons &amp;lt;tlyons&amp;lt; at &amp;gt;ivenue.com&amp;gt;  2013-05-08 13:48:40 ---
On Wed, May 8, 2013 at 3:01 AM, Dmitry Isaikin &amp;lt;isaikin-dmitry&amp;lt; at &amp;gt;yandex.ru&amp;gt;
wrote:


&lt;/pre&gt;</description>
    <dc:creator>Todd Lyons</dc:creator>
    <dc:date>2013-05-08T12:48:43</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.exim.devel/6247">
    <title>Re: [Bug 1352] New: Exim configuration error: main option "dns_retry" unknown</title>
    <link>http://permalink.gmane.org/gmane.mail.exim.devel/6247</link>
    <description>&lt;pre&gt;


&lt;/pre&gt;</description>
    <dc:creator>Todd Lyons</dc:creator>
    <dc:date>2013-05-08T12:48:16</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.exim.devel/6246">
    <title>[Bug 1352] New: Exim configuration error: main option "dns_retry" unknown</title>
    <link>http://permalink.gmane.org/gmane.mail.exim.devel/6246</link>
    <description>&lt;pre&gt;------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1352
           Summary: Exim configuration error: main option "dns_retry"
                    unknown
           Product: Exim
           Version: N/A
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: bug
          Priority: medium
         Component: General execution
        AssignedTo: nigel&amp;lt; at &amp;gt;exim.org
        ReportedBy: isaikin-dmitry&amp;lt; at &amp;gt;yandex.ru
                CC: exim-dev&amp;lt; at &amp;gt;exim.org


We use option "dns_retry".
After rebuilding Exim from master branch, Exim makes core:

/etc/init.d/exim restart
Shutting down exim:                                        [  OK  ]
Starting exim: 2013-05-08 13:27:32 Exim configuration error in line 81 of
/usr/exim/conf/configure:
  main option "dns_retry" unknown

Fix:

diff --git a/src/src/readconf.c b/src/src/readconf.c
index d684b90..84577e5 100644
--- a/src/src/readconf.c
+++ b/src/src/readconf.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -2&lt;/pre&gt;</description>
    <dc:creator>Dmitry Isaikin</dc:creator>
    <dc:date>2013-05-08T10:01:52</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.exim.devel/6245">
    <title>Security considerations: use_shell</title>
    <link>http://permalink.gmane.org/gmane.mail.exim.devel/6245</link>
    <description>&lt;pre&gt;I've pushed commit 5336c0d adding a new section to the Security
Considerations chapter of The Exim Specification.

There's probably more we can add here.

Context:
 https://www.redteam-pentesting.de/de/advisories/rt-sa-2013-001/-exim-with-dovecot-typical-misconfiguration-leads-to-remote-command-execution

People keep using use_shell and our warnings are perhaps not strong
enough as they stand.  Adding them into the security considerations
chapter might provide for better review, with security teams talking to
postmasters to find workable balances in the use of features called out
as dangerous.

-Phil

&lt;/pre&gt;</description>
    <dc:creator>Phil Pennock</dc:creator>
    <dc:date>2013-05-06T01:35:28</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.exim.devel/6244">
    <title>Re: Opportunistic DANE TLS mode for SMTP</title>
    <link>http://permalink.gmane.org/gmane.mail.exim.devel/6244</link>
    <description>&lt;pre&gt;

One more thing I forgot to respond to from March, a DANE implementation
cannot be limited to just the "IN TLSA x 0 0" use case.  In practice
almost all DANE TLSA RRs will be of the "IN TLSA 3 1 1" variety, but
one needs to also be prepared for "IN TLSA 2 1 0" and "IN TLSA 2 1 1".

Even with "0 0 0" and "2 0 0", the certificate in the TLSA RR may
be an intermediate certificate and not a root!  Though in practice
almost nobody will publish such RRs since full certificates are
too bulky to store in DNS.

Yes, this means that implementating a DANE verifier is more complex
than just adding another root via a CAfile and asking the SSL
library to do PKI as usual.

One needs to support digest matches, and these may match at any
depth in the certificate chain.  One even needs to support "2 1 0"
and "0 1 0", by checking whether the top of the server chain is
signed by a given public key (without the corresponding certificate
in hand).

&lt;/pre&gt;</description>
    <dc:creator>Viktor Dukhovni</dc:creator>
    <dc:date>2013-05-03T13:48:01</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.exim.devel/6243">
    <title>Opportunistic DANE TLS mode for SMTP</title>
    <link>http://permalink.gmane.org/gmane.mail.exim.devel/6243</link>
    <description>&lt;pre&gt;
I see that DANE was actively discussed on this list in March, sorry
I was not here to participate.

I am writing a draft RFC for an "experimental" protocol that
implements "opportunistic DANE TLS".  This is designed to match
SMTP protocol reality whenever it is in conflict with strict
conformance with RFC 6698 or other potentially relevant IETF
documents.  I'd like to see major MTAs implement the opportunistic
DANE TLS protocol.  I'm also attempting to reach out to Sendmail
and Microsoft.

I am writing a separate draft on operational guidance for DANE TLSA
implementations that is not SMTP specific and covers some cornder
cases that need a bit more explanation than provided in RFC 6698.
With luck the second draft could be a basis for an update to 6698.

A couple of follow-ups to the March discussion:

    - It would be a mistake to use security status to trump MX
      preference.  Some sites have MX hosts that refuse all mail
      unless the secondary believe that the primary is down.

      Connecting to &lt;/pre&gt;</description>
    <dc:creator>Viktor Dukhovni</dc:creator>
    <dc:date>2013-05-02T17:37:57</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.exim.devel/6242">
    <title>Re: Embedding Python</title>
    <link>http://permalink.gmane.org/gmane.mail.exim.devel/6242</link>
    <description>&lt;pre&gt;

I had this same problem once, and did this workaround:

#define PYTHON_DIR "..."

static const char pypath[] =
"import sys\n"
"sys.path.append(\"" PYTHON_DIR "\")\n";

...

Py_Initialize();

m = PyImport_AddModule("__main__");
globals = PyModule_GetDict(m);

res = PyRun_String(pypath, Py_file_input, globals, globals);
if (!res) {
PyErr_Print();
return -1;
} else
Py_DECREF(res);

johannes


&lt;/pre&gt;</description>
    <dc:creator>Johannes Berg</dc:creator>
    <dc:date>2013-05-02T11:51:11</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.exim.devel/6241">
    <title>Re: Embedding Python</title>
    <link>http://permalink.gmane.org/gmane.mail.exim.devel/6241</link>
    <description>&lt;pre&gt;
Messing with environment seems bad, and affects the ability of sysadmin
to do so if needed.

Todd should just be able to use PyList_Insert() to modify sys.path,
after importing sys.  Note that this has to happen after the interpreter
is loaded, since Py_GetPath() is used to provide the default value.

The main things to figure out and document are:

 1. Does site initialisation get loaded?  If not, does another fixed
    module name get loaded instead, letting administrators symlink it to
    pull in any site customisations of sys.path done therein?  This is
    `site.py` inside the main python system modules directory, and it
    affects whether or not distutils-provided packages can be used, etc
    etc.

 2. Is threading initialised?  If not, threading calls will all succeed
    but the other threads will never actually be scheduled.  It's
    GIL-based, and OS-level threads are unaffected, since effectively
    it's just a single real thread, but given that Exim is traditionally
    single-threaded, eve&lt;/pre&gt;</description>
    <dc:creator>Phil Pennock</dc:creator>
    <dc:date>2013-05-02T20:36:59</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.exim.devel/6240">
    <title>Re: Embedding Python</title>
    <link>http://permalink.gmane.org/gmane.mail.exim.devel/6240</link>
    <description>&lt;pre&gt;
http://docs.python.org/2/install/index.html
says:
==========
There are two environment variables that can modify sys.path. PYTHONHOME 
sets an alternate value for the prefix of the Python installation. For 
example, if PYTHONHOME is set to /www/python, the search path will be 
set to ['', '/www/python/lib/pythonX.Y/', 
'/www/python/lib/pythonX.Y/plat-linux2', ...].

The PYTHONPATH variable can be set to a list of paths that will be added 
to the beginning of sys.path. For example, if PYTHONPATH is set to 
/www/python:/opt/py, the search path will begin with ['/www/python', 
'/opt/py']. (Note that directories must exist in order to be added to 
sys.path; the site module removes paths that don’t exist.)
==========

So presumably if the exim process modifies its own environment in that
way before starting Python, we get what we need?
&lt;/pre&gt;</description>
    <dc:creator>jgh&lt; at &gt;wizmail.org</dc:creator>
    <dc:date>2013-05-02T11:01:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.exim.devel/6239">
    <title>Re: Embedding Python</title>
    <link>http://permalink.gmane.org/gmane.mail.exim.devel/6239</link>
    <description>&lt;pre&gt;
Yeah, I'm familiar with that stance, and if you're starting from scratch
it makes a certain amount of sense, but being unable to accept existing
code and work with it, instead of fighting it, is unfortunate and not
pragmatic.


Yes.  I'd use it.  I wanted to find time to write the code myself, I'm
very glad you're doing so.


Manipulate the existing sys.path variable using the normal list
manipulation API?

-Phil

&lt;/pre&gt;</description>
    <dc:creator>Phil Pennock</dc:creator>
    <dc:date>2013-05-02T03:05:29</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.exim.devel/6238">
    <title>Embedding Python</title>
    <link>http://permalink.gmane.org/gmane.mail.exim.devel/6238</link>
    <description>&lt;pre&gt;I decided that I was going to add embedded python to exim in the same
manner than perl is embedded.  I did some plumbing for exim to be
configured for it, then build and link it.  I just finished that
portion and pushed up to my personal branch.  I have been working on
this since last week (started on it after I pushed the opendmarc
branch.)

Over the past couple of days, while ironing out the kinks in the build
process, I was hitting an issue getting the python code to import.  I
went and asked in the #python irc channel.  HOLY CRAP was that the
wrong thing to do.  I was told I was stupid for trying to embed python
into an existing app because I lose so much of the power of python.  I
was also told it would probably be just as stupid to embed perl into
my app.  I admit I kind of laughed at that.  They referred me to
http://twistedmatrix.com/users/glyph/rant/extendit.html which kindly
explains that I should reconfigure my app to be a module of python,
not to embed python in the app.

I think I'm just going t&lt;/pre&gt;</description>
    <dc:creator>Todd Lyons</dc:creator>
    <dc:date>2013-05-01T19:28:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.exim.devel/6237">
    <title>Administrivia: tahini downtime</title>
    <link>http://permalink.gmane.org/gmane.mail.exim.devel/6237</link>
    <description>&lt;pre&gt;It appears that tahini (www.exim.org, git.exim.org, etc) experienced
some downtime.  Still waiting for word on cause, etc.

Mailing both to inform and to prod to make sure the mailing-lists are
working.

-Phil

&lt;/pre&gt;</description>
    <dc:creator>Phil Pennock</dc:creator>
    <dc:date>2013-05-01T16:24:12</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.exim.devel/6236">
    <title>[Bug 311] Add headers at top and middle</title>
    <link>http://permalink.gmane.org/gmane.mail.exim.devel/6236</link>
    <description>&lt;pre&gt;------- You are receiving this mail because: -------
You are the QA contact for the bug.

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

Nigel Metheringham &amp;lt;nigel&amp;lt; at &amp;gt;exim.org&amp;gt; changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|Exim 4.72                   |Exim 4.73
   Target Milestone|Exim 4.73                   |Exim 4.77

Jeremy Harris &amp;lt;jgh146exb&amp;lt; at &amp;gt;wizmail.org&amp;gt; changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jgh146exb&amp;lt; at &amp;gt;wizmail.org




--- Comment #2 from Jeremy Harris &amp;lt;jgh146exb&amp;lt; at &amp;gt;wizmail.org&amp;gt;  2013-04-28 22:00:32 ---
Headers added in ACL can be at_start, after_received, at_start_rfc or at_end.
Does this satisfy the requirement?


&lt;/pre&gt;</description>
    <dc:creator>Jeremy Harris</dc:creator>
    <dc:date>2013-04-28T21:00:32</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.mail.exim.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.mail.exim.devel</link>
  </textinput>
</rdf:RDF>
