On Tue, Jan 31, 2006 at 01:23:08AM -0700, Philip Prindeville wrote:
> I was just thinking... We don't export any of the Sendmail variables into
> the filter_helo() code:
>
> O Milter.macros.helo={tls_version}, {cipher}, {cipher_bits}, {cert_subject},
> {cert_issuer}
>
> What to do about that?
I was just thinking... We don't export any of the Sendmail variables into
the filter_helo() code:
O Milter.macros.helo={tls_version}, {cipher}, {cipher_bits},
{cert_subject}, {cert_issuer}
What to do about that?
-Philip
___
NOTE: If there is a dis
On Tue, Jan 17, 2006 at 03:33:38PM -0800, Gary Funck wrote:
> OK, and what about the question raised as to how incoming mailers
> might react if, for example, tempfailed at HELO time, and related
> questions?
I asked that merely out of curiousity, since it's not common to reject
after HELO, so it'
Seems to be working:
Jan 17 08:10:01 mail sendmail[24471]: NOQUEUE: connect from
san-cust-208.57.14.2.mpowercom.net [208.57.14.2]
Jan 17 08:10:01 mail sendmail[24471]: AUTH: available mech=DIGEST-MD5
ANONYMOUS
CRAM-MD5, allowed mech=EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN
Jan 17 08:10:
David F. Skoll wrote:
(Btw, I've noticed that almost no patch submitters remember to update
the man pages! :-))
Not true! ;-)
I updated the man page, but that also included edits for changing
filter_sender(),
which I then had to back out...
-Philip
>
> Philip wanted an opportunity from MIMEDefang to change how Sendmail
> reacts to the HELO/EHLO command. Right now, you can't; you have to wait
> for MAIL FROM: to do anything based on the HELO argument.
>
OK, and what about the question raised as to how incoming mailers
might react if, for
Gary Funck wrote:
> I've kind of lost the thread here what is the
> recommended use for filter_helo?
Philip wanted an opportunity from MIMEDefang to change how Sendmail
reacts to the HELO/EHLO command. Right now, you can't; you have to wait
for MAIL FROM: to do anything based on the HELO ar
I've kind of lost the thread here what is the
recommended use for filter_helo?
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://w
Hi, Philip.
> Here's the patch again. I was hoping to get some answers about the
> set_dsn() stuff before posting...
Thanks! I believe set_dsn() will work in the HELO callback. I will
integrate your patch.
(Btw, I've noticed that almost no patch submitters remember to update
the man pages! :-
David F. Skoll wrote:
Not in filter_sender if we use your patch, unless we parse the
commands file manually.
If you re-work your patch to leave filter_sender as it was, I will
include it in the official release.
Here's the patch again. I was hoping to get some answers about the
set_dsn()
Jan Pieter Cornet wrote:
>Also, your code assumes you cannot call smfi_setreply in the helo()
>callback, but that assumption is wrong. At least, it is according to
>the milter API documentation. It's probably very useful to set a reply
>after HELO!
>
Ok, here are part of the revised diffs to mi
David F. Skoll wrote:
But it breaks existing filters; we need the helo arg back.
And there's a good reason to pass HELO in filter_sender (and
filter_recipient, for that matter): You may WANT to defer your
HELO processing until later. Our commercial products, for
example, let individual recipien
Philip Prindeville wrote:
>> But it breaks existing filters; we need the helo arg back.
>> And there's a good reason to pass HELO in filter_sender (and
>> filter_recipient, for that matter): You may WANT to defer your
>> HELO processing until later. Our commercial products, for
>> example, let in
Jan Pieter Cornet wrote:
Also, your code assumes you cannot call smfi_setreply in the helo()
callback, but that assumption is wrong. At least, it is according to
the milter API documentation. It's probably very useful to set a reply
after HELO!
Ok, here are part of the revised diffs to m
Philip Prindeville wrote:
> It was previously passed in filter_sender() because it wasn't
> available earlier (since obviously there was no support for
> "helos"). This was a design short-coming. And it's an attempt to
> KISS, by dividing and conquering the problem...
But it breaks existing filte
Jan Pieter Cornet wrote:
On Tue, Jan 17, 2006 at 02:15:25AM -0700, Philip Prindeville wrote:
Ok, some progress... I've installed the package, I'm running it currently.
Anyone have any comments on it?
Yes: why do you remove the HELO argument in filter_sender? This means
you're breaki
Philip Prindeville wrote:
> Anyone have any comments on it?
Looks OK except for one thing: You've removed the HELO argument
from filter_sender. We need to restore that; lots of people rely on it.
With that change, I will add the patch to the official release.
Regards,
David.
_
Philip Prindeville wrote:
> I was wondering about moving the:
>write_mx_command(data->cmdFD, 'E', (unsigned char *) data->heloArg);
> into the helo() function from envfrom() instead.
Won't work; you don't have a queue-ID yet.
--
David.
___
NOTE: I
Philip Prindeville wrote:
> Hmmm... I'm looking at MXRelayOK, MXSenderOK, MXRecipientOK, etc.
> and wondering about why there's duplication of both passing the same
> arguments again (ip, name, helo, etc)... As well as duplicating the
> validation logic for arguments...
Because the filter_relay
On Tue, Jan 17, 2006 at 02:15:25AM -0700, Philip Prindeville wrote:
> Ok, some progress... I've installed the package, I'm running it currently.
>
> Anyone have any comments on it?
Yes: why do you remove the HELO argument in filter_sender? This means
you're breaking compatibility for those who d
Ok, some progress... I've installed the package, I'm running it currently.
Anyone have any comments on it?
Thanks,
-Philip
--- examples/init-script.in.bak 2005-10-14 10:16:27.0 -0600
+++ examples/init-script.in 2006-01-17 00:58:34.0 -0700
@@ -39,16 +39,19 @@ [EMAIL PROTECTED]@
Quick question...
I was wondering about moving the:
write_mx_command(data->cmdFD, 'E', (unsigned char *) data->heloArg);
into the helo() function from envfrom() instead... but I'm not sure at
what point
the file is opened and can be written to... currently that happens in
envfrom()
too,
Working on adding filter_helo support...
Hmmm... I'm looking at MXRelayOK, MXSenderOK, MXRecipientOK, etc.
and wondering about why there's duplication of both passing the same
arguments
again (ip, name, helo, etc)... As well as duplicating the validation
logic for
arguments...
Inquiring min
23 matches
Mail list logo
