Currently these are trying to deliver ndr's constantly to eg amm@dhl.com
and bounce@nds.fedex.com.
Why does your system generate DSNs?
And why aren't those delivered?
If ip ranges have been put on a specific blacklist, they will be treated
as greylisting. In the greylist 4xx notification is a link that will
allow the email through when it is clicked. Because these 4xx are not
always (directly) communicated back to the sender, a message to the
envelope is send also.
This message is only send when the spf is valid (for invalid or no spf,
no such message is send)
Maybe you could fix those problems instead of trying to work around
them and also affecting other mails?
This is still in trial, for now I would like to see how this goes.
Nice would be if such `external' messages would only be tried to
delivered two or 3 times. For messages that have to be delivered to the
And if there is a temporary problem you want the message to fail
after 3 tries?
Yes, currently I have countless tries.
You could use "Queue Groups" and change the retry times,
but the overall timeout is global -- though there are
some "suboptions", see doc/op/op.*, e.g.,
If the message has a normal
(default) precedence and it is a delivery status
notification (DSN), Timeout.queuereturn.dsn and
Timeout.queuewarn.dsn can be used to give an alter-
native warn and return time for DSNs.
Oh ok that looks quite interesting. Obviously I am a little worried that
if something here is down mail is not going to be queued and bounced. So
I would prefer to have something that is deciding on ‘infrastructure’ instead of something like this.
QGRP:slow-poke.com slowgroup
QGRP:
root@notify.com fastgroup
QGRP:your.domain localgroup
[1]
https://etutorials.org/Server+Administration/Sendmail/Part+II+Administration/Chapter+11.+Manage+the+Queue/11.4+Queue+Groups+V8.12+and+Above/
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)