Re: disable receiving for particular email

[Poliman - Serwis]

Ok, if all solutions are even to each other I will choose one.

2017-10-27 16:08 GMT+02:00 Matus UHLAR - fantomas :

> On 23.10.17 15:35, Poliman - Serwis wrote:
>
>> Thank you for a lot of answers. Could you tell me how would you resolve
>> the
>> problem?
>>
>
> we already told you how would we resolve it.
> we gave you a better solutions to choose from, but the choice is up to you.
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> "To Boot or not to Boot, that's the question." [WD1270 Caviar]
>



-- 

*Pozdrawiam / Best Regards*
*Piotr Bracha*

Re: unable to send email to hotmail.com domain

[Poliman - Serwis]

Hmm, you know... Contact in any case with the Microsoft was pain in ass
many times. Second thing better do some "backup way" if contacting with ms
support do nothing like almost all time. Now I am really surprised, because
they answer (wow!), they answer in short time (WOW!) and it was positive
answer which resolved some problem (INSANE WOW!). That's all. In my earlier
post I put the link to form, which can help in similar problems to mine.

2017-10-27 18:01 GMT+02:00 /dev/rob0 :

> On Thu, Oct 26, 2017 at 12:33:03PM +0200, Poliman - Serwis wrote:
> > I know that MS has own black list but why they block me.
>
> There is exactly one place which can answer that question, and it's
> *NOT* the postfix-users mailing list!
>
> If Microsoft is blocking you, ASK MICROSOFT for help.
>
> Recently (June) I helped someone with the same problem.  Microsoft
> postmaster was contacted, a human replied, and the IP address was
> removed from their blacklist.
>
> Seriously ... why did no one else suggest this?  Even if, as one
> might imagine, they didn't care enough to reply (as is the case at
> Google and other large receivers), Microsoft really is the only
> reasonable one to ask about this.
>
> #include 
> --
>   http://rob0.nodns4.us/
>   Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
>



-- 

*Pozdrawiam / Best Regards*
*Piotr Bracha*

Re: Question about default_destination_concurrency_limit

[J Doe]

Hi Viktor,

> On Oct 30, 2017, at 12:11 AM, Viktor Dukhovni  
> wrote:
> 
>> I had a question regarding the main.cf parameter 
>> “default_destination_concurrency_limit”.  The man page (man 5 postconf), 
>> states it is: “The default maximal number of parallel deliveries to the same 
>> destination.”
> 
> Correct.
> 
>> and that this applies to the smtp(8) delivery agent.
> 
> It states no such thing, and indeed this is not the case.

Oh, perhaps I am mistaken.  When I look at that parameter using: 
http://www.postfix.org/postconf.5.html

...it states: “This is the default limit for delivery via the lmtp(8), pipe(8), 
smtp(8)and virtual(8) delivery agents.”

>> This got me wondering . . . how would one adjust this parameter ?  I am 
>> thinking it is only
>> through benchmarking trial and error, as a number of factors would seem to 
>> affect this
>> (server load, bandwidth, etc.).  But then I was thinking if it was through 
>> trial and error,
>> how was the value of “20” determined when most people running Postfix will 
>> have varying
>> equipment for their server? [1]
> 
> This parameter much less about your server's capacity that it is about
> not overwhelming remote servers with too many parallel connections.
> It should, for a transport that handles deliveries to many destinations,
> of course not consume the entire transport process limit, which as
> specified with default_process_limit or the corresponding master.cf
> entry.  The latter defaults to 100, so 20 is a reasonable fraction
> that does not result in any single destination hogging all the
> transport slots.

Ah, I see.

Thanks for your reply,

- J

Re: Question about default_destination_concurrency_limit

[Viktor Dukhovni]

> On Oct 29, 2017, at 9:40 PM, J Doe  wrote:
> 
> I had a question regarding the main.cf parameter 
> “default_destination_concurrency_limit”.  The man page (man 5 postconf), 
> states it is: “The default maximal number of parallel deliveries to the same 
> destination.”

Correct.

> and that this applies to the smtp(8) delivery agent.

It states no such thing, and indeed this is not the case.

> This got me wondering . . . how would one adjust this parameter ?  I am 
> thinking it is only
> through benchmarking trial and error, as a number of factors would seem to 
> affect this
> (server load, bandwidth, etc.).  But then I was thinking if it was through 
> trial and error,
> how was the value of “20” determined when most people running Postfix will 
> have varying
> equipment for their server? [1]

This parameter much less about your server's capacity that it is about
not overwhelming remote servers with too many parallel connections.
It should, for a transport that handles deliveries to many destinations,
of course not consume the entire transport process limit, which as
specified with default_process_limit or the corresponding master.cf
entry.  The latter defaults to 100, so 20 is a reasonable fraction
that does not result in any single destination hogging all the
transport slots.

