On 14/01/2020 21:59, Bill Cole wrote:
>> Beginning to get a little confused ...
>
> I can understand why.
>
> Is it certain that the macro you want is non-null when you're asking for it?
I will post a minimal C reproducer some time later hopefully.
As a summary, another quick illustration of
On 14 Jan 2020, at 15:16, David Bürgin wrote:
I have reproduced this both with an independent milter application and
with the Postfix test-milter program. Are you sure MIMEDefang uses the
libmilter API?
Absolutely certain.
It isn’t a pure Perl milter implementation?
No. The core
David B?rgin:
> On 14/01/2020 20:48, Wietse Venema wrote:
> >> test-milter confirms that smfi_setsymlist does not work:
> >>
> >> $ test-milter -v -p inet:3000@localhost -m connect -M
> >> '{client_connections}'
> >> set symbol list connect to "{client_connections}"
> >> negotiate
On 14/01/2020 20:31, Bill Cole wrote:
> I can confirm that a milter absolutely can request and receive macros from
> postfix, PROVIDED those macros are available. I use the MIMEDefang milter,
> which optionally uses smfi_setsymlist() to request macros and includes
> options to ask for specific
On 14/01/2020 20:48, Wietse Venema wrote:
>> test-milter confirms that smfi_setsymlist does not work:
>>
>> $ test-milter -v -p inet:3000@localhost -m connect -M
>> '{client_connections}'
>> set symbol list connect to "{client_connections}"
>> negotiate f0=1ff *pf0 = 1ff f1=1f
David B?rgin:
> On 14/01/2020 19:39, Wietse Venema wrote:
> >>>unsigned long *pf3)
> >>> {
> >>> if (set_macro_list) {
> >>> if (verbose)
> >>> printf("set symbol list %s to \"%s\"\n",
> >>>
On 14 Jan 2020, at 12:40, David Bürgin wrote:
smfi_setsymlist would be a useful function to have, because it lets
milter applications request the macros they need for operation
themselves. Just recently there was a thread on this list where
someone
struggled to set up the required macros for
On 14/01/2020 19:39, Wietse Venema wrote:
>>>unsigned long *pf3)
>>> {
>>> if (set_macro_list) {
>>> if (verbose)
>>> printf("set symbol list %s to \"%s\"\n",
>>>macro_states[set_macro_state], set_macro_list);
>>>
David B?rgin:
> Wietse,
>
> On 14/01/2020 18:58, Wietse Venema wrote:
> > smfi_setsymlist() is called by test_negotiate():
> >
> > static sfsistat test_negotiate(SMFICTX *ctx,
> >unsigned long f0,
..
> >unsigned long
Wietse,
On 14/01/2020 18:58, Wietse Venema wrote:
> smfi_setsymlist() is called by test_negotiate():
>
> static sfsistat test_negotiate(SMFICTX *ctx,
>unsigned long f0,
>unsigned long f1,
>
rdquiterio wrote:
> I've been using postfix for several years as a relay but never used it to
> restrict inbound mail, since it is done by an anti-spam appliance.
>
> But now, we need to implement an inbound rule like this:
If inbound mail is already restricted by an anti-spam appliance then
David B?rgin:
> On 14/01/2020 18:22, Wietse Venema wrote:
> >> In section ?What macros will Postfix send to Milters??, MILTER_README
> >> says:
> >>
> >>> As of Sendmail 8.14.0, Milter applications can specify what macros
> >>> they want to receive at different Milter protocol stages. An
> >>>
On 14/01/2020 18:22, Wietse Venema wrote:
>> In section ?What macros will Postfix send to Milters??, MILTER_README
>> says:
>>
>>> As of Sendmail 8.14.0, Milter applications can specify what macros
>>> they want to receive at different Milter protocol stages. An
>>> application-specified list
I already did it, but I will try once more.
Thanks anyway. :)
--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
David B?rgin:
> In section ?What macros will Postfix send to Milters??, MILTER_README
> says:
>
> > As of Sendmail 8.14.0, Milter applications can specify what macros
> > they want to receive at different Milter protocol stages. An
> > application-specified list takes precedence over a
In section ‘What macros will Postfix send to Milters?’, MILTER_README
says:
> As of Sendmail 8.14.0, Milter applications can specify what macros
> they want to receive at different Milter protocol stages. An
> application-specified list takes precedence over a Postfix-specified
> list.
This
On Tue, 14 Jan 2020 at 12:53, Scott Kitterman wrote:
> On Tuesday, January 14, 2020 7:39:05 AM EST Emanuel wrote:
> > Hello everyone.!
> >
> > I see this error in the postfix logs:
> >
> > said: 550 Blocked by SPF () (in reply to MAIL FROM command))
> >
> > Jan 14 09:31:46 antartida
Hi,
relay=mail.aylendepartamentos.com.ar[200.58.120.110]:25, delay=1.8,
delays=1.6/0/0.17/0, dsn=4.0.0, status=SOFTBOUNCE (host
mail.aylendepartamentos.com.ar[200.58.120.110] said: 550 Blocked by SPF
It's not your postfix complaining.
Your postfix tries to deliver to 200.58.120.110 and
On Tuesday, January 14, 2020 7:39:05 AM EST Emanuel wrote:
> Hello everyone.!
>
> I see this error in the postfix logs:
>
> said: 550 Blocked by SPF () (in reply to MAIL FROM command))
>
> Jan 14 09:31:46 antartida postfix/smtpd[16086]: 9248680010:
>
Hello everyone.!
I see this error in the postfix logs:
said: 550 Blocked by SPF () (in reply to MAIL FROM command))
Jan 14 09:31:46 antartida postfix/smtpd[16086]: 9248680010:
client=a48-146.smtp-out.amazonses.com[54.240.48.146]
Jan 14 09:31:46 antartida postfix/cleanup[16162]: 9248680010:
rdquiterio:
> Hi;
>
> I've been using postfix for several years as a relay but never used it to
> restrict inbound mail, since it is done by an anti-spam appliance.
>
> But now, we need to implement an inbound rule like this:
>
> 1. Everybody on our domain should be allowed to receive email
Hi;
I've been using postfix for several years as a relay but never used it to
restrict inbound mail, since it is done by an anti-spam appliance.
But now, we need to implement an inbound rule like this:
1. Everybody on our domain should be allowed to receive email form a
specific sender
Hello,
Now I have notices inconsistency:
On 10.01.20 12:42, Simon B wrote:
For as long as I can I remember, I have blocked connections purporting
to be my own domain/IP address using a postmapped file called
helo_checks.
[...]
Since upgrading to 2.11 yesterday (yes, I am on a path to move
23 matches
Mail list logo
