Hi all.
Finally after 2-3 weks of playing with qmail on a server i succeded to
install it with courier-imap and vmailmgr.My last desire though is to have
the ability my users not to be UNIX users but virtual users.I have problems
with my vmailmgr program but i would like to know if there is a w
Am Dienstag, 9. Januar 2001 13:13 schrieb Johan Almqvist:
> However, the log will be incompatible anyhow, because right now, an
> eventual analysis tool will just not see the qmtp deliveries at all. To
> fix that, my patch minus the protocol information must be used, and maybe
> (depending on th
On Tue, Jan 09, 2001 at 01:13:07PM +0100, Henning Brauer wrote:
> Am Dienstag, 9. Januar 2001 11:36 schrieb Johan Almqvist:
> > Do we want smtp to say:
> > success:
> > smtp:192.203.178.8_accepted_message./Remote_host_said:_250_ok_978720863_qp_
> >22711/
> I'd not change the this, it makes smtp l
Am Dienstag, 9. Januar 2001 11:36 schrieb Johan Almqvist:
> Do we want smtp to say:
> success:
> smtp:192.203.178.8_accepted_message./Remote_host_said:_250_ok_978720863_qp_
>22711/
I'd not change the this, it makes smtp log entries incompatible with stock
qmail. Even if it's more logical.
--
On Fri, Jan 05, 2001 at 07:05:02PM +, Mark Delany wrote:
> Russ offers: http://qmail.org/qmail-1.03-qmtpc.patch
> Feedback: Given a sample of one, this patch seems to work. Nice work.
> Suggestion: What about making the log file entries more consistent
> with the current format?
Russ offers: http://qmail.org/qmail-1.03-qmtpc.patch
Feedback: Given a sample of one, this patch seems to work. Nice work.
Suggestion: What about making the log file entries more consistent
with the current format?
Current smtp:
success: 192.203.178.8_accepted_message./Remote_host_said
> > when discussing as we are currently, could we take care only to reply
> > to the list or only to the author but not both. it's not a biggy and i
> > am a newbie here, so maybe i should not propose that, but getting the
> > same mail twice can be annoying...
> Simply add the following to your
wrapper.
I will also use PHP4-session management, to also get rid of the
current mysql-based system.
If you have any suggestion or feature request, it's the right moment!
So please have a look at http://omail.omnis.ch/ or test the
demo on http://admin.omnis.ch/omail/ (test.com + test as p
Brett:
Apparently procmail 3.15pre supports maildir. It even has a sample script...
Eric Wolven
On Wed, Jun 28, 2000 at 11:15:44AM -0500, Ronny Haryanto wrote:
> On 28-Jun-2000, Morten Liebach wrote:
> > So ... how does procmail handle maildir then? Or doesn't procmail care
> > about that at all?
>
> procmail has "native" maildir support since 3.14.
>
> > It's the only thing I need to know
On Thu, Jun 29, 2000 at 02:12:16AM +1000, Brett Randall wrote:
> >So ... how does procmail handle maildir then? Or doesn't procmail care
> >about that at all?
>
> AFAIK (someone correct me if I am wrong), procmail does not support Maildir.
There are patches for procmail to make use of Maildirs;
Brett Randall wrote:
>AFAIK (someone correct me if I am wrong), procmail does not support Maildir.
It does, as of version 3.14.
Mark
--
Do not reply directly to this e-mail address
--
Mark Mentovai
UNIX Engineer
Gillette Global Network
On 28-Jun-2000, Morten Liebach wrote:
> So ... how does procmail handle maildir then? Or doesn't procmail care
> about that at all?
procmail has "native" maildir support since 3.14.
> It's the only thing I need to know before I switch to qmail, as I have
> a very nice and wellfunctioning .procma
On Thu, Jun 29, 2000 at 02:12:16AM +1000, Brett Randall wrote:
> >So ... how does procmail handle maildir then? Or doesn't procmail care
> >about that at all?
>
> AFAIK (someone correct me if I am wrong), procmail does not support Maildir.
Well, stand corrected :->
Newest procmail supports Mail
>So ... how does procmail handle maildir then? Or doesn't procmail care
>about that at all?
AFAIK (someone correct me if I am wrong), procmail does not support Maildir.
BR
On Wed, Jun 28, 2000 at 08:49:51AM +0200, Steffan Hoeke wrote:
> Daniel,
>
> On Wed, Jun 28, 2000 at 01:43:45AM -0500, Snowcrash wrote:
> >
> > This one may be in the works already.. but has there been any thought
> > into adding folder capabilities? I have some users that owuld like to be
Daniel,
On Wed, Jun 28, 2000 at 01:43:45AM -0500, Snowcrash wrote:
>
> This one may be in the works already.. but has there been any thought
> into adding folder capabilities? I have some users that owuld like to be
> able to create custom folders for mail sorting.
IMHO this is *not* someth
This one may be in the works already.. but has there been any thought
into adding folder capabilities? I have some users that owuld like to be
able to create custom folders for mail sorting.
Daniel Daley
[EMAIL PROTECTED]
> Russ Allbery:
> > WHAT'S WRONG WITH LEARNING PYTHON
>
> It's annoying? :)
and dots-in-names dont make oo!
clemens
> > * GNU Mailman: looks superswell, but I'd rather not have to learn python
>
> WHAT'S WRONG WITH LEARNING PYTHON
yeah! i hate it, too!
clemens
Ben Beuchler <[EMAIL PROTECTED]> writes:
> On Tue, Jun 06, 2000 at 11:13:51PM -0400, John R Levine wrote:
>> * Majordomo 2: looks swell but is in perpetual alpha, dunno about VERP
> I've never liked majordomo... But that's just personal opinion.
Majordomo 2 is a completely different program tha
[ added ezmlm list to cc: ]
also sprach johnl:
> I'm moving my lists to a new server, and I figure this is as good a time
> as any to look for something better than Majordomo 1.94. Here's what I
> want:
[snip]
> -- web interface, at least enough so that the subscription confirmation
>can h
On Tue, Jun 06, 2000 at 11:13:51PM -0400, John R Levine wrote:
> * Majordomo 2: looks swell but is in perpetual alpha, dunno about VERP
I've never liked majordomo... But that's just personal opinion.
> * ezmlm: no digests, no web, no MIME
What you want is ezmlm-idx, a fully supported patch fo
y, June 07, 2000 6:13 AM
Subject: Suggestion for mailing list manager?
> I'm moving my lists to a new server, and I figure this is as good a time
> as any to look for something better than Majordomo 1.94. Here's what I
> want:
>
> -- automatic VERP bounce processing
> -- pl
I'm moving my lists to a new server, and I figure this is as good a time
as any to look for something better than Majordomo 1.94. Here's what I
want:
-- automatic VERP bounce processing
-- plain and digest lists
-- multiple lists in multiple virtual domains
-- plays nicely with qmail
-- does s
I find some of the error messages from qmail to be quite terse. This
one perplexed me this morning:
Jan 9 11:19:14 nemeton qmail: 947377154.120073 delivery 9: deferral:
Unable_to_chdir_to_maildir._(#4.2.1)/
In this case I'd left a domain listed in 'locals' when I added it to
virtualdomains a
On Wed, Aug 18, 1999 at 11:39:05PM -0500, Mate Wierdl wrote:
: As I was searching for various patches at ftp sites, I got struck by
: how many different names patches get --- and how many different
: versions there are. For example, there are 5 different versions of
: the big-todo patch, and as a
Title: RE: humble suggestion from a confused boy
A lot of people also make functionally equivalent. Perhaps just a central table that has each patch, its latest revision date, its current status, etc. so people can differentiate between them.
Cris Daniluk
MicroStrategy
> -Origi
On Wed, Aug 18, 1999 at 11:39:05PM -0500, Mate Wierdl wrote:
> I know, none of the above problems are outrageous, but one can spend
> considerable time on sorting out badly organized patches. (Sorry, for
> picking on the big-todo patc, but I still do not know, which one is
> the latest, www.qmail
As I was searching for various patches at ftp sites, I got struck by
how many different names patches get --- and how many different
versions there are. For example, there are 5 different versions of
the big-todo patch, and as a test, I'd ask the maintainers if they
know offhand under what name t
-Original Message-
From: Harald Hanche-Olsen <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Wednesday, June 16, 1999 5:43 PM
Subject: Re: Suggestion: qmail-unqueue
>+ "Peter van der Landen" <[EMAIL PROTECTED]>:
>
>| I had a prob
+ "Peter van der Landen" <[EMAIL PROTECTED]>:
| I had a problem with a remote site that messed up its primary MX
| configuration so mail to that site stayed in the queue. I briefly
| considered doing a script that would send it to the (functional)
| secondary MX instead.
Why not simply make a co
-Original Message-
From: Russell P. Sutherland <[EMAIL PROTECTED]>
To: Russell Nelson <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Wednesday, June 16, 1999 4:40 PM
Subject: Re: Suggestion: qmail-unqueue
>On Wed, Jun 16, 1999 at 01:11:45PM
Jos Backus wrote/schrieb/scribsit:
> Who knows, maybe 2.0 will have a generalized delivery type:
> local/remote/bounce/discard/..., and the possibility to change it on the fly
> for a given message.
Return-Path: <[EMAIL PROTECTED]>
Date: 13 Dec 1998 03:09:02 -
Message-ID: <[EMAIL PROTECTED]>
Peter van der Landen writes:
> Trying to keep in with the Qmail way of doing things, It might have the
> following syntax:
>
> qmail-unqueue queue-id program [ arg ... ]
>
> The queue-id could be extracted from the qmail-qread output. The program
> would receive the message on stdin & the
On Wed, Jun 16, 1999 at 10:08:03AM +0200, Peter van der Landen wrote:
> I wouldn't dream of doing this myself but maybe Dan could implement it with
> proper locking.
It would have to go in qmail-send, which will probably look rather different
in 2.0. That's my guess.
> The very fact that messing
>On Wed, Jun 16, 1999 at 09:52:07AM +0200, Peter van der Landen wrote:
>> I probably overlooked some important aspects but it seems useful...
>
>You're not supposed to mess with the queue while qmail-send is running...
I wouldn't dream of doing this myself but maybe Dan could implement it with
p
On Wed, Jun 16, 1999 at 09:52:07AM +0200, Peter van der Landen wrote:
> I probably overlooked some important aspects but it seems useful...
You're not supposed to mess with the queue while qmail-send is running...
--
Jos Backus _/ _/_/_/ "Reliability means never
You can easily insert messages into Qmail's queue with qmail-queue but there
seems to be no approved way of 'manually' extracting messages from the
queue.
Would a 'qmail-unqueue' program be a good idea?
Trying to keep in with the Qmail way of doing things, It might have the
following syntax:
qm
On Wed, Apr 07, 1999 at 09:42:18AM +0200, Peter van Dijk wrote:
> Well extend it a bit to ignore qmtp in smtp banners for like one hour if qmtp turns
> out to be _not_ available. No big deal.
Right. I just wanted to throw that into the proposal. An hour is
probably a good long time.
-Peter
On Wed, Apr 07, 1999 at 10:37:48AM -0400, Chris Johnson wrote:
> On Wed, Apr 07, 1999 at 08:53:29AM -0500, Fred Lindberg wrote:
> > Since SMTP and QMTP are linked anyway, the advertizing of QMTP by the
> > SMTP server could easily be linked to QMTP being up. Thus, a working
> > smtpd with a failed
On Wed, 7 Apr 1999 10:37:48 -0400, Chris Johnson wrote:
>Why not just implement QMTP in qmail-smtpd? qmail-smtpd would advertise QMTP in
>its banner, and then the host connecting would be free to start firing away in
>QMTP lingo. There would never be any question of QMTP being up, since
>qmail-sm
> From: Richard Letts <[EMAIL PROTECTED]>
> Date: Wed, 7 Apr 1999 19:06:04 +0100 (BST)
>
> On Tue, 6 Apr 1999, Peter C. Norton wrote:
>
> > On Tue, Apr 06, 1999 at 06:31:03PM -0500, Chris Garrigues wrote:
> > >
> > > netstat -a |fgrep '*:qmtp'
> > >
> > > or the low-level C equivalent.
> >
On Tue, 6 Apr 1999, Peter C. Norton wrote:
> On Tue, Apr 06, 1999 at 06:31:03PM -0500, Chris Garrigues wrote:
> >
> > netstat -a |fgrep '*:qmtp'
> >
> > or the low-level C equivalent.
>
> I'm not concerned with this. I'm concerned with Fred's proposal
> relying on the status of the remote
On Wed, Apr 07, 1999 at 08:53:29AM -0500, Fred Lindberg wrote:
> Since SMTP and QMTP are linked anyway, the advertizing of QMTP by the
> SMTP server could easily be linked to QMTP being up. Thus, a working
> smtpd with a failed qmtpd (admin forgot to start?) would not advertize
> QMTP. This would
On Tue, 6 Apr 1999 19:40:59 -0400, Peter C. Norton wrote:
>I'm not concerned with this. I'm concerned with Fred's proposal
>relying on the status of the remote smtp and qmtp server. If I'm
>"local" and someone else is "remote" and remote's qmtp service is
>down, but remote's smtp server is stil
On Tue, Apr 06, 1999 at 07:40:59PM -0400, Peter C. Norton wrote:
> On Tue, Apr 06, 1999 at 06:31:03PM -0500, Chris Garrigues wrote:
> >
> > netstat -a |fgrep '*:qmtp'
> >
> > or the low-level C equivalent.
>
> I'm not concerned with this. I'm concerned with Fred's proposal
> relying on the
On Tue, Apr 06, 1999 at 06:31:03PM -0500, Chris Garrigues wrote:
>
> netstat -a |fgrep '*:qmtp'
>
> or the low-level C equivalent.
I'm not concerned with this. I'm concerned with Fred's proposal
relying on the status of the remote smtp and qmtp server. If I'm
"local" and someone else is
> From: "Peter C. Norton" <[EMAIL PROTECTED]>
> Date: Tue, 6 Apr 1999 19:26:46 -0400
>
> The outbound smtp agent would have to be aware somehow of the
> activities of its fellow outbound qmtp server. If the smtp listener
> on a remote site is advertising qmtp, and its qmtp server is not
> respo
On Tue, Apr 06, 1999 at 05:57:37PM -0500, Fred Lindberg wrote:
> When sending, one would look up host names in the cdb, and if
> QMTP-capable start a QMTP dialog. If it fails, the db can be updated
> with that info (it doesn't matter if it takes a while to make it to the
> cdb since this should be
Instead of MX magic, would it be possible to use a local cache to keep
track of QMTP-capable hosts?
QMTP is most useful for hosts that we talk to often and [with
multi-recipient protocols] with smarthosts, etc. Thus, it should be
possible to use SMTP by default, recognize from the banner that the
52 matches
Mail list logo
