On 04.08.17 15:28, Fazzina, Angelo wrote:
When the limit is exceeded should the sender receive a bounce back email ?
postfix rejects additional recipients with temporary error, which means
that the client should retry those.
Proper SMTP clients retry remaining recipients until mail is sent to a
On 8/4/2017 10:12 AM, Fazzina, Angelo wrote:
> Thank you. I see it maybe me doing the limiting
>
> smtpd_recipient_limit (default: 1000)
>
> The maximal number of recipients that the Postfix SMTP server accepts per
> message delivery request.
>
>
>
> Q1 = So, can I assume it does not mat
Hi,
When the limit is exceeded should the sender receive a bounce back email ?
You say "find the error" is that the error you are talking about ?
To me it's sounding like I should ask sender to send emails with less than 1000
recipients and limit will not hit.
It's too bad there is no way to know
On Fri, Aug 04, 2017 at 03:12:16PM +, Fazzina, Angelo wrote:
> Thank you. I see it maybe me doing the limiting
> smtpd_recipient_limit (default: 1000)
> The maximal number of recipients that the Postfix SMTP server accepts per
> message delivery request.
> Q1 = So, can I assume it does no
Thank you. I see it maybe me doing the limiting
smtpd_recipient_limit (default: 1000)
The maximal number of recipients that the Postfix SMTP server accepts per
message delivery request.
Q1 = So, can I assume it does not matter if the recipients are in the TO, CC,
or BCC field, the hard
On Fri, Aug 04, 2017 at 02:29:00PM +, Fazzina, Angelo wrote:
> Did my postfix instance limit the number of recipients in the email that was
> sent ?
Yes, it restricts the amount of recipients to the number given. Your
client needs to do another mail transaction with the remaining
recipients.
Isn't Systemd a RHEL 7 thing ?
I think I run rsyslog.
[root@mail5 home]# ps -ef |grep sys
root 1522 1 0 Jul11 ?00:01:36 /sbin/rsyslogd -i
/var/run/syslogd.pid -c 5
dbus 1537 1 0 Jul11 ?00:00:00 dbus-daemon --system
root 30400 26453 0 10:51 pts/000:00:
Fazzina, Angelo:
> Hi,
>
> Did my postfix instance limit the number of recipients in the email
> that was sent ?
If you're missing recipients in the log, then that may be the result
of unhelpful systemd rate limiting. Systemd is not part of Postfix.
The Postfix scheduler has some safety features
Hi,
Did my postfix instance limit the number of recipients in the email that was
sent ?
I was reading this at this link http://www.postfix.org/postconf.5.html
default_extra_recipient_limit (default: 1000)
The default value for the extra per-transport limit imposed on the number of
in-memory
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).
On 03.08.17 17:04, Martin Jiřička wrote:
Hmm, I am not server administrator by profession, so maybe I do not
On 4/8/2017 1:59 μμ, Alex JOST wrote:
Dovecot needs to know about the user. What does 'doveadm user -u
imaptes...@noa.gr' print?
Thank you Alex,
I just found the problem. After switching to LMTP, Dovecot receives from
Postfix a fully qualified username, whereas with LDA it was receiving a
'
Am 04.08.2017 um 11:37 schrieb Nikolaos Milas:
Hello,
I am setting up a new box with Postfix 3.2.2 and Dovecot.
Until now I have been using LDA delivery successfully. On the new server
LDA setup works fine too, but I am considering to move to LMTP.
IMPORTANT NOTE: It is important in my setup
> It seems natural (for me at least) to introduce a new map type
> dnsbl: that maps those IP addresses to an action.
That would be amazing! If I get it right this would also deprecate
e.g. `reject_rhsbl_client` and `reject_rbl_client`. As a Postfix
novice I would appreciate the reduction of config
Hello,
I am setting up a new box with Postfix 3.2.2 and Dovecot.
Until now I have been using LDA delivery successfully. On the new server
LDA setup works fine too, but I am considering to move to LMTP.
IMPORTANT NOTE: It is important in my setup to keep functional all
virtual_alias_maps & vi
Hi
Just saw this comment in the HISTORY file and noticed that the original
and replaced values look just the same.
20170704
Typos (introduced: Postfix 2.10): in comments about
IPv4-in-IPv6 addresses, replace :::1.2.3.4 with the
correct form :::1.2.3.4. Incorrect o
> 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 h
16 matches
Mail list logo