auths/dovecot.c , server_socket IP listen

Hello
The other day needed to create an SMTP authentication via dovecot.
Dovecot with version 2.0 in addition to creating UNIX-socket can listen to TCP/IP socket.
I made changes to the file auths/dovecot.c.
Now in the config exim server_socket can be set as follows:
server_socket = 127.0.0.1:9999
File with the changes in atache.
Thank you.

Hello
The other day needed to create an SMTP authentication via dovecot.
Dovecot with version 2.0 in addition to creating UNIX-socket can listen to TCP/IP socket.
I made changes to the file auths/dovecot.c.
Now in the config exim server_socket can be set as follows:
server_socket = 127.0.0.1:9999
File with the changes in atache.
Thank you.

dbmjz lookup type - testing needed

So, it's all very well adding gsasl support but if real world admins
can't use it to migrate from Cyrus SASL, then it's not providing a
viable alternative.  I have nothing in particular against Cyrus, I just
want to make sure that we offer real options, with real competition.

sasldb2 stores passwords under a key composed of:
  $usercode \x00 $realm \x00 "userPassword"

I've added a new lookup type "dbmjz" to exim, on the "dbmjz" branch.  It
interprets the key as an Exim list and joins the list items together
with ASCII NUL characters to form the lookup key.  This key, with
embedded NULs, is then safely passed to the DBM routines and the result
retrieved.  Embedded NULs in the result will still cause problems
elsewhere, as may leading and trailing whitespace.

So I've tested this with both of:

auth_cram:
  driver        = gsasl
  public_name   = CRAM-MD5
  server_realm  = imap.spodhuis.org
  server_password = ${lookup{$auth1:$auth3:userPassword}dbmjz{/usr/local/etc/sasldb2}{$value}fail}
  server_set_id = ${quote:$auth1}
  server_condition = yes

auth_cram_own:
  driver     = cram_md5
  public_name   = CRAM-MD5
  server_secret = ${lookup{$auth1:imap.spodhuis.org:userPassword}dbmjz{/usr/local/etc/sasldb2}{$value}fail}
  server_set_id = $auth1

Re: [exim] DKIM problems

Thanks for checking. I'm traveling and will take a look at this next week.

-----Original Message-----
From: Phil Pennock [mailto:pdp <at> exim.org] 
Sent: Freitag, 2. März 2012 16:13
To: Marcin Mirosław
Cc: exim-users <at> exim.org; exim-dev <at> exim.org; Tom Kistner
Subject: Re: [exim] DKIM problems

On 2012-02-20 at 12:14 +0100, Marcin Mirosław wrote:
> W dniu 19.01.2012 22:34, Marcin Mirosław pisze:
> > W dniu 2012-01-19 21:49, Phil Pennock napisał(a):
> >> If you have a copy of such an email which you're willing to share, 
> >> then could you please forward it, WITH ALL HEADERS INTACT, to me 
> >> and I'll try to find time to take a look.
> > 
> > I sended such mail to you offlist.
> > Thank you.
> > 
> 
> Hello!
> Did you have some time to look into problematic email?

Is it possible that the mail was received using \r line termination, instead of \r\n ?

I think that we have a bug in that case: after the \r, we call
receive_getc() and if the resulting character is *not* \n, then we put it back with receive_ungetc().

Meanwhile, each call to receive_getc() updates DKIM state, so if
receive_ungetc() is ever called, that character will update DKIM state twice.

[Bug 1216] New: exigrep doesn't find all entries relevant to the message

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

http://bugs.exim.org/show_bug.cgi?id=1216
           Summary: exigrep doesn't find all entries relevant to the message
           Product: Exim
           Version: 4.76
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: bug
          Priority: medium
         Component: Exigrep
        AssignedTo: nigel <at> exim.org
        ReportedBy: arekm <at> maven.pl
                CC: exim-dev <at> exim.org

# exigrep -l some <at> email.pl logfile

finds:

2012-03-08 11:18:10 1S5aQE-0002B2-FJ <= root <at> test.pl U=root P=local S=466
2012-03-08 11:19:09 1S5aQE-0002B2-FJ => user1 <some <at> email.pl>
R=sql_uservacation T=uservacation_transport QT=59s
2012-03-08 11:19:09 1S5aQE-0002B2-FJ => some <at> other.email.pl <some <at> email.pl>
R=send_to_mailmxout_gateway T=remote_smtp H=mailmxout.pl [1.1.1.1] C="250 OK
id=1S5aRB-0002Es-Ss" QT=59s
2012-03-08 11:19:09 1S5aQE-0002B2-FJ Completed

while 

[Bug 1217] New: New lookup

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

http://bugs.exim.org/show_bug.cgi?id=1217
           Summary: New lookup
           Product: Exim
           Version: N/A
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: wishlist
          Priority: medium
         Component: Lookups
        AssignedTo: nigel <at> exim.org
        ReportedBy: warren <at> decoy.co.za
                CC: exim-dev <at> exim.org

