Marc Sherman wrote:
> Heiko Schlittermann wrote:
>
>> Anyway - what about implementing the fallback_hosts feature not for
>> temporary errors but for 5xx errors too?
>>
>> The rationale: There's a mail server sending from non-rDNS-able address.
>> On most connections it works, but some reject this server with 5xx. In
>> this, *only* this case I'd like to route the mails to some friendly
>> smarthost...
>>
>> (The smart host uses callout for recipient checks, so if the 5xx is
>> because of some other reason, it should reject the mail at SMTP time
>> already, thus refusing its smart service.)
>>
>> Could please somebody explain me, why it's a stupid idea? ;-)
>>
>
> This has been discussed ad nauseam many times in the past. It will _not_
> give you a reliable mail server even if implemented. A large number of
> sites do not reject blacklisted messages with 550's, but rather
> quarantine or blackhole them. So implementing this feature will have all
> the negatives of violating the RFCs, and none of the intended benefits.
>
> http://www.google.ca/search?q=site:www.exim.org/mail-archives+fallback+OR+retry+smarthost&hl=en&lr=&start=10&sa=N
>
> - Marc
>
>
Picture this situation. I have several IPs to send mail on to forward to
my customers. One transport uses IP address A and for some unknown
reason A becomes accidentally blacklisted. So the customers hosting
company starts bouncing all the email coming from my filtering service
for that customer.
But - if it could be passed on to another transport that sends on a
different IP then it would perhaps go through.
As I have said. Would never do this for all outgoing email but only in
very targeted situations.
