Postings by mailing list subscriber

Re: retry 5xx using a fallback outgoing IP

the primary mx is not refusing *me* the postifx box, it's refusing connections initiated by me from one of the two IP address.

Do the RFCs handle such cases? (fallback to a different smtp_bind_address)

Does postfix have some round-robin or fallback choice of smtp_bind_address?

Re: retry 5xx using a fallback outgoing IP

that is what I am doing right now & waiting for an answer from ISP for request to allocate a different, «clean» reputation IP address.

Re: retry 5xx using a fallback outgoing IP

I'm sorry but I fail to understand what value is your acid question bringing to the conversation.

FWIW, Mathus, the remote side is simply printing a 5xx one line message "not accepted" banner instead of the expected welcome 220 banner, not giving any explanation to why, then closing the tcp session, without postfix even getting a chance to say HELO!

However, the topic of this thread is: Can postfix retry a failed message, by attempting to retransmit using a different outgoing IP address of the machine it's running on?

If I send a mail to the same destination using the old IP ad

retry 5xx using a fallback outgoing IP

I've already asked them that.

My question is can postfix retry a failed delivery using another smtp_bind_address than the first tried and failed one?

Re: retry 5xx using a fallback outgoing IP

no, it's statically configured

retry 5xx using a fallback outgoing IP

My small office client upgraded his internet connection and I've updated the self hosted postfix configuration file with the new IP address.

Soon after, email users began complaining about bounces they started receiving for some emails they sent.

After examining logs I've concluded that the newly IP was reused from another client and it is listed in few rbl.

extended ascii codes in rfc822-formatted message?

I have accidentally learned that a postfix server has accepted and
attempted to deliver an email with the envelope sender containing 8 bit
ascii codes (it looks like this T\▒\▒ ... at domain dot tld - that's a backslash and
then ascii extended code 177). the imap backend - an old cyrus lmtp service
- has refused the delivery.

what rfc defines this?

collection of methods for bypassing/whitelisting of header_checks rules

Every now and then people ask for ways to skip some or all checks defined
in header_checks done by the cleanup daemon, then they learn[1] that due to
postifx design they must figure out workarounds or use external filters.

For example, some want to prevent legitimate users' outgoing mail from
being checked against header_checks or to be checked against a relaxed set
of checks[2]; in this case a solution is either to configure the submission
smtpd daemon with "-o receive_override_options=no_header_body_checks" in or setup an additional postfix instance dedicated to handle email

strange body_checks pcre match

I have this body_checks in a postmulti(1) setup:

root@mailhost:~# grep 200 /etc/postfix-in/body_exceptions_pcre
#body checks error codes 200-299
/^.*((primesti|primiti|primit) acest (mesaj|email|mail|e-mail)
(deoarece|din cauza|pentru ca|in urma inscrierii)|(you are
receiving.*because)).*/ REJECT Error processing your message -
non-business related content (internal error code 200)

postconf -n pasted here because is long:
<a href="" title=""></a>

cleanup(8) log pasted here because of privacy (it contains some
telephone numbers)
<a href="" title=""></a>

I re-read pcre, cleanup and body_

soft_bounce=yes in postmulti setup

I have two issues.
After hard reading of MULTI_INSTANCE_README I've come to a setup as below.
I've been so far satisfied with achieving splitting postfix-2.9.3
(ubuntu 12.04 amd64) into incoming mail, submission and delivery to
cyrus. Just before switching old box with new one, I have enabled
soft_bounce = yes. The mail delivery was interrupted for a couple of
hours, so incoming mail hit my isp backed-up mx during this time, to
which I connected and manually issued an ETRN.

It seems however that once deliveries started, logfiles show 5xx
rejects instead of expected 4xx.

clarification about missing LMTP_README file

Ok, this¹ has been raised over a few times in the past, but I'm not
satisfied with the answer (referral to man page of lmtp/smtp instead
of idiot-proof narrative version like other *_README howtos).
1. Do the cached file contents still apply to current release version
of postfix?
2. If yes, why is it retired/not present as
<a href="" title=""></a>?
3. If not, why isn't there the updated version?

² <a href="" title=""></a>