Created an attachment (id=550)
 --> (http://bugs.exim.org/attachment.cgi?id=550)
Add new lookup type for Redis

Hi,

Attached is a patch which provides lookups via Redis of the noSQL family. With
this patch you can extract and set values in Redis. I am currently using the
store for storing various information on connecting hosts and then use that
information for actions to take on connections from these hosts. It has been
working in my environment without any hiccups for the last week but wider use
will be beneficial.

[Bug 1126] max_rcpt=1 disables multi message delivery on a single connection

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

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

Jasen Betts <jasen <at> treshna.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #489 is|0                           |1
           obsolete|                            |
 Attachment #493 is|0                           |1
           obsolete|                            |

--- Comment #6 from Jasen Betts <jasen <at> treshna.com>  2012-03-12 23:18:39 ---
Created an attachment (id=551)
 --> (http://bugs.exim.org/attachment.cgi?id=551)
combined patch with further fix 

OOPS I found another problem with my patch, permanent (and temporary) 
errors on a single address were "bleeding" into the rest of the list.

I have attached is a combined patch (includes other two patches) which fixes
this.

--

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

(no subject)

Ok, I'm learning about exim's innards.  I'm a firm believer that the
best way to learn something is to do a small project (trial by fire),
so I'm attempting to add PRDR (Per Recipient Data Response) capability
to exim.  I have not exactly settled on settings in the config file
(hardcoded on for the moment) nor an ACL approach.  At this point, I'm
just trying to get exim to recognize the request for PRDR.

The draft (now expired, but like I said, this is mostly for
educational purposes, and it might end up becoming useful if more
implement it) basically says that you add a PRDR capability to the
HELO reponse (done), and activate PRDR when it's requested by the
sending MTA during the mail from:

MAIL FROM:<user <at> example.com> PRDR

In the code which parses args to mail and rcpt commands, it requires
key=value pairs (for example, BODY=149833), so this type of option
which is just a singleton (what other word describes it?) is rejected
by the following code:

src/src/smtp_in.c:
    /* Loop, checking for ESMTP additions to the MAIL FROM command. */

    if (esmtp) for(;;)
      {
      uschar *name, *value, *end;
      unsigned long int size;

      if (!extract_option(&name, &value)) break;

Re: SMTP PRDR

I'm in no sense an authority, but here's my take:

On 2012-03-19 16:19, Todd Lyons wrote:
> MAIL FROM:<user <at> example.com>  PRDR
>
> In the code which parses args to mail and rcpt commands, it requires
> key=value pairs (for example, BODY=149833),

Actually, despite the comment on extract_option() I don't see it being
called at RCPT.  Maybe I'm missing something, or maybe the
comment needs correcting.

> So the extract_option requires a key=value pair.  At this point, the
> has not yet verified that the options are valid/invalid, it's just
> splitting them from the email address.  With contemporary exim design
> standards in mind:
>
> 1) would it better to pass a variable to extract_option() to indicate
> that "=" is not required?

Given the limited number of callers I'd be happy with such a mod.
The problem is that it's still required for the current options,
and you've not determined what the option is yet.

> 2) would it be better to make a duplicate function that basically just
> does #1 (i.e. not require "=")
> 3) something else?

I'd like a code refactor from the if/elseif chain into a table-driven
approach, using a static data table of acceptable option names

Re: SMTP PRDR

On Mon, Mar 19, 2012 at 10:47 AM, Jeremy Harris <jgh <at> wizmail.org> wrote:
> Actually, despite the comment on extract_option() I don't see it being
> called at RCPT.  Maybe I'm missing something, or maybe the
> comment needs correcting.

I took it at face value, but it appears to need correcting since it's
not called in the RCPT_CMD case.

>> So the extract_option requires a key=value pair.  At this point, the
>> has not yet verified that the options are valid/invalid, it's just
>> splitting them from the email address.  With contemporary exim design
>> standards in mind:
>> 1) would it better to pass a variable to extract_option() to indicate
>> that "=" is not required?
>
> Given the limited number of callers I'd be happy with such a mod.
> The problem is that it's still required for the current options,
> and you've not determined what the option is yet.
>
> I'd like a code refactor from the if/elseif chain into a table-driven
> approach, using a static data table of acceptable option names
> each with a "supplies argument" indicator.  This would be in line
> with (eg.) the parsing in acl_verify().

...that makes a lot of sense.  Until now, everything that exim
supported required an argument, so bailing on the absence of an "="
was sufficient for a quick sanity check.  To support non-argument
options, each option will have to be sanity checked and validated at
the same time.  Doing this in a table would be, theoretically, better
able to do both at once.

[Bug 1184] code refactoring in acl.c

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

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

--- Comment #1 from Phil Pennock <pdp <at> exim.org>  2012-03-19 22:19:47 ---
Has this continued to run in production without issues?

How extensive would you say your use of the ACL facilities is?

Have you tried running the test suite to look for regressions?

I'm just trying to get a feel for the risk involved; skimming the patch, it
looks sane.

Hrm, our test suite could probably do with a performance-testing system so we
can A/B test performance of, eg, "ACL logic evaluation".

--

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