Phil Pennock | 22 Apr 01:57 2014

Working with GitHub PRs

I got a notification email for a Pull Request on GitHub, it looked sane,
I merged it, then thought it might be worth a couple of notes to the
list on this.

  https://github.com/Exim/exim/pull/13

For those not already familiar: the "Files changed" tab is informative.

My general philosophy has been "we'll take contributions via any sane
means; we don't have so many contributors that we want to make people
jump through hoops, but we do _prefer_ to have things in our Bugzilla
for tracking.  For non-contentious changes, working from a GitHub PR is
fine." (and I think I'm previously on record as saying that).

In your Exim repo, use `git config -e` (or `--edit`) to edit the
repository's config file (_usually_ found at `.git/config` relative to
the top level of the repo).

Add these lines:

----------------------------8< cut here >8------------------------------
[remote "github"]
        fetch = +refs/heads/*:refs/remotes/github/*
        fetch = +refs/pull/*/head:refs/remotes/github/pr/*
        url = git <at> github.com:Exim/exim.git
----------------------------8< cut here >8------------------------------

Those assume that you're using SSH to talk to your GitHub account.  Note
that there are _two_ `fetch` specifications, and the second one is
slightly unusual.
(Continue reading)

Jeremy Harris | 20 Apr 15:34 2014

Re: [Bug 1455] tls_out_cipher or tls_cipher is empty

On 20/04/14 14:20, Andreas Metzler wrote:
> On the outgoing connection $tls_cipher expands to the same content as
> $tls_out_cipher which is expected and wanted. However there is also an
> unwanted change: tls_in_cipher is suddenly *nonempty*, it has gone
>                       ^^
> persistant, recording the tls-information as of message receipt:

> I am not doing callouts or something like this, so afaiui
> tls_in_cipher should be empty in X-TLS-info-out.

Ah, no.  That's what it's for; recording what the TLS information
was during acceptance of the mail item in question (now being
sent onwards).  There's no particular reason to make that
information *un*-available now that the conflict in use
of the legacy "tls_cipher" variable is resolved.
--

-- 
Cheers,
   Jeremy

Todd Lyons | 19 Apr 19:30 2014

Survey

It's been 6 months since the last release of Exim 4.82.  There has
been a flurry of bug-fixing, refactoring, and a few new features.
There's not really any major new feature, but the release guidelines
do suggest that every 6 months we release a new version with whatever
is in the tree.

Can we get some votes yea or nay for beginning a release cycle for Exim 4.83?

Last release I didn't give enough time between announcing the
beginning of the release cycle and code freeze, this time will be
longer, we'll say 2 weeks from the announcement.  I'm open to
suggestions of whether that time should be longer or shorter.

...Todd
--

-- 
The total budget at all receivers for solving senders' problems is $0.
 If you want them to accept your mail and manage it the way you want,
send it the way the spec says to. --John Levine

Resellerdesktop Admins | 17 Apr 14:50 2014
Picon

[Bug 1469] New: Bruteforce logentry does show base64 username

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

http://bugs.exim.org/show_bug.cgi?id=1469
           Summary: Bruteforce logentry does show base64 username
           Product: Exim
           Version: 4.80.1
          Platform: Other
        OS/Version: Windows
            Status: NEW
          Severity: bug
          Priority: medium
         Component: Logging
        AssignedTo: nigel <at> exim.org
        ReportedBy: customercare <at> resellerdesktop.de
                CC: exim-dev <at> exim.org

small bug in the anti bruteforce log :

H=68-188-72-60.static.stls.mo.charter.com ([192.168.2.33]) [68.188.72.60]
rejected AUTH LOGIN YW1pdA==: authentication is allowed only once per message
in order to slow down bruteforce
cracking

10:1 it should give out the decoded name, not the base64 version :)

--

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

(Continue reading)

Sorin Sbarnea | 14 Apr 13:51 2014
Picon

[Bug 1465] New: Allow recipients with # (hash/pound sign) in their addreses

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

http://bugs.exim.org/show_bug.cgi?id=1465
           Summary: Allow recipients with # (hash/pound sign) in their
                    addreses
           Product: Exim
           Version: N/A
          Platform: Other
               URL: http://www.gossamer-
                    threads.com/lists/exim/users/29610#29610
        OS/Version: All
            Status: NEW
          Severity: bug
          Priority: medium
         Component: Delivery in general
        AssignedTo: nigel <at> exim.org
        ReportedBy: sorin.sbarnea <at> gmail.com
                CC: exim-dev <at> exim.org

We are currently using exim4 to filter email messages from few servers before
sending them to corporate Exchange servers.

We just discovered that exim was dropping all messages send to Exchange mailing
lists because they all were starting with "#" hash sign.

If this can be obtained via re-configuration it would be great.

--

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

Jeremy Harris | 14 Apr 16:48 2014

[Bug 1466] New: Support entire certificate chain for OCSP stapling

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

http://bugs.exim.org/show_bug.cgi?id=1466
           Summary: Support entire certificate chain for OCSP stapling
           Product: Exim
           Version: 4.82
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: security
          Priority: low
         Component: TLS
        AssignedTo: pdp <at> exim.org
        ReportedBy: jgh146exb <at> wizmail.org
                CC: exim-dev <at> exim.org

The original OCSP RFC, 6066, provides for a single OCSP proof (for the server
certificate).  A later RFC, https://www.ietf.org/rfc/rfc6961.txt specifies a
TLS extension for multiple certificate status requests.   We should consider
supporting it.

Concerns include the resulting size and overhead of the TLS startup; suggested
mitigation includes caching.

See also:
http://www.ietf.org/mail-archive/web/tls/current/msg09566.html
http://bugs.exim.org/show_bug.cgi?id=1459

--

-- 
(Continue reading)

Wolfgang Breyha | 9 Apr 14:26 2014
Picon
Picon

heartbleed detection

Hi!

I patched my exim to detect heartbleed attacks/checks. The patch is quick and
dirty and not intended for HEAD or inexperienced users. That's why I post it
only here. Don't know the impact of setting a tls_msg_callback on the
performance yet.

Maybe somebody is interested. Try at your own risk;-)

It works with patched OpenSSL versions as well as with unpatched ones.

Patch will most likely apply with some fuzz, since I've other patches in place
as well.

Greetings, Wolfgang
--

-- 
Wolfgang Breyha <wbreyha <at> gmx.net> | http://www.blafasel.at/
Vienna University Computer Center | Austria

Hi!

I patched my exim to detect heartbleed attacks/checks. The patch is quick and
dirty and not intended for HEAD or inexperienced users. That's why I post it
only here. Don't know the impact of setting a tls_msg_callback on the
performance yet.

Maybe somebody is interested. Try at your own risk;-)
(Continue reading)

Jeremy Harris | 6 Apr 22:01 2014

[Bug 1462] New: recipient verify should make 5xx messsage available

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

http://bugs.exim.org/show_bug.cgi?id=1462
           Summary: recipient verify should make 5xx messsage available
           Product: Exim
           Version: 4.82
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: wishlist
          Priority: medium
         Component: ACLs
        AssignedTo: jgh146exb <at> wizmail.org
        ReportedBy: jgh146exb <at> wizmail.org
                CC: exim-dev <at> exim.org

It'd be nice to get any information the target gave with the rejection visible
in $acl_verify_messsage

--

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

Jeremy Harris | 6 Apr 15:38 2014

[Bug 1461] New: dnssec use floods /var/log/messages

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

http://bugs.exim.org/show_bug.cgi?id=1461
           Summary: dnssec use floods /var/log/messages
           Product: Exim
           Version: 4.82
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: bug
          Priority: medium
         Component: Lookups
        AssignedTo: jgh146exb <at> wizmail.org
        ReportedBy: jgh146exb <at> wizmail.org
                CC: exim-dev <at> exim.org

The intro of dnssec checking on rdns lookups exposes a bug in the linux glibc:
once the process-global resolver options dnssec bit is set, old-style
gethostbyaddr lookup use it too and proceed to spit an error when the
non-understood RR arrives:

We'll be chasing the glibc issue separately, but exim might workaround by
either
flipping the dnssec bit only while needed or by converting all current use of
gethostby* to use the newer res_search().  The latter is preferred because we
want to use toward dnssec-everywhere (and anyway, gethostbyname in obsoleted by
getaddrinfo where both ipv4 & ipv6 returns are possible).

How this impacts OS' which use getipnodebyaddr (SunOS5, apparently) I'm not
(Continue reading)

Andreas Metzler | 5 Apr 18:20 2014
Picon

Re: [Bug 1455] tls_out_cipher or tls_cipher is empty

On 2014-04-05 Jeremy Harris <jgh146exb <at> wizmail.org> wrote:
[...]
> --- Comment #5 from Jeremy Harris <jgh146exb <at> wizmail.org>  2014-04-05 14:14:48 ---
> I'm sorry I've not yet had time to look into this.  Do you have a suggested
> patch?  Enhanced tests for the regression suite would also be of benefit.

Hello,

sadly I have not got a patch. The initial idea of simply adding a
'tls_support *tls' and having it point to tls_in or tls_out as the
situation requires does not work, since it is not possible to use the 
pointer in expand.c ("initializer element is not constant").

Which means it is not trivial to do and therefore shouldn't be done by
me. ;-)

OTOH, looking at the initial comment in git history
(817d9f576cdfbc27cf0536be348645baf27d7836) I am wondering whether it
is even possible to do:
----------
Dual-tls - split management of TLS into in- and out-bound
connection-handling.

Enables concurrent use from a single process, and thereby use for
cutthrough delivery.  As a side-effect EHLO and TLS use for verify
callouts introduced.
----------

With the concurrent use exim can hold open two TLS connections (message
receiption incoming and outgoing callout/cutthrough). - Which of these
(Continue reading)

Jeremy Harris | 1 Apr 22:29 2014

[Bug 1459] New: OCSP-stapling support under GnuTLS

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

http://bugs.exim.org/show_bug.cgi?id=1459
           Summary: OCSP-stapling support under GnuTLS
           Product: Exim
           Version: 4.82
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: wishlist
          Priority: medium
         Component: TLS
        AssignedTo: pdp <at> exim.org
        ReportedBy: jgh146exb <at> wizmail.org
                CC: exim-dev <at> exim.org

The current (experimentsl) Online Certificate Status Protocol (OCSP) stapling
support is only for OpenSSL.  It should be also supported under GnuTLS.

--

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


Gmane