On 21 November 2019 07:11:43 CET, Viktor Dukhovni
wrote:
>Blocking mail by language risks false-positives and should be generally
>avoided, but it is not evil.
Blocking based on geolocation / domain endings is something I seriously despise.
Email is decentralized for a reason, blocking huge por
On Thu, Nov 21, 2019 at 06:42:15AM +0100, Reto wrote:
> Hm, didn't Germany learn its lesson yet somewhen in the 50s don't you
> think?
I don't think this is appropriate tone for the list[1]. Please refrain
from similar ad-hominem in the future. Blocking mail by language risks
false-positives an
On 21 November 2019 05:51:56 CET, merr...@fn.de wrote:
>We speak not Chinese, do you think if it is possible to reject all mails from
>China?
Apparently you also don't speak English properly. Do you want people to spam
block the full .de domain because of that?
Think hard before you block 1.5 b
We did get a lot of spam messages from Chinese providers. We speak not Chinese,
do you think if it is possible to reject all mails from China? Thanks
> On Nov 13, 2019, at 4:30 AM, Matus UHLAR - fantomas wrote:
>
> On 12.11.19 17:01, Viktor Dukhovni wrote:
>> The correct way to verify that would be to resolve the EHLO name to
>> an address, NOT to resolve the address to a name. This would then
>> find no anomalies with:
>>
>> Received:
> On Nov 20, 2019, at 12:38 PM, A. Schulze wrote:
>
>>> The SMTP daemon also enforces the message size limit independently.
>>> You can therefore specify different limits on the submission and
>>> port25 services.
>>>
>>> However, those limits cannot be larger than the limit that is
>>> enforced
Am 20.11.19 um 17:57 schrieb @lbutlr:
>> The SMTP daemon also enforces the message size limit independently.
>> You can therefore specify different limits on the submission and
>> port25 services.
>>
>> However, those limits cannot be larger than the limit that is
>> enforced by the cleanup daem
On 20 Nov 2019, at 08:16, Wietse Venema wrote:
> A. Schulze:
>> My goal is to allow different message size on MX and submission.
>> As message_size_limit is a cleanup option, this is my (non working) setup
>> based on http://www.postfix.org/BUILTIN_FILTER_README.html#mx_submission
> The SMTP daem
A. Schulze:
>
> Hello,
>
> My goal is to allow different message size on MX and submission.
> As message_size_limit is a cleanup option, this is my (non working) setup
> based on http://www.postfix.org/BUILTIN_FILTER_README.html#mx_submission
The SMTP daemon also enforces the message size limit
oh damn it...
i don't mean the MTA i think i mean MDA?
i would suggest to check MX-record or/and reply-to or/and SMTP mail from
so postfix can (maybe)probe only postmas...@doamin.tld and cache the result
Am 20.11.19 um 15:01 schrieb Wietse Venema:
Philipp Ewald:
BTW:
by reject_unverified_send
Hello,
My goal is to allow different message size on MX and submission.
As message_size_limit is a cleanup option, this is my (non working) setup
based on http://www.postfix.org/BUILTIN_FILTER_README.html#mx_submission
main.cf
message_size_limit = 512
master.cf
# define a sepa
Philipp Ewald:
> BTW:
> by reject_unverified_sender:
> would it not be better to check sending server? like accept connection
> on port 25 not whole sender? this way dont work with mailing list ( it
> would but its produce many mail probing)
That would be immensely stupid idea. First, there is n
Hi folks,
i have just installed postfix on Debian 10 and want to test "SMTP VRFY
Command"
i have noticed that postfix only probing a mail to vrfy the recipient.
Is there any another way as probing mail delivery?
at this point we use a custom script ( we want only "default-tools")
BTW:
by rej
:-)
Due to SPF restrictions I'm interested in SRS address rewriting. For
this purpose I'm using postsrsd (do you have any better solution?). The
recommended configuration of postsrsd is quite simple and as follows
(main.cf):
sender_canonical_maps = tcp:localhost:10001
sender_canonical_classe
[Sorry for late, Ralph.]
Ralph Seichter writes:
> * 황병희:
>
>> i did not setup SPF. Instead i think User-Agent/X-Mailer are
>> important.
>
> The contents of these headers are easily faked, so relying on them is
> questionable to me. Also, you will encounter User-Agent headers
> generated by vari
15 matches
Mail list logo