On Thu, Aug 03, 2017 at 12:19:55PM +0530, hyndavirap...@bel.co.in wrote:
> > He's not posted the configuration of the sending system or
> > its logs. This is a waste of everyone's time.
The relevant logging is the TLS-related logging from the sending
postfix/smtp client process that happens *bef
Martin Ji?i?ka:
> > Did you mean: reject_rhsbl_sender (i.e. reject the sender domain)?
> > That already exists.
>
> The `reject_rhsbl_sender` checks whether MAIL FROM domain is listed
> under rbl_domain. And I would like to have `reject_rbl_sender` that
> would check whether reversed sender domain
> I'm not talking about DNS lookups, but about DNSBL lookups.
Yes, I did interchanged them, pardon.
> You ask each dnsbl for client IP, now you will ask them for each A or MX
> record. That means, number of DNSBL lookups will increase ad least two times
> (for each dnsbl you already query).
Hmm,
Doing it on MX would require dnsbl lookups for each MX server in all
received mail.
That would massively increase amount of dnsbl lookups.
On 03.08.17 13:38, Martin Jiřička wrote:
I do not know if I would call it "massively". I already do
`reject_unknown_client_hostname` check and 4 other dnsbl
Am 03.08.2017 um 07:32 schrieb Tomas Macek:
I'm trying to get to know, if there is a chance to see in Milter that the
"NOTIFY=xxx,yyy,zzz" was specified by a client at rcpt to command
On Thu, 3 Aug 2017, A. Schulze wrote:
from the milter API Doku:
xxfi_envrcpt:
ctx Opaque context struct
> Did you mean: reject_rhsbl_sender (i.e. reject the sender domain)?
> That already exists.
The `reject_rhsbl_sender` checks whether MAIL FROM domain is listed
under rbl_domain. And I would like to have `reject_rbl_sender` that
would check whether reversed sender domain is listed under rbl_domain.
Martin Ji?i?ka:
> Hi,
>
> why there is no `reject_rbl_sender` restriction?
Did you mean: reject_rhsbl_sender (i.e. reject the sender domain)?
That already exists.
Wietse
On Thu, 3 Aug 2017, A. Schulze wrote:
Am 03.08.2017 um 07:32 schrieb Tomas Macek:
I'm trying to get to know, if there is a chance to see in Milter that the
"NOTIFY=xxx,yyy,zzz" was specified by a client at rcpt to command
Hello Tomas,
from the milter API Doku:
xxfi_envrcpt:
ctxOpaq
On 03/08/17 11:55, Matus UHLAR - fantomas wrote:
> You apparently mean something like check_sender_mx_access (reject when MX
> server of sending domain points to blacklisted IP) or maybe
> check_sender_a_access (similar), but with dnsbl lookups.
>
> Doing it on MX would require dnsbl lookups for ea
> Doing it on MX would require dnsbl lookups for each MX server in all
> received mail.
> That would massively increase amount of dnsbl lookups.
I do not know if I would call it "massively". I already do
`reject_unknown_client_hostname` check and 4 other dnsbl lookups. So I
would do another 2 in a
On 03.08.17 11:07, Martin Jiřička wrote:
why there is no `reject_rbl_sender` restriction? It probably does not
make so much sense as `reject_rbl_client`, but it would help me in my
spam battle. Quite a lot of emails come from servers not listed inside
Spamhause blacklists, but sender's domain poi
For a while I tried a local black-list based on the senders of bounced
emails. It was deployed using "check_sender_access ".
Using the whole email address didn't work - I never sawthe same sender
twice;
and using just the domain part gave me more false positives than true.
A more targeted list, c
Am 03.08.2017 um 07:32 schrieb Tomas Macek:
> I'm trying to get to know, if there is a chance to see in Milter that the
> "NOTIFY=xxx,yyy,zzz" was specified by a client at rcpt to command
Hello Tomas,
from the milter API Doku:
xxfi_envrcpt:
ctx Opaque context structure.
argv Null-term
Hi,
why there is no `reject_rbl_sender` restriction? It probably does not
make so much sense as `reject_rbl_client`, but it would help me in my
spam battle. Quite a lot of emails come from servers not listed inside
Spamhause blacklists, but sender's domain points to blacklisted IP.
For example ye
Am 02.08.2017 um 12:59 schrieb Wietse Venema:
> Why mess with NDRs, when you could reduce the intensity of the flow
> to the mbox servers?
>
As usual thanks to Wietse for putting me in the right direction. :-)
It was not the amount of msg but the message size itself which was
problematic.
My si
15 matches
Mail list logo