-- 
Viktor.

Question about default_destination_concurrency_limit

[J Doe]

Hi,

I had a question regarding the main.cf parameter 
“default_destination_concurrency_limit”.  The man page (man 5 postconf), states 
it is: “The default maximal number of parallel deliveries to the same 
destination.” and that this applies to the smtp(8) delivery agent.

This got me wondering . . . how would one adjust this parameter ?  I am 
thinking it is only through benchmarking trial and error, as a number of 
factors would seem to affect this (server load, bandwidth, etc.).  But then I 
was thinking if it was through trial and error, how was the value of “20” 
determined when most people running Postfix will have varying equipment for 
their server ? [1]

Thanks,

- J

[1] I ask this as there a couple of other parameters in the main.cf config file 
that seem to fall into this category and I am wondering if there is a more 
efficient method of determining the values for my server or whether the 
solution is also through trial and error.

Re: directing logs to remote syslog with any local syslog instance

[Bill Cole]

On 29 Oct 2017, at 17:22 (-0400), zhong ming wu wrote:


Hello,
I had successfully used postfix for years and now I am trying to 
recreate
postfix clusters in docker and in particular interested in how I can 
direct

all postfix logs from a container to other places.

I do not find in postfix configuration how one can achieve this 
without any
local syslog daemon.  Can someone please confirm that it's not 
possible to
capture postfix logs without the assistance of any local syslog 
daemon?
If so, can I put a feature request to be able to adjust which syslog 
server
postfix logs to as well as ability for postfix to log to 
stdout/stderr.
the spirit of the docker container is that one is supposed to have 
only one
software running in it and it will be nice if we do not have to 
maintain
any syslog instance in the container.  My plan is to run syslog in 
another

container and have postfix send all logs there.
Thanks
mr wu


Using the Docker "syslog" log-driver you can direct syslog messages from 
a container to an arbitrary IP & port number.


See https://docs.docker.com/engine/admin/logging/syslog/#usage


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole

Postfix stable release 3.2.4, and legacy releases 3.1.7 and 3.0.11

[Wietse Venema]

