On 2006-06-18 22:08:05 +0200, Robert Millan wrote:
diff -Nur qpsmtpd-0.32.old/lib/Qpsmtpd/Constants.pm
qpsmtpd-0.32/lib/Qpsmtpd/Constants.pm
--- qpsmtpd-0.32.old/lib/Qpsmtpd/Constants.pm 2006-02-26 13:22:16.0
+0100
+++ qpsmtpd-0.32/lib/Qpsmtpd/Constants.pm 2006-06-18
On Sun, Jun 18, 2006 at 03:15:37PM -0700, Ask Bjørn Hansen wrote:
On Jun 18, 2006, at 11:25 AM, Robert Millan wrote:
Can you rewrite this to be a plugin?
Yes. But are you sure it's necessary to split it? Given that
nothing happens
unless users create ~/.preforward files, I'd say
On Sun, Jun 18, 2006 at 07:08:34PM -0700, Robert Spier wrote:
Comments:
- provide more documentation in the plugin, mention 2821 section 3.4
(and a short paragraph)
- should be off by default (even though it requires the existence of
files.)
Ok.
- wondering if it should be
On 19-Jun-06, at 7:31 AM, Peter J. Holzer wrote:
Which reminds me: I think we should move to a more flexible system of
return codes
We do. $self-qp-respond(CODE, @MESSAGE); return DONE;
(that's why we have the DONE return code).
Ok, here is it. I tried to make a very complete description here; hope you
like it.
--
Robert Millan
diff -Nur qpsmtpd-0.32.old/config.sample/plugins
qpsmtpd-0.32/config.sample/plugins
--- qpsmtpd-0.32.old/config.sample/plugins 2006-02-26 13:22:16.0
+0100
+++
Hi!
The attached patch implements code 551 as described in RFC 2821 section 3.4.
The idea is that the originator MTA is told via DSN which address is the final
destination of this email, instead of transparently forwarding it.
The following code is returned by server:
551 User not local;
I like the idea, but nothing else in qpsmtpd knows about local
delivery.
Can you rewrite this to be a plugin?
-R
At Sun, 18 Jun 2006 19:27:11 +0200,
Robert Millan wrote:
diff -ur qpsmtpd-0.32.old/lib/Qpsmtpd/Constants.pm
qpsmtpd-0.32/lib/Qpsmtpd/Constants.pm
---
Also, what other MTA's support this on the sending side? We don't.
-R
At Sun, 18 Jun 2006 10:55:00 -0700,
Robert Spier wrote:
I like the idea, but nothing else in qpsmtpd knows about local
delivery.
Can you rewrite this to be a plugin?
-R
At Sun, 18 Jun 2006 19:27:11 +0200,
On Sun, Jun 18, 2006 at 10:55:00AM -0700, Robert Spier wrote:
I like the idea, but nothing else in qpsmtpd knows about local
delivery.
Can you rewrite this to be a plugin?
Yes. But are you sure it's necessary to split it? Given that nothing happens
unless users create ~/.preforward
On Sun, Jun 18, 2006 at 10:56:50AM -0700, Robert Spier wrote:
Also, what other MTA's support this on the sending side?
None that I know of, but Exim is high in my TODO as well.
We don't.
I was looking at this, but I couldn't find the code in qpsmtpd that handles
mail sending. Does support
I like the idea, but nothing else in qpsmtpd knows about local
delivery.
Can you rewrite this to be a plugin?
Yes. But are you sure it's necessary to split it? Given that nothing happens
unless users create ~/.preforward files, I'd say it's quite harmless.
Yes. It is definitely
We don't.
I was looking at this, but I couldn't find the code in qpsmtpd that handles
mail sending. Does support for 551 actualy belong to qpsmtpd itself, or a
library? (Mail::* perhaps?)
A library. Brain fart on mentioning qpsmtpd. It's too early in the
morning and too hot already.
-R
On Jun 18, 2006, at 11:25 AM, Robert Millan wrote:
Can you rewrite this to be a plugin?
Yes. But are you sure it's necessary to split it? Given that
nothing happens
unless users create ~/.preforward files, I'd say it's quite harmless.
Just to explain the policy:
The trouble is that
Comments:
- provide more documentation in the plugin, mention 2821 section 3.4
(and a short paragraph)
- should be off by default (even though it requires the existence of
files.)
- wondering if it should be called preforward-local or something
because it works on local files.
- is
14 matches
Mail list logo
