headers
Uwe Doering | 1 Feb 2011 23:03

[Bug 1019] DKIM multiple signature generation does not work (dkim_domain list)

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

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

--- Comment #12 from Uwe Doering <gemini <at> geminix.org>  2011-02-01 22:03:05 ---
Hi there,

On 2010-09-30 10:11, Michael Haardt wrote:
> --- Comment #11 from Michael Haardt<michael.haardt <at> freenet.ag>   2010-09-30 09:11:29 ---
>> Final set of multiple signature generation DKIM bug fixes for Exim 4.72
>
> The patch looks fine to me and works, too.  A mail signed with two
> different keys passes verification of both keys.  Nigel: Would you
> commit it?

Now that 4.74 has been released, may I politely point out that said 
patch still hasn't been committed.  The target milestone was 4.73, 
actually.  I would be glad if this could be resolved in time for 4.75.

Regards,

    Uwe

--

-- 
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email
Permalink | Reply | 0 comments |
headers
Marcin Mirosław | 3 Feb 2011 12:17
Picon

Logging address ip of outgoing mail

Hello!
I'd like to have in log addres IP used to send mail. Something like
outgoing_interface instead incoming_interface. Is it possible to do it
in straight way or i need to add log function to transport?
Thanks.

--

-- 
www: http://blog.mejor.pl/
Permalink | Reply | 2 comments |
headers
Todd Lyons | 3 Feb 2011 19:39
Gravatar

Milter api

I really like the power exim has in its macros and string handling,
but I have always felt like we exclude ourselves from some nice
software options because we don't support the milter interface.  For
instance, I am a beta tester for the opendkim project, and while I
like the built in DKIM support, I have a large system already setup on
the sendmail (older customer mail system) side with opendkim doing key
lookups from mysql.  It would be easier to manage if I could also use
this same opendkim software configured in the same way across the exim
side as well.  It simplifies my exim configuration some as well.

I spoke with a gentleman (Hilko) who had developed a local_scan based
milter interface as part of his thesis, this was back around 2006 when
exim 4.66 was current.  He also had started working on an integrated
version.  The local_scan version processed the whole message in one
chunk, whereas integrated support can be called at any point in the
ACL's that the sysadmin desires, depending on the function of the
milter(s).  It's wrapped with EXPERIMENTAL_MILTER macros, so it can be
turned off or on at build time as needed.

1. The first question is if there is any interest in this kind of
functionality.  Would a fully tested and documented patch be accepted
into exim core?
2. Undoubtedly it needs extensive testing especially WRT error
handling, I'm planning on doing a lot of that, and will also run it in
a test system and (if stable) in a production scenario for a while
before I ask Hilko to submit it.
3. Hilko is a damn good coder, and it's his (GPL v2) code, none of it
is mine.  I'm just serving in the capacity of finding bugs, maybe
fixing them if they're simple.
4. I've not tested anything yet, only merged it into my local copy of master.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Phil Pennock | 3 Feb 2011 20:45

Re: Milter api

On 2011-02-03 at 10:39 -0800, Todd Lyons wrote:
> 1. The first question is if there is any interest in this kind of
> functionality.  Would a fully tested and documented patch be accepted
> into exim core?

I am interested in seeing milter functionality, simply because it lets
Exim use the same tools as the other MTAs and play in a larger
ecosystem.

It was on my "to-do" list, sufficiently far down that I wouldn't have
gotten to it for far too long, so I'm glad to see someone else doing it.

> I've scanned the archives several times looking for conversation on a
> milter interface in exim.  I found nothing that indicates any
> inclination by the core devs either for or against such an interface.
> Any comments?

I believe that there was reluctance because the ACLs already provide
significantly more power than most milters offered at the time this was
being suggested before, several years ago.

Milters caught on, the world has changed.

-Phil
Permalink | Reply | 0 comments |
headers
Jeremy Harris | 4 Feb 2011 00:05

Re: Logging address ip of outgoing mail

On 2011-02-03 11:17, Marcin Mirosław wrote:
> Hello!
> I'd like to have in log addres IP used to send mail. Something like
> outgoing_interface instead incoming_interface. Is it possible to do it
> in straight way or i need to add log function to transport?

I'm not aware of a log_selector that does what you want.

What I've done to help logging in routing/transport is an
embedded-perl function Exim::log_write called as a dummy
lookup.  Typically I use this in a router as:

    data =      ${if eq {}{\
              ${perl{Exim::log_write}{router_name: bad  <$local_part <at> $domain>}}}\
                   {}{}}

I assume you're using an smtp transport with a lookup for
    interface =
and you could do something similar there.

-- 
Jeremy

--

-- 
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at
http://www.exim.org/ ##
Permalink | Reply | 1 comment |
headers
Jakob Hirsch | 4 Feb 2011 15:59
Picon
Gravatar

Re: Milter api

Todd Lyons, 2011-02-03 19:39:
> I really like the power exim has in its macros and string handling,
> but I have always felt like we exclude ourselves from some nice
> software options because we don't support the milter interface.  For