[An on-line version of this announcement will be available at
http://www.postfix.org/announcements/postfix-3.2.4.html]

This announcement concerns fixes for problems that were introduced
with Postfix 3.0 and later. Older supported releases are unaffected.

Fixed in Postfix 3.1 and later:

  * DANE interoperability. Postfix builds with OpenSSL 1.0.0 or
1.0.1 failed to send email to some sites with "TLSA 2 X X" DNS
records associated with an intermediate CA certificate. Problem
report and initial fix by Erwan Legrand.

Fixed in Postfix 3.0 and later:

  * Missing dynamicmaps support in the Postfix sendmail command.
This broke authorized_submit_users settings that use a
dynamically-loaded map type. Problem reported by Ulrich Zehl.

You can find the updated Postfix source code at the mirrors listed
at http://www.postfix.org/.

Wietse

directing logs to remote syslog with any local syslog instance

[zhong ming wu]

Hello,
I had successfully used postfix for years and now I am trying to recreate
postfix clusters in docker and in particular interested in how I can direct
all postfix logs from a container to other places.

I do not find in postfix configuration how one can achieve this without any
local syslog daemon.  Can someone please confirm that it's not possible to
capture postfix logs without the assistance of any local syslog daemon?
If so, can I put a feature request to be able to adjust which syslog server
postfix logs to as well as ability for postfix to log to stdout/stderr.
the spirit of the docker container is that one is supposed to have only one
software running in it and it will be nice if we do not have to maintain
any syslog instance in the container.  My plan is to run syslog in another
container and have postfix send all logs there.
Thanks
mr wu

Re: Question about logging mismatched DNS in submission server

[/dev/rob0]

On Sun, Oct 29, 2017 at 07:28:24AM +, MRob wrote:
> Lately it looks like some zombie bot farm is connecting to 
> submission (and looks to do nothing except connect), causing many 
> of these in the logs:
> 
> Oct 28 06:15:35 mail postfix/smtpd[12941]: warning: hostname
> x.y.z does not resolve to address 11.22.33.44: Name or service
> not known

BTW there is absolutely no need to mung such logs.  Who are you 
trying to protect?  Also, if this is in fact on submission, why is 
there no " -o syslog_name=postfix/submission" override to help 
distinguish submission from smtp?
 
> For submission service where clients often connect from dynamic IP 
> address ranges, maybe seeing these is not important - just noise, 
> so I am curious about why postfix is logging this. Does this mean 
> client is somehow attempting to send before (without) doing any 
> AUTH? I tested by hand and MAIL FROM result is "530 5.7.0 Must 
> issue a STARTTLS command first". I found that I neglected to 
> override smtpd_sender_restrictions in the submission service, but 
> it shouldn't matter if the client cant AUTH, right?
> 
> Or is it default postfix behavior and I can ignore these logs?

TL;DR yes, ignore these.

Postfix smtpd(8) by default looks up the PTR for every connecting 
client address, and then tries to validate that PTR with an A/ 
lookup of the hostname value.  Your example failed in validation; 
"x.y.z./IN/A" (or ) lookup had an error.

You can disable these reverse DNS lookups, and specifically only for
submission, but that's probably not desirable, because then every 
Received: header in submission would show "unknown[ip.add.re.ss]".

The reason for logging is that Postfix logs every error condition.
The same smtpd code which listens on submission is also listening on 
port 25, and there, wonky lookup results are likely to indicate a 
problem of some kind.

Best bet is to just leave the defaults in place and perhaps do 
filtering when reading logs, to avoid the entries you do not 
care/need to see.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: Question about logging mismatched DNS in submission server

[Wietse Venema]

MRob:
> Lately it looks like some zombie bot farm is connecting to submission 
> (and looks to do nothing except connect), causing many of these in the 
> logs:
> 
> Oct 28 06:15:35 mail postfix/smtpd[12941]: warning: hostname x.y.z does 
> not resolve to address 11.22.33.44: Name or service not known

This is logged because it affects name-based Postfix features such
as check_client_access, check_client_ns_access and so on. Without
such logging, trouble shooting after-the-fact would be harder.

Instead, Postfix could log 

warning: client hostname unavailable for check_client_access:
hostname x.y.z does not resolve to address 11.22.33.44: Name
or service not known

And that would be logged for each affected feature, i.e. multiple
times per SMTP session.

If the presence of the line in the logfile bothers you: use grep.

Wietse

Re: Question about logging mismatched DNS in submission server

[Bill Cole]

On 29 Oct 2017, at 3:28 (-0400), MRob wrote:

Lately it looks like some zombie bot farm is connecting to submission 
(and looks to do nothing except connect), causing many of these in the 
logs:


Oct 28 06:15:35 mail postfix/smtpd[12941]: warning: hostname x.y.z 
does not resolve to address 11.22.33.44: Name or service not known


For submission service where clients often connect from dynamic IP 
address ranges, maybe seeing these is not important - just noise, so I 
am curious about why postfix is logging this. Does this mean client is 
somehow attempting to send before (without) doing any AUTH?


No. It means that the PTR record in DNS for that IP address resolves to 
a name that does not have an A (or CNAME+A) record resolving it back to 
the same IP. Not really a major issue.


I tested by hand and MAIL FROM result is "530 5.7.0 Must issue a 
STARTTLS command first". I found that I neglected to override 
smtpd_sender_restrictions in the submission service, but it shouldn't 
matter if the client cant AUTH, right?


Right.


Or is it default postfix behavior and I can ignore these logs?


Yes. Note that this is a warning only. It's an indication that parties 
in control of the reverse DNS for the IP address and the forward DNS for 
the name it resolves to are not cooperating with each other in a useful 
way at the moment. Maybe bad luck (something out of their control is 
making YOU see the name->IP resolution fail,) maybe carelessness or 
incompetence, maybe a lame attempt by a spammer to misdirect blame. It 
is slightly more likely that mail offered on such a connection is in 
some way illegitimate, but not to a useful degree. For example: nearly 
all of the connections I've see with such warnings this week either were 
to impatient to get past postscreen's 6-second delay OR were blacklisted 
widely enough to die in postscreen OR ultimately delivered perfectly 
legitimate & wanted email.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole

Question about logging mismatched DNS in submission server

[MRob]

Lately it looks like some zombie bot farm is connecting to submission 
(and looks to do nothing except connect), causing many of these in the 
logs:


Oct 28 06:15:35 mail postfix/smtpd[12941]: warning: hostname x.y.z does 
not resolve to address 11.22.33.44: Name or service not known


For submission service where clients often connect from dynamic IP 
address ranges, maybe seeing these is not important - just noise, so I 
am curious about why postfix is logging this. Does this mean client is 
somehow attempting to send before (without) doing any AUTH? I tested by 
hand and MAIL FROM result is "530 5.7.0 Must issue a STARTTLS command 
first". I found that I neglected to override smtpd_sender_restrictions 
in the submission service, but it shouldn't matter if the client cant 
AUTH, right?


Or is it default postfix behavior and I can ignore these logs?