On 07/04/2022 17:55, Pedro David Marco wrote:
Probably i am misunderstanding Postfix documentation but... What is exactly the
Postfix criteria about using smtp_fallback_relay
I also had an issue with this some time ago, which I didn't understand.
At the time I had set the fal
Understood!
Thanks a lot Wietse and Viktor!
Tete.
On Thursday, April 7, 2022, 08:03:36 PM GMT+2, Wietse Venema
wrote:
Pedro David Marco:
> Sorry, but i am confused... documentation is accurate, but probably
> not my understading of it...
Instead of arguing about what happens, look in y
le" destination, and
> hence, smtp_fallback_relaytakes place...? ?my understanding was that
> unreacahble meant "cannot connect to remote smtp port"...
The text is based on a very early Postfix implementation. The text
should be updated: smtp_fallback_relay is now used when (non-f
I have destinations not accepting email with a 451 return code. Some
> of them are being sent by postfix to the smtp_fallback_relay and some
> of them are just sent to the deferred queue... Probably i am
> misunderstanding Postfix documentation but... What is exactly the
> Postfix crite
Pedro David Marco:
> Sorry, but i am confused... documentation is accurate, but probably
> not my understading of it...
Instead of arguing about what happens, look in your logs for the
messages that end up in the deferred queue.
In the implementation, Postfix appends the fallback relay(s) to the
On Thu, Apr 07, 2022 at 04:55:26PM +, Pedro David Marco wrote:
> I have destinations not accepting email with a 451 return code. Some
> of them are being sent by postfix to the smtp_fallback_relay and some
> of them are just sent to the deferred queue... Probably i am
> misu
On Thursday, April 7, 2022, 07:23:14 PM GMT+2, Wietse Venema
wrote:>>Pedro David Marco:>>> Hi,>> Postfix
documentation about smtp_fallback_relay says:>>>> smtp_fallback_relay (default:
$fallback_relay):>> Optional list of relay hosts for SMTP desti
Pedro David Marco:
> Hi,
> Postfix documentation about smtp_fallback_relay says:
>
> smtp_fallback_relay (default: $fallback_relay):
> Optional list of relay hosts for SMTP destinations that can't
> be found or that are unreachable. With Postfix 2.2 and earlier
>
Hi,
Postfix documentation about smtp_fallback_relay says:
smtp_fallback_relay (default: $fallback_relay):
Optional list of relay hosts for SMTP destinations that can't be found or
that are unreachable. With Postfix 2.2 and earlier this parameter is called
fallback_relay.
I
; to prefer implicit TLS over STARTTLS
> So, at least I would now announce that it would be nice to have
> something like this:
> master.cf
>smtp unix - - n - - smtp
> -o smtp_fallback_relay=[relayhost.exampl
er STARTTLS
So, at least I would now announce that it would be nice to have
something like this:
master.cf
smtp unix - - n - - smtp
-o smtp_fallback_relay=[relayhost.example]:465
# not yet existing option :-)
-o smtp_fallback_relay_wrappermode=on
Andreas
Greetings, Viktor Dukhovni!
>> On Nov 28, 2018, at 9:25 PM, Andrey Repin wrote:
>>
>>> The "smtp_tls_wrapper_mode" setting in Postfix is per-transport
>>> (via master.cf overrides), and has no per-destination analogue in
>>> the TLS policy table. Nor is this inferred from the port number.
>>
>
> On Nov 28, 2018, at 9:25 PM, Andrey Repin wrote:
>
>> The "smtp_tls_wrapper_mode" setting in Postfix is per-transport
>> (via master.cf overrides), and has no per-destination analogue in
>> the TLS policy table. Nor is this inferred from the port number.
>
>> So yes, you can't have wrapper mo
y called "implicit" TLS:
> https://tools.ietf.org/html/rfc8314#section-3
>> Hm. I was near that solution, but you are right that it is only applicable to
>> a known set of domains.
> Is that your case or do you see the issue with an unpredictable set
>
you see the issue with an unpredictable set
of destinations?
> > smtp unix - - n - - smtp
> > -o smtp_fallback_relay=[relayhost.example]:587
>
> Should use 465...
The "smtp_tls_wrapper_mode" setting in Postfix is per-tra
SMTP) or implicit TLS
> (SMTP after TLS)?
TLS as in - explicit TLS (port 465).
>> Now, I've successfully configured dumb relayhost= with TLS and auth.
>> But I'm failing to mate it with either relay_transport= or
>> smtp_fallback_relay=
> If the failures are confined
TLS after SMTP) or implicit TLS
(SMTP after TLS)?
> Now, I've successfully configured dumb relayhost= with TLS and auth.
> But I'm failing to mate it with either relay_transport= or
> smtp_fallback_relay=
If the failures are confined to a mostly stable set of domains and are
no
hough slower, but…
4. Relay server requires TLS and authentication.
Now, I've successfully configured dumb relayhost= with TLS and auth.
But I'm failing to mate it with either relay_transport= or
smtp_fallback_relay=
It either not using fallback relay, complain that it requires wrappermode=ye
w many? 10? 100? 1000? It it's 10, just use different SMTP client
entries in master.cf, each with its own "-o smtp_fallback_relay"
override.
smtpA .. .. .. .. .. .. smtp
-o smtp_fallback_relay=[192.168.2.1]
smtpB .. .. .. .. .. .. smtp
-o smtp_fallba
??? (without using DNS
"tricks if possible please, just Postfix)
thanks in advance again!
Pedro.
On Tue, 1/12/16, Wietse Venema wrote:
Subject: Re: smtp_fallback_relay in transport maps...
To: "Postfix users"
Date: Tuesday, January 12
Pedro David Marco:
> Thanks a lot Wietse for your quick answer...
>
> but then... does this mean that i cannot use smtp_fallback_relays
> in transport_map file??
Perhaps you can explain what problem you are trying to solve.
I.e explain the problem instead of the solution, because
there may be a b
Thanks a lot Wietse for your quick answer...
but then... does this mean that i cannot use smtp_fallback_relays in
transport_map file??
Thanks again!
Pedro.
On Tue, 1/12/16, Wietse Venema wrote:
Subject: Re: smtp_fallback_relay in transport maps
Pedro David Marco:
> Hello everybody!!!
>
> I am trying to set smtp_fallback_relays per domain in the transport map file.
>
> According to the documentation this is possible:
> "In transport maps, specify "relay:nexthop..." as the right-hand side for
> backup or primary MX domain entries."
Th
Hello everybody!!!
I am trying to set smtp_fallback_relays per domain in the transport map file.
According to the documentation this is possible:
"In transport maps, specify "relay:nexthop..." as the right-hand side for
backup or primary MX domain entries."
i have tried:
domain.com smtp:[
On September 29, 2014 12:00:04 PM Ralf Hildebrandt wrote:
Currently I'm using smtp_fallback_relay but I don't want Address
verification probes to take that particular path.
How can I disable smtp_fallback_relay for the address verification
probes?
Add it to verify service in mast
client behaved
> as if smtp_mx_session_limit=1, that is, there was only one SMTP
> session per delivery request (it tried to connect to each MX until
> one responded, and then it would not try any of the other MXes).
>
> Why is it better to skip the fallback relay and reply with
Ralf Hildebrandt:
> > The difference is that probes are never delivered (SMTP interruptus),
> > and that failed probes are never returned to the mail queue. There
> > is no reason to keep failed probes in the mail queue (and it would
> > be unwise).
>
> You mean they would clutter the queue?
Mas
* Wietse Venema :
> Robert Schetterer:
> > Am 29.09.2014 um 13:45 schrieb Noel Jones:
> > > Is smtp_fallback_relay even used with a verification probe? I would
> > > expect the probe to fail before it tries the fallback.
> >
> >
On 9/29/2014 9:06 AM, Wietse Venema wrote:
> Robert Schetterer:
>> Am 29.09.2014 um 13:45 schrieb Noel Jones:
>>> Is smtp_fallback_relay even used with a verification probe? I would
>>> expect the probe to fail before it tries the fallback.
>>
>
Noel Jones:
> > By default, Postfix sends address verification probe messages via the
> > same route as regular mail,
>
> Yes, but it also says:
>
> Probe messages are like normal mail, except that they are never
> delivered, deferred or bounced
> - and -
> Postfix assumes that an address is und
Robert Schetterer:
> Am 29.09.2014 um 13:45 schrieb Noel Jones:
> > Is smtp_fallback_relay even used with a verification probe? I would
> > expect the probe to fail before it tries the fallback.
>
> hm...
>
> http://www.postfix.org/ADDRESS_VERIFICATION_README.html
>
Am 29.09.2014 um 16:04 schrieb Ralf Hildebrandt:
>> Yes, but it also says:
>>
>> Probe messages are like normal mail, except that they are never
>> delivered, deferred or bounced
>
> Wait what?
>
>> - and -
>> Postfix assumes that an address is undeliverable when the nearest
>> MTA for the addre
>>>> On Mon, Sep 29, 2014 at 12:00:04PM +0200, Ralf Hildebrandt wrote:
>>>>>>
>>>>>>> Currently I'm using smtp_fallback_relay but I don't want Address
>>>>>>> verification probes to take that particular path.
>>>
> Yes, but it also says:
>
> Probe messages are like normal mail, except that they are never
> delivered, deferred or bounced
Wait what?
> - and -
> Postfix assumes that an address is undeliverable when the nearest
> MTA for the address rejects the probe, regardless of the reason for
> rejectio
randt wrote:
>>>>>
>>>>>> Currently I'm using smtp_fallback_relay but I don't want Address
>>>>>> verification probes to take that particular path.
>>>>>>
>>>>>> How can I disable smtp_fallback_relay for the a
Am 29.09.2014 um 13:45 schrieb Noel Jones:
> On 9/29/2014 6:18 AM, Wietse Venema wrote:
>> Ralf Hildebrandt:
>>> * Viktor Dukhovni :
>>>> On Mon, Sep 29, 2014 at 12:00:04PM +0200, Ralf Hildebrandt wrote:
>>>>
>>>>> Currently I'm using s
On 9/29/2014 6:18 AM, Wietse Venema wrote:
> Ralf Hildebrandt:
>> * Viktor Dukhovni :
>>> On Mon, Sep 29, 2014 at 12:00:04PM +0200, Ralf Hildebrandt wrote:
>>>
>>>> Currently I'm using smtp_fallback_relay but I don't want Address
>>>> ve
Ralf Hildebrandt:
> * Viktor Dukhovni :
> > On Mon, Sep 29, 2014 at 12:00:04PM +0200, Ralf Hildebrandt wrote:
> >
> > > Currently I'm using smtp_fallback_relay but I don't want Address
> > > verification probes to take that particular path.
> > &
* Viktor Dukhovni :
> On Mon, Sep 29, 2014 at 12:00:04PM +0200, Ralf Hildebrandt wrote:
>
> > Currently I'm using smtp_fallback_relay but I don't want Address
> > verification probes to take that particular path.
> >
> > How can I disable smtp_fal
On Mon, Sep 29, 2014 at 12:00:04PM +0200, Ralf Hildebrandt wrote:
> Currently I'm using smtp_fallback_relay but I don't want Address
> verification probes to take that particular path.
>
> How can I disable smtp_fallback_relay for the address verification
> pro
Currently I'm using smtp_fallback_relay but I don't want Address
verification probes to take that particular path.
How can I disable smtp_fallback_relay for the address verification
probes?
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
Am 15.08.2014 um 22:06 schrieb A. Schulze:
> Hello,
>
> I'm looking for an alternative solution for smtp_fallback_relay that I'm
> currently forced to use.
>
> Mostly I hit servers also running postscreen or postgrey.
> postfix could deliver direct if it w
Hello,
I'm looking for an alternative solution for smtp_fallback_relay that
I'm currently forced to use.
Mostly I hit servers also running postscreen or postgrey.
postfix could deliver direct if it would get a second chance.
But smtp_fallback_relay=... catch all deliveries after
A 127.0.0.1
As a matter of principle, when the Postfix SMTP client finds its
own IP address in the list of destination domain MX addresses, then
it WILL NOT hand-off mail to an equal-or-less preference MX host
or to an smtp_fallback_relay. This prevents mailer loops.
If a remote site lists
On 4/17/2014 9:55 AM, Denny Fuchs wrote:
> hi,
>
> Am 17.04.2014 um 15:21 schrieb Noel Jones :
>
>> Typically in your situation one would use relayhost, with
>> transport_maps overrides for internal destinations that are directly
>> reachable.
>
> thanks @all for debugging ... I think, is is sim
hi,
Am 17.04.2014 um 15:21 schrieb Noel Jones :
> Typically in your situation one would use relayhost, with
> transport_maps overrides for internal destinations that are directly
> reachable.
thanks @all for debugging ... I think, is is simply broken, what the maintainer
of the zone does. Is th
On Thu, Apr 17, 2014 at 09:55:59AM -0400, Wietse Venema wrote:
> With this:
>
> mailin.marc-werner.eu. 86060 IN MX 10 mx01.isphosts.de.
> mailin.marc-werner.eu. 86060 IN MX 100 mx02.isphosts.net.
> mx01.isphosts.de. 273 IN A 109.239.57.96
> mx02.isph
Denny Fuchs:
Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
> hi,
>
> in our university we have to use a relay server, for delivering mails to
> external destinations. It works since two years with:
>
> smtp_fallback_relay = mailout.example.com
On 4/17/2014 7:04 AM, Denny Fuchs wrote:
> hi,
>
> Am 17.04.2014 um 13:16 schrieb Denny Fuchs :
>
>
>> smtp_fallback_relay = mailout.example.com
>
> just for testing: I added relayhost = mailout.example.com && postfix reload
> && postsuper
hi,
Am 17.04.2014 um 13:16 schrieb Denny Fuchs :
> smtp_fallback_relay = mailout.example.com
just for testing: I added relayhost = mailout.example.com && postfix reload
&& postsuper -r && sendmailq -q .. and mails are delivered through the
relay server. So, it
hi,
in our university we have to use a relay server, for delivering mails to
external destinations. It works since two years with:
smtp_fallback_relay = mailout.example.com
Postfix tries to deliver the mail directly, but it fails, with a connection
refused /network unreachable(ipv6) (blocked
> > Alternative/additional approach:
> >
> > smtp_fallback_relay_threshold_time (compare to
> > smtp_pix_workaround_threshold_time)
> >
> > How long a message must be queued before the Postfix SMTP client
> > passes the mail to the smtp_fallback_re
Ralf Hildebrandt:
> Currently, smtp_fallback_relay is being used after the first failed
> delivery.
>
> http://www.postfix.org/postconf.5.html#smtp_fallback_relay
> explicitly mentions: "With bulk email deliveries, it can be beneficial
> to run the fallback relay MTA on th
On Thu, Jun 13, 2013 at 03:40:33PM +0200, Ralf Hildebrandt wrote:
> Currently, smtp_fallback_relay is being used after the first failed
> delivery.
>
> http://www.postfix.org/postconf.5.html#smtp_fallback_relay
> explicitly mentions: "With bulk email deliveries, it can be
Currently, smtp_fallback_relay is being used after the first failed
delivery.
http://www.postfix.org/postconf.5.html#smtp_fallback_relay
explicitly mentions: "With bulk email deliveries, it can be beneficial
to run the fallback relay MTA on the same host, so that it can reuse
the send
Ralf Hildebrandt:
> If a SMTP destination is unreachable, is the smtp_fallback_relay tried
> IMMEDATELY after not reaching the "real" destination or is the mail
> being deferred and thus subject to queue_run_delay / minimal_backoff_time?
Immediately. It is implemented as if th
If a SMTP destination is unreachable, is the smtp_fallback_relay tried
IMMEDATELY after not reaching the "real" destination or is the mail
being deferred and thus subject to queue_run_delay / minimal_backoff_time?
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße
Rafael Azevedo:
> > Yes, you can, as long as the MTAs run on the SAME HOST.
>
> Hmm.. Is there anyway we can have multiple postfix instances sharing
> the same queue?
Definitely not.
Wietse
On Thu, Jan 17, 2013 at 3:45 AM, Stan Hoeppner wrote:
> I know you're not Steve.
>
No.. I AM Steve! ;)
Rafael Azevedo:
> > smtp_bind_address sets the SOURCE IP address.
>
> Yes, but I cant have 2 servers with same smtp_bind_address
Yes, you can, as long as the MTAs run on the SAME HOST.
Wietse
> smtp_bind_address sets the SOURCE IP address.
Yes, but I cant have 2 servers with same smtp_bind_address
- Rafael
> same host?
The idea of smtp_fallback_relay is to NOT share the mail queue.
> Regardless, if they two MTAs used the same smtp_bind_address,
> wouldn't that mean that only one of them would match the host's
> reverse DNS lookup, and that the other would have mail rejected
On Thu, Jan 17, 2013 at 5:28 AM, Wietse Venema wrote:
> host = computer (operating system on top of real or virtual hardware)
> MTA = postfix
>
> The text in main.cf assumes that both non-fallback and fallback
> MTA run on the same host and that they send mail from the same
> source IP address. Y
Rafael Azevedo:
> > A host is a computer (or virtual machine). myhostname is a Postfix
> > parameter. Now plug these into the context of Wietse's statement to you
> > and you should understand.
>
> Thanks Stan!
>
> But if I point it to another host (different than myhostname) it
> will send thr
> A host is a computer (or virtual machine). myhostname is a Postfix
> parameter. Now plug these into the context of Wietse's statement to you
> and you should understand.
Thanks Stan!
But if I point it to another host (different than myhostname) it will send
through another IP right? I'm not
On 1/17/2013 5:16 AM, Rafael Azevedo wrote:
> Could you please tell me the difference of "same host" and "myhostname"?
A host is a computer (or virtual machine). myhostname is a Postfix
parameter. Now plug these into the context of Wietse's statement to you
and you should understand.
--
Stan
On 1/16/2013 6:49 PM, Steve Jenkins wrote:
> On Wed, Jan 16, 2013 at 4:35 PM, Stan Hoeppner
> wrote:
>> And BTW, if you're not a spammer...
> Gotit - thanks. I am certainly NOT a spammer.
I know you're not Steve. I should have said "as you're not a spammer.."
instead of "if you're..."
--
St
cases of greylists. In my case, each postfix
server uses myhostname to determinate the server's host (each host has its own
ip).
So I imagined that I should use the same myhostname in smtp_fallback_relay in
order to have it retrying to send the messages that were deferred because of
grayl
> It says use the same host. It does not say use the same
> myhostname setting.
Thanks once again Wietse! Your help is very appreciated.
I'll try to work on this.
BR,
- Rafael
On Wed, Jan 16, 2013 at 4:35 PM, Wietse Venema wrote:
> You can twiddle with smtp_mx_mumble_limit, but why bother sending
> from mailer1, when the mail is accepted only from mailer2?
>
For those who are learning along with me, since I didn't want to leave the
smtp_mx_address_limit settings at t
Rafael Azevedo - IAGENTE:
> With bulk email deliveries, it can be beneficial to run the fallback
> relay MTA on the same host, so that it can reuse the sender IP
> address. This speeds up deliveries that are delayed by IP-based
> reputation systems (greylist, etc.).
...
> And the logs just shows th
On Wed, Jan 16, 2013 at 5:27 PM, Wietse Venema wrote:
> mumble is a wild-card.
>
> grep smtp_mx_ in postconf output.
>
DOH! Roger that. :)
Also, any way to use transport in some way on mailer1 to tell Postfix to
use mailer2 for aol.com addresses? I could set that temporarily for the
remainder o
Steve Jenkins:
> On Wed, Jan 16, 2013 at 4:35 PM, Wietse Venema wrote:
>
> > You can twiddle with smtp_mx_mumble_limit
>
> FYI - Google returns NO results (nor does the search function on
> Postfix.org... since it's Google-powered) for "smtp_mx_mumble_limit." Any
> docs on that?
mumble is a wil
Hello guys!
I was reading the smtp_fallback_relay doc at
http://www.postfix.org/postconf.5.html#smtp_fallback_relay and couldn't be able
to make it work.
It says:
smtp_fallback_relay (default: $fallback_relay)
[…]
With bulk email deliveries, it can be beneficial to ru
On Wed, Jan 16, 2013 at 4:35 PM, Wietse Venema wrote:
> You can twiddle with smtp_mx_mumble_limit
FYI - Google returns NO results (nor does the search function on
Postfix.org... since it's Google-powered) for "smtp_mx_mumble_limit." Any
docs on that?
SteveJ
On Wed, Jan 16, 2013 at 4:35 PM, Wietse Venema wrote:
> You can twiddle with smtp_mx_mumble_limit, but why bother sending
> from mailer1, when the mail is accepted only from mailer2?
>
I think mailer1 got blocked initially by AOL because my
aol_destination_concurrency_limit, aol_destination_reci
On Wed, Jan 16, 2013 at 4:35 PM, Stan Hoeppner
wrote:
> Why not simply spread the newsletter load over both your outbounds to
> begin with?
>
Until this week, we were using an OLD server to act as our fallback relay
(graveyard) machine and nothing else, since we really couldn't lean on it
that
Steve Jenkins:
> I guess my only other option is to turn off smtp_skip_5xx_greeting, in
> which case it will hand off to mailer2 on the first failure, correct?
Nope. 5xx is a permanent delivery error.
Wietse
Steve Jenkins:
> This is from mailer1:
[5x 554 greeting]
> mtain-mc05.r1000.mx.aol.com ESMTP not accepting connections
> Jan 16 16:14:40 mailer1 postfix-aol/smtp[1732]: 97092438FFD: to=<
> xx...@example.com>, relay=mailer2.example.com[xx.xx.xx.xx]:25, delay=7365,
> delays=6096/1261/8.3/0.13, dsn=2.
On 1/16/2013 6:23 PM, Steve Jenkins wrote:
> So I guess I should change my question - it looks like mailer1 is
> attempting to deliver to 5 AOL mail servers before passing off to the
> relay. Any way I can make it hand off to the fallback relay with fewer
> attempts?
Why not simply spread the new
On Wed, Jan 16, 2013 at 4:22 PM, Wietse Venema wrote:
> With "smtp_skip_5xx_greeting = yes" by default, Postfix pretends
> that the session failed due to a temporary error and tries the next
> MX host (or fall-back relay).
>
> If the mail is still in the active queue then Postfix is still
> tryin
On Wed, Jan 16, 2013 at 4:12 PM, Steve Jenkins wrote:
> Should that not trigger handing the message over to the fallback relay for
> subsequent attempts?
>
Hold on... maybe it IS handing it off, now that I look at it more closely.
This is from mailer1:
Jan 16 16:14:32 mailer1 postfix-aol/smtp[17
Steve Jenkins:
> qshape isn't showing deferred mail on mailer1, though. qshape deferred is
> all zeros. The active queue is massive, however (over 91K messages in it
> now) and more than half of them are in the 1280 column.
>
> When a destination replies to mailer1 like this:
>
> Jan 16 16:10:15
On Wed, Jan 16, 2013 at 4:00 PM, Wietse Venema wrote:
> The way smtp_fallback_relay is implemented, it adds each relay as
> a low-priority MX host with a safety check: if the relay does not
> resolve, then mail is not bounced.
>
Hey, Wietse. I appreciate the reply.
Ok - as far a
Steve Jenkins:
> I've got two machines on my network - mailer1 and mailer2. Both running
> Postfix 2.9.5. I've got
>
> smtp_fallback_relay = mailer2.example.com
>
> configured in mailer1's main.cf.
The way smtp_fallback_relay is implemented, it adds each relay
On Sat, Sep 08, 2012 at 10:49:49PM -0500, Stan Hoeppner wrote:
> Is the latency you describe caused by disk IOPS or Postfix queue
> processing behavior, or ?? I'd assume most folks using a 2nd instance
> for fallback relay duty have the fallback instance queue on the same
> physical disks, so I a
On 9/8/2012 8:43 AM, Viktor Dukhovni wrote:
> On Sat, Sep 08, 2012 at 10:01:13AM +0200, Ralf Hildebrandt wrote:
>
>> When sending lots of mails (mass mailings) via many machines, one
>> quickly realizes that the current concept of smtp_fallback_relay is
>> a bit problem
Am 08.09.2012 20:28, schrieb Wietse Venema:
> Robert Schetterer:
>>> Nobody said that the fallback relay has to another machine. You
>>> can and should in many cases configure a second Postfix instance
>>> on each machine to be the fallback relay, this solves the greylisting
>>> by IP problem, and
Robert Schetterer:
> > Nobody said that the fallback relay has to another machine. You
> > can and should in many cases configure a second Postfix instance
> > on each machine to be the fallback relay, this solves the greylisting
> > by IP problem, and keeps the fallback load distributed to all the
Am 08.09.2012 15:43, schrieb Viktor Dukhovni:
> On Sat, Sep 08, 2012 at 10:01:13AM +0200, Ralf Hildebrandt wrote:
>
>> When sending lots of mails (mass mailings) via many machines, one
>> quickly realizes that the current concept of smtp_fallback_relay is
>> a bit problem
* Viktor Dukhovni :
> Nobody said that the fallback relay has to another machine. You
> can and should in many cases configure a second Postfix instance
> on each machine to be the fallback relay, this solves the greylisting
> by IP problem, and keeps the fallback load distributed to all the
> ava
On Sat, Sep 08, 2012 at 10:01:13AM +0200, Ralf Hildebrandt wrote:
> When sending lots of mails (mass mailings) via many machines, one
> quickly realizes that the current concept of smtp_fallback_relay is
> a bit problematic:
If one thinks harder, one realizes the purpose of the mechan
* Ralf Hildebrandt :
> I'll check the use of the smtp_fallback_relay for different mailing
> campaigns.
machine epsilon:
Mails sent directly to MX:
==
56423 (93.7%)
Mails sent to fallback_relay:
=
3735 (6.2%)
Bounces:
83
Am 08.09.2012 15:11, schrieb Ralf Hildebrandt:
> * Wietse Venema :
>
>> I suppose you have lots of logfile information. Does the evidence
>> support the idea that delaying smtp_fallback_relay would improve
>> the delivery life cycle?
>
> I'll check the
* Wietse Venema :
> I suppose you have lots of logfile information. Does the evidence
> support the idea that delaying smtp_fallback_relay would improve
> the delivery life cycle?
I'll check the use of the smtp_fallback_relay for different mailing
campaigns.
--
Ra
Ralf Hildebrandt:
> When sending lots of mails (mass mailings) via many machines, one
> quickly realizes that the current concept of smtp_fallback_relay is
> a bit problematic:
>
> * The mass mailing gets (randomly) distributed to n machines
> * these n machines try sending out
Am 08.09.2012 10:01, schrieb Ralf Hildebrandt:
> When sending lots of mails (mass mailings) via many machines, one
> quickly realizes that the current concept of smtp_fallback_relay is
> a bit problematic:
>
> * The mass mailing gets (randomly) distributed to n machines
> * th
When sending lots of mails (mass mailings) via many machines, one
quickly realizes that the current concept of smtp_fallback_relay is
a bit problematic:
* The mass mailing gets (randomly) distributed to n machines
* these n machines try sending out the mails assigned to them and will
encounter
Patrick Ben Koetter:
> Use DNS (round robin) to provide more than one IP for server1.tld or cluster
> the ip.
Georg Sch?nweger:
> Does this solve the problem? if IP1 is down will postfix retry to send
> via IP2? Or will postfix just defer the delivery? If so then
> smtp_fallback_re
Am 07.06.2012 09:58, schrieb Patrick Ben Koetter:
> * Georg Schönweger :
>> Hi,
>>
>> On our postfix server we use:
>> relayhost = [server1.tld]:587
>>
>> How can i tell postfix to relay mails localy if server1.tld is down? I
>> thought this
1 - 100 of 129 matches
Mail list logo
