On Feb 12, 2009, at 0:22, Robert Spier wrote:
Ah; git is great. :-) Basically this is like passing a patch
around,
but with tools that are made to work with it. (We could also have
had
three commits with two of them just having for the history books
useless tweaks).
Kind of. I used gi
Matt Sergeant wrote:
>
> Also note this won't work with -async properly. I'll have a look how it
> can be made to work asynchronously (you need to follow the respond
> style in the rest of the code).
For some reason, I thought I looked at the rest of the code and
convinced myself it would, be
Ask Bjørn Hansen wrote:
>
>
> On Feb 10, 2009, at 2:43, Robert Spier wrote:
>
> > Committed as
> >
> > http://github.com/rspier/qpsmtpd/commit/a0ae0453264fe8dd85c132f2e7305b5ac34bf7e8
> >
> > Did you actually test that this worked? I had to tweak the code to
> > make it make sense. Also, you
On Tue, 2009-10-02 at 20:54 -0800, Ask Bjørn Hansen wrote:
> Thanks. I tweaked the commit message a bit. In git the first line
> works more like a subject line; many tools will show just the first
> line by default. (For example "git shortlog v0.40.."
Shortlog shows only the subject. It is
On Feb 10, 2009, at 12:33, Hanno Hecker wrote:
Hanno - do you want to make a patch that removes README.plugins after
incorporating anything unique there into plugins.pod?
Done
http://github.com/vetinari/qpsmtpd/commit/4e892560eb8aa1074e2ce1548e6c337d0e19a0fb
Thanks. I tweaked the commit me
On Tue, 10 Feb 2009 00:25:50 -0500
Ask Bjørn Hansen wrote:
>
> On Feb 9, 2009, at 23:58, Hanno Hecker wrote:
>
> > There should be a note in README.plugins, that the full documentation
> > of the hooks is in docs/plugins.pod ... (or replace it's entire
> > content
> > with a redirection do do
Also note this won't work with -async properly. I'll have a look how it
can be made to work asynchronously (you need to follow the respond
style in the rest of the code).
On Mon, 09 Feb 2009 23:43:05 -0800, Robert Spier wrote:
>
> Committed as
>
>
http://github.com/rspier/qpsmtpd/commit/a0ae
On Feb 10, 2009, at 2:43, Robert Spier wrote:
Committed as
http://github.com/rspier/qpsmtpd/commit/a0ae0453264fe8dd85c132f2e7305b5ac34bf7e8
Did you actually test that this worked? I had to tweak the code to
make it make sense. Also, you had a mix of tabs and spaces and didn't
follow the sty
Committed as
http://github.com/rspier/qpsmtpd/commit/a0ae0453264fe8dd85c132f2e7305b5ac34bf7e8
Did you actually test that this worked? I had to tweak the code to
make it make sense. Also, you had a mix of tabs and spaces and didn't
follow the style of the rest of the code. I cleaned them up
Ask Bjørn Hansen wrote:
>
>
> On Feb 9, 2009, at 23:58, Hanno Hecker wrote:
>
> > There should be a note in README.plugins, that the full documentation
> > of the hooks is in docs/plugins.pod ... (or replace it's entire
> > content
> > with a redirection do docs/plugins.pod)
>
>
> Hanno - do
On Feb 9, 2009, at 23:58, Hanno Hecker wrote:
There should be a note in README.plugins, that the full documentation
of the hooks is in docs/plugins.pod ... (or replace it's entire
content
with a redirection do docs/plugins.pod)
Hanno - do you want to make a patch that removes README.plugi
On Mon, 9 Feb 2009 22:25:51 +0100
"Karl Y. Pradene" wrote:
> On Mon, 09 Feb 2009 10:10:47 -0800 Robert Spier
> wrote:
> > Can you update the patch with
> > - documentation
> > - ... including a warning
> > - changing the name?
> >
> > And then I'll happily apply it.
> And
And voila. Hook renamed to data_headers_end, documentation in
README.plugins with a BIG warning.
Just a thought -- perhaps the methodology for throwing away further
input as cleverly described by Jose Martinez should be thrown around and
tested and then documented in README.plugins together wi
On Sun, Feb 8, 2009 at 1:24 AM, Ask Bjørn Hansen wrote:
>
>
>
> Look in data_respond in lib/Qpsmtpd/SMTP.pm -- it would be pretty easy to
> add. Look for the line that says "$in_header = 0;"
>
> I'm not sure it'd be useful though, because the only way you can avoid
> receiving the data anyway at
On Mon, 09 Feb 2009 10:10:47 -0800 Robert Spier
wrote:
>
> > Functionally, just about anything you can do here you can do just as
> >
> > I don't see a problem with adding it per-se. It'd make my
> > plugins/config file ordering a trifle simpler, but it doesn't
> > really add any functionality
Chris Lewis escribió:
Functionally, just about anything you can do here you can do just as
easily with a data_post plugin.
- By putting your header checks in this hook, you can more explicitly
control sequencing and enable/disable of header versus body checking.
_However_, you can do this just
On Mon, 09 Feb 2009 10:10:47 -0800 Robert Spier
wrote:
>
> > Functionally, just about anything you can do here you can do just as
> >
> > I don't see a problem with adding it per-se. It'd make my
> > plugins/config file ordering a trifle simpler, but it doesn't
> > really add any functionality
> Functionally, just about anything you can do here you can do just as
>
> I don't see a problem with adding it per-se. It'd make my
> plugins/config file ordering a trifle simpler, but it doesn't really add
> any functionality. I agree there should be a big warning about
> rejects/disconnects
Jose Luis Martinez wrote:
> Robert Spier escribió:
>> The patch itself looks fine, I'm not sure whether we actually should
>> support this or not.
>>
>
> Why not? After all, if you don't need it, you don't use it. What about a
> warning in the docs saying something like "be careful! If you drop
I think Jose's argument was persuasive, let's just add it. I didn't
understand why one line resetting/setting/... the headers in the
transaction object was removed; but I didn't look that closely.
Karl - your English is better than many who pretend to be fluent or
even native speakers. :-
Robert Spier escribió:
The patch itself looks fine, I'm not sure whether we actually should
support this or not.
Why not? After all, if you don't need it, you don't use it. What about a
warning in the docs saying something like "be careful! If you drop the
connection: legal MTAs will retry,
On Sun, 08 Feb 2009 22:29:14 -0800 Robert Spier
wrote:
> The patch itself looks fine, I'm not sure whether we actually should
> support this or not.
We can try.
> (It also needs an update to README.plugins, and maybe should be called
> data_headers_end, but those are little things.)
I can do it
The patch itself looks fine, I'm not sure whether we actually should
support this or not.
(It also needs an update to README.plugins, and maybe should be called
data_headers_end, but those are little things.)
Anyone else want to chime in?
Karl Y. Pradene wrote:
>
> On Sat, 7 Feb 2009 23:24:39
On Sat, 7 Feb 2009 23:24:39 -0800 Ask Bjørn Hansen
wrote:
>
> On Feb 7, 2009, at 6:25, Karl Y. Pradene wrote:
>
> > Hi,
> > is it possible add a hook at the end of headers?
>
> Hi Karl,
>
> Look in data_respond in lib/Qpsmtpd/SMTP.pm -- it would be pretty
> easy to add. Look for the line tha
On Sat, 7 Feb 2009 23:24:39 -0800 Ask Bjørn Hansen
wrote:
>
> On Feb 7, 2009, at 6:25, Karl Y. Pradene wrote:
>
> > Hi,
> > is it possible add a hook at the end of headers?
>
> Hi Karl,
>
> Look in data_respond in lib/Qpsmtpd/SMTP.pm -- it would be pretty
> easy to add. Look for the line tha
On Feb 7, 2009, at 6:25, Karl Y. Pradene wrote:
Hi,
is it possible add a hook at the end of headers?
Hi Karl,
Look in data_respond in lib/Qpsmtpd/SMTP.pm -- it would be pretty easy
to add. Look for the line that says "$in_header = 0;"
I'm not sure it'd be useful though, because the only
That sounds intriguing... it may not be very RFC-compliant to actually, say,
interrupt a sender halfway through DATA transmission to tell them that you're
rejecting based on headers, though.
I can't say that has always stopped me...
-Jared
From: Karl Y.
27 matches
Mail list logo
