headers
lehmann | 2 Jan 2007 22:38
Picon

[Bug 441] New: request for unseen_remember_accepted option

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

http://www.exim.org/bugzilla/show_bug.cgi?id=441

           Summary: request for unseen_remember_accepted option
           Product: Exim
           Version: 4.64
          Platform: x86
        OS/Version: All
            Status: NEW
          Severity: wishlist
          Priority: medium
         Component: Delivery in general
        AssignedTo: ph10 <at> hermes.cam.ac.uk
        ReportedBy: lehmann <at> cnm.de
         QAContact: exim-dev <at> exim.org

What I would like to do is to have several routers that are all tried in a row
and checked if their conditions are met for a certain delivery. The hard part
is that more than one router may be responsible and more than one router shall
handle the delivery and pass it to a transport in that case. But the routers
shall not now anything from each other. So when a message comes in, exim shall
try all of these routers and remember if at least one of them accepts it so the
sender doesn't get a "User unknown".

As far as I know exim doesn't have an option for it. "unseen" lets exim try the
next router, but if that fails (doesn't accept) then exim thinks, that there is
no router that accepts the message because he forgot that the previous router
with the unseen option accepted it. So right now I have a very cumbersome
(Continue reading)

Permalink | Reply | 0 comments |
headers
mb/exim | 7 Jan 2007 17:29
Picon
Favicon

[Bug 443] New: would like to use user S/MIME certificate as sufficient authentication

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

http://www.exim.org/bugzilla/show_bug.cgi?id=443

           Summary: would like to use user S/MIME certificate as sufficient
                    authentication
           Product: Exim
           Version: 4.62
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: wishlist
          Priority: medium
         Component: TLS
        AssignedTo: ph10 <at> hermes.cam.ac.uk
        ReportedBy: mb/exim <at> dcs.qmul.ac.uk
         QAContact: exim-dev <at> exim.org

While $tls_peerdn is available, I'd like to use the "X509v3 Subject Alternative
Name" which my S/MIME certificates use to encode the e-mail address. This can
be used with AUTH EXTERNAL, at least in my set-up, such that the same user
certificate is used for SMTP AUTH and S/MIME signing.

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

--

--
Permalink | Reply | 1 comment |
headers
mb/exim | 7 Jan 2007 17:32
Picon
Favicon

[Bug 443] would like to use user S/MIME certificate as sufficient authentication

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

http://www.exim.org/bugzilla/show_bug.cgi?id=443

------- Comment #1 from mb/exim <at> dcs.qmul.ac.uk  2007-01-07 16:32 -------
Created an attachment (id=43)
 --> (http://www.exim.org/bugzilla/attachment.cgi?id=43&action=view)
OpenSSL patch for $tls_subject_alt_name

This "works for me", but might not be the way you want to do it. I haven't
written the GnuTLS version (it took me long to get the OpenSSL code together),
but could look into it if the rest of the patch looks OK to you.

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

--

--
Permalink | Reply | 0 comments |
headers
Michael Haardt | 9 Jan 2007 15:21
Picon

Old topic again: Option to avoid fsync()?

Hello,

I asked here once ago, but got no replies.

If you have a previously overloaded system that built up a large queue,
disabling fsync() is like an overboost switch: Not for regular operation,
but it solves the problem and brings you back to regular operation,
allowing to care about the original problem.

Apart from that, I run a spam honeypot where losing mail is no problem.
Avoiding fsync() for regular operation allows to run it on a way cheaper
system.

A command line option does not help, because it would not be passed
to queue runners and their children.  Either you compile Exim without
fsync() or introduce a new configuration file option.  Having an extra
executable finally annoys me enough to bring this topic up again.

Philip does not like an option like that, because dumb admins may use
it without being aware of the risks.  That's a valid point.

Me, I think the flexibility of Exim allows to screw up so many things
already, that dumb admins probably screw up already and have nothing
to lose.  I wouldn't mind if the daemon logged a message about unsafe
operation to mainlog when starting up.  I am trying to reduce the amount
of private Exim patches and getting this in the main distribution helps
me a lot, plus it may help others that know what they are doing.

Remember ghost busters: There will be the day when you have to cross
the streams. ;-)
(Continue reading)

Permalink | Reply | 19 comments |
headers
Michael Haardt | 9 Jan 2007 17:16
Picon

Re: Old topic again: Option to avoid fsync()?

> I try to avoid r/w contention by using full data journalling with external 
> journals, which are on physically different (and hopefully faster) HDDs. I 
> believe this is good practice for synchronous I/O like mail and NFS.

There is a bunch things you can do for _regular operation_.  But disks can
fail by getting ridiculous slow, networks can lose or destroy packets,
name servers can fail, then of course there are attacks and whatever
else... and you end up with a queue.

Disable fsync() for a couple minutes and people have their mail.  Enable
it again and everything is fine.

> For real psychopathic I-don't-care-about-my-data cases you can always use 
> tmpfs..

Right, but that may either cause swapping or I have a very limited queue.
Running the system on real disks, but without fsync(), means data will
either be written lazy, or not at all.  It's nicely in between tmpfs
and fsync().

Do you vote for or against having an option to disable fsync()?

Michael

--

--
Permalink | Reply | 1 comment |
headers
Matt Bernstein | 9 Jan 2007 15:44
Picon
Favicon

Re: Old topic again: Option to avoid fsync()?

At 15:21 +0100 Michael Haardt wrote:

> If you have a previously overloaded system that built up a large queue,
> disabling fsync() is like an overboost switch: Not for regular operation,
> but it solves the problem and brings you back to regular operation,
> allowing to care about the original problem.

I try to avoid r/w contention by using full data journalling with external 
journals, which are on physically different (and hopefully faster) HDDs. I 
believe this is good practice for synchronous I/O like mail and NFS.

For real psychopathic I-don't-care-about-my-data cases you can always use 
tmpfs..

--

--
Permalink | Reply | 18 comments |
headers
Matt Bernstein | 10 Jan 2007 11:28
Picon
Favicon

Re: Old topic again: Option to avoid fsync()?

On Jan 9 Michael Haardt wrote:

> Do you vote for or against having an option to disable fsync()?

Against; I don't want Exim authors blamed for irresponsible behaviour.

Another option available to you is to LD_PRELOAD a no-op for fsync(), eg 
<http://ftp.die.net/pub/qmail-tools/libnosync.c>.

But please try the external journal trick first, and set a commit interval 
as large as you like--I use a minute or two. Your I/O will scale since 
then main volume is largely only reading and the journal volume will only 
write if you have enough RAM.

--

--
Permalink | Reply | 0 comments |
headers
Florian Weimer | 10 Jan 2007 16:26
Picon

Re: Old topic again: Option to avoid fsync()?

* Matt Bernstein:

> I try to avoid r/w contention by using full data journalling with external 
> journals, which are on physically different (and hopefully faster) HDDs. I 
> believe this is good practice for synchronous I/O like mail and NFS.

If you want to throw money at the problem, a RAID controller with a
battery-backed cache is a good option as well.

On the other hand, with a lot drives in their default configuration,
fsync() can't reliably do what it claims to anyway. 8-/

--

--
Permalink | Reply | 15 comments |
headers
Michael Haardt | 10 Jan 2007 17:38
Picon

Re: Old topic again: Option to avoid fsync()?

On Wed, Jan 10, 2007 at 04:26:29PM +0100, Florian Weimer wrote:
> If you want to throw money at the problem, a RAID controller with a
> battery-backed cache is a good option as well.

You completely miss the point, so let me rephrase it:  I am _not_
talking about regular operation.  I am talking about cleaning up a mess,
e.g. after an attack or double/triple fault that managed to kill all
redundancy.  Additionally, exotic applications benefit from disabling
fsync().

It's not economical to run systems at 10% of their maximum performance
just to have enough if shit happens, unless of course you just run a
small site, where the economic disadvantage of doing so can be tolerated.

> On the other hand, with a lot drives in their default configuration,
> fsync() can't reliably do what it claims to anyway. 8-/

Actually, if you use maildir, there is no fsync() to synchronise the
directory, just one for the tmp file, but a code audit must be harder
than implicating to leave fsync in place under all conditions, because
it the most you can do and still sometimes not enough.

The only valid point so far was:

>> Do you vote for or against having an option to disable fsync()?

> Against; I don't want Exim authors blamed for irresponsible behaviour.

What's irresponsible most of the time, may exceptionally be sane.
LD_PRELOAD is an idea that probably works fine, although I don't like
(Continue reading)

Permalink | Reply | 14 comments |
headers
abs | 10 Jan 2007 14:07
Gravatar

[Bug 444] NetBSD specific build patches from pkgsrc

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

http://www.exim.org/bugzilla/show_bug.cgi?id=444

------- Comment #3 from abs <at> absd.org  2007-01-10 13:07 -------
Created an attachment (id=46)
 --> (http://www.exim.org/bugzilla/attachment.cgi?id=46&action=view)
Correct HAVE_SYS_STATVFS_H check for __NetBSD_Version__  >= 299000900

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

--

--
Permalink | Reply | 0 comments |

Gmane