On 05/02/18 00:12, Viktor Dukhovni wrote:
>
>
>> On Feb 4, 2018, at 5:46 PM, J Doe wrote:
>>
>> Feb 4 15:05:46 server postfix/smptd[718]: warning: hostname
>> 1-2-3-4.dyn.isp.net does not resolve to address 1.2.3.4: Name or service not
>> known
>>
>> Does this mean that:
>>
>> 1. smtpd recei
On 2018-02-05 12:26, Allen Coates wrote:
> On 05/02/18 00:12, Viktor Dukhovni wrote:
>>
>>
>>> On Feb 4, 2018, at 5:46 PM, J Doe wrote:
>>>
>>> Feb 4 15:05:46 server postfix/smptd[718]: warning: hostname
>>> 1-2-3-4.dyn.isp.net does not resolve to address 1.2.3.4: Name or service
>>> not known
>
If you're using unbound as your local DNSSEC-validating
resolver and have enabled DANE, an issue is resolved in
unbound 1.6.8 where NSEC records for wildcards could be
misused for invalid denial-of-existence proofs. See:
https://medium.com/nlnetlabs/the-peculiar-case-of-nsec-processing-using
Hi list,
sorry for my belated reply.
First of all: thanks for the input to everyone suggesting where / what the
error may be.
What I tried so far:
1) reducing the MTU all the way down to 1400 - no change, error still persists.
2) sniffing the connection: nothing suspicious, one or two RST fl
> On Feb 5, 2018, at 12:04 PM, Niclas Rautenhaus
> wrote:
>
> What I tried so far:
Instead of blindly trying random changes that may only have unwanted
side-effects, collect the information needed to understand the problem.
What you have not yet tried is posting the complete logging for some
On Feb 5, 2018, at 05:26, Allen Coates wrote:
>
> Is this a reliable bad-host detector?
It is a very good indicator of spam. It is also an indicator of a misconfigured
mail server (in the case of spammers, intentionally so). Anyone kitting this
error on your postfix is going to be unable to se
Hi,
> Instead of blindly trying random changes that may only have unwanted
> side-effects, collect the information needed to understand the problem.
I did not change anything that I am not able to revert back to it's original
settings.
I am not "blindly trying random changes" but implementing
> On Feb 5, 2018, at 3:00 PM, Niclas Rautenhaus
> wrote:
>
> I did not change anything that I am not able to revert back to it's original
> settings.
> I am not "blindly trying random changes" but implementing suggestions being
> made in this
> thread and / or I found elsewhere online when I
> On Feb 5, 2018, at 3:16 PM, Viktor Dukhovni
> wrote:
>
> Note also that for this to be a meaningful mail archive, you should lose the
> original envelope recipient addresses (which happens with always_bcc) and
> instead use a recipe based on "recipient_bcc_maps" with regular expression
> map
> On Feb 5, 2018, at 3:16 PM, Viktor Dukhovni
> wrote:
>
> One thing that is interesting is that the message generates two BCC
> copies with the *same* recipient address:
>
> Feb 5 17:28:51 mail postfix/smtp[22771]: 363BD601EE:
> to=,
> relay=192.168.1.23[192.168.1.23]:1025, delay=0.1,
> One thing that is interesting is that the message generates two BCC
> copies with the *same* recipient address:
This is *only* the case with mails that later get deferred. Messages that are
sucessfully sent to the appliance that archives the mails are only logged once,
with the status "sent"
> f it is "always_bcc" you have for now,
> then you should indeed enable it only on the far side of the content filter,
> which amounts to:
>
> -o receive_override_options=no_address_mappings
This was one of the things I already tried without resolving the issue, as
stated in my feedback mail
> On Feb 5, 2018, at 4:28 PM, Niclas Rautenhaus
> wrote:
>
>> One thing that is interesting is that the message generates two BCC
>> copies with the *same* recipient address:
>
> This is *only* the case with mails that later get deferred. Messages that are
> sucessfully sent to the appliance
> On Feb 5, 2018, at 4:38 PM, Niclas Rautenhaus
> wrote:
>
> This was one of the things I already tried without resolving the issue, as
> stated in my feedback mai
Show evidence of this in logs. The resulting messages should have only one
archive recipient. Are these also deferred. Also,
"@lbutlr" writes:
> On 1 Feb 2018, at 22:39, Olivier wrote:
>> A failing connection:AMTP authentication:
>> Jan 29 16:44:57 fbsd63 postfix/smtpd[93113]: connect from
>> unknown[118.174.201.202]
>
>
>> A successful SMTP authentication
>>
>> Jan 30 17:52:38 fbsd63 postfix/smtpd[15674]: connect f
"@lbutlr" writes:
> On 1 Feb 2018, at 21:31, Olivier olivier.nic...@cs.ait.ac.th> wrote:
>> Is that a know problem? Is there a fix?
>
> It is not. I have a postfix 3.2 install and primary use Macs to access it.
> Works fine one new and old accounts.
>
> However, this sounds like a dovecot issue,
Viktor Dukhovni writes:
>> On Feb 2, 2018, at 12:39 AM, Olivier wrote:
>>
>>> You've also not explained what you mean by deleting and recreating the
>>> account.
>>
>> I am not a Mac user, but from the Mail app, select Files/Account and
>> remove the account that makes problem and recreate it
Hello
Last week I had problems with my mail server but now everything
has settled again. I have in my logs now the following error
message that I do not understand. As I've seen, this has
already been discussed a few times.
Please, how do I tackle this or how can I solve this!?
[Mail.log]
Viktor Dukhovni writes:
>> On Feb 3, 2018, at 1:21 PM, Karol Augustin wrote:
>>
>> I have few people connecting using Macs. I had similar issue when I
>> upgraded libssl to 1.1.0f-4 all of them couldn't connect as they are
>> still using TLS 1.0. I had to temporarily downgrade to 1.1.0f-3 until
19 matches
Mail list logo