I always felt the same way and wondered, why nobody bothered to
implement or at least ask for it. Maybe because it's something from the
sendmail world and nobody wanted to get near that :)
I even wanted to do this myself, but never found the time for it (and
the need for it was not that big). I think that milter integration would
be really good for Exim, so I'm looking forward for that. It's the right
way and surely better than implementing every possible interface and
protocol ourselves.
Permalink | Reply | 0 comments |
headers
Andreas Metzler | 4 Feb 2011 19:37

Re: Milter api

On 2011-02-03 Todd Lyons <tlyons <at> ivenue.com> wrote:
> I really like the power exim has in its macros and string handling,
> but I have always felt like we exclude ourselves from some nice
> software options because we don't support the milter interface.
[...]

Hello,

Disclaimer: I really do not know much about non-exim MTAs and know
milter mainly from wikipedia.

One of the obvious counterarguments is that it complicates things.
With exim4 the basic setup was rather clean, you get one ACL for each
ESMTP verb, routers choose the destination, transports deliver. (The
verify ACL verb and verify_only routers muddy the water a little bit.
acl_smtp_dkim is the odd man.)

Milter being basically a replacement for the ACL system makes it a
strange addition, it seems to be a perfect fit for a stripped down MTA
but with exim it feels like combining a leatherman with a swiss army
knife. 

Afaiui milters get passed the message at eached ehlo verb, and can
not only return a status but also modify the contents. I think more or
less the only consistent way to integrate milters would be in adding a
milter verb to the ACL language. And here the fun starts: When is the
milter run? At the start of the ACL, bottom, do I suddenly need to add
a milter statement to every single one of the ACLs (even the ones I am
not currently using)?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Phil Pennock | 4 Feb 2011 20:06

Re: Milter api

On 2011-02-04 at 19:37 +0100, Andreas Metzler wrote:
> Afaiui milters get passed the message at eached ehlo verb, and can
> not only return a status but also modify the contents. I think more or
> less the only consistent way to integrate milters would be in adding a
> milter verb to the ACL language. And here the fun starts: When is the
> milter run? At the start of the ACL, bottom, do I suddenly need to add
> a milter statement to every single one of the ACLs (even the ones I am
> not currently using)?

My thought was a milter condition, taking the milter name, SMTP stage
and any arguments for the milter.

If the milter needs to be invoked at three stages, you add the milter at
those three stages.  If it's only needed in one, you only invoke it
there.

But these thoughts are based in part on a lack of experience with
milters, so might be asinine.

-Phil
Permalink | Reply | 0 comments |
headers
Todd Lyons | 4 Feb 2011 22:01
Gravatar

Re: Milter api

On Fri, Feb 4, 2011 at 10:37 AM, Andreas Metzler
<eximusers <at> downhill.at.eu.org> wrote:
> On 2011-02-03 Todd Lyons <tlyons <at> ivenue.com> wrote:
>> but I have always felt like we exclude ourselves from some nice
>> software options because we don't support the milter interface.
> Afaiui milters get passed the message at eached ehlo verb, and can
> not only return a status but also modify the contents. I think more or

There are callbacks defined for each stage of the smtp conversation, a
few of the obvious ones:
xxfi_connect: same as acl_smtp_connect
xxfi_envfrom: same as acl_smtp_mail
xxfi_envrcpt: same as acl_smtp_rcpt
xxfi_eom: same as acl_smtp_data

Some callbacks that don't match cleanly:
xxfi_eoh: essentially the same as acl_smtp_predata

Some callbacks that would have to be synthesized:
xxfi_header: called once for each header

Don't profess to fully understand:
xxfi_body: I can't tell yet if it's called at the beginning of the
body verb, or at the "\r\n.\r\n" sequence.

I do have some irc buddies who used to work at sendmail and maintain
their own milters who I can lean on for support in understanding these
things :-)

> the only consistent way to integrate milters would be in adding a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Todd Lyons | 5 Feb 2011 00:39
Gravatar

[Bug 139] Dynamically loadable lookup modules

------- You are receiving this mail because: -------
You are the QA contact for the bug.

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

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

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

--- Comment #44 from Todd Lyons <tlyons <at> ivenue.com>  2011-02-04 23:39:35 ---
(In reply to comment #26)
> (In reply to comment #19)
> > We should probably do with adding the list of loaded lookups to 'exim -bV'
> > output somehow. And it would be nice if we could avoid using RTLD_NOW. 
> The cosmetic path called in show_whats_supported() function to
> display list of loadable lookup modules possible.
> --- exim-4.70.lookup/src/exim.c 2009-11-06 13:18:19 +0100
<snip>

Verified that this patch still applies cleanly against exim 4.74 and produces
proper output.  Verified that it works properly when no *.so files are in the
lookups directory.

CentOS55[root <at> ivwm21 ~]# exim -bV
Exim version 4.74 #1 built 04-Feb-2011 23:23:09
Copyright (c) University of Cambridge, 1995 - 2007
Berkeley DB: Sleepycat Software: Berkeley DB 4.3.29: (July 12, 2010)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc TCPwrappers OpenSSL
(Continue reading)

Permalink | Reply | 0 comments |

Gmane