Re: [exim] retry configuration

Pàgina inicial
Delete this message
Reply to this message
Autor: W B Hacker
Data:  
A: exim users
Assumpte: Re: [exim] retry configuration
Catalin Constantin wrote:
>> On Mon, Apr 20, 2009 at 09:47:59PM +0300, Catalin Constantin wrote:
>>> Even after setting retry_use_local_part, no luck.
>>> It looks like Lena suggested that this configuration is ignored for
>>> remote transports.
>> Yeah, bummer. Not sure why that is.
>>
>> Anyway, there's something suficiently odd about your configuration then.
>> We send a much larger number of messages to Yahoo than that, and never
>> run into problems.
> The odd part in this whole issue is that sending with Postfix from the
> same system is
> FAST enough. Trying to switch to Exim (cause of extra config options)
> ended up with this
> BIG deliverability issue.
>> I'd suggest you try and find out why you are getting hit with greylisting
>> when others who are sending much more are not.
>>
> The grey list is something regular for hosts which do not send very
> high volumes of email.
> Not being able to proper retry a delivery cause of miss
> implementations (or no implementation) could be
> considered a bug ? Should i submit the bug or feature request ?
>
> Triggering from cron:
> # exim -qf
> is not pretty nice for a workaround.
>
>> We handle tens of millions of messages a month and have never run into
>> problem with remote retries. Now, that being said, we do have split
>> queues for immediate deliveries, deferred deliveries, and slow delivery
>> hosts to keep things running tip-top, but still no underlying problems
>> with retries on a per domain basis.
> You can consider this "luck" :)
>


Not 'luck'. Appropriate configuration.

That you are getting greylisted *repeatedly* indicates you may have some
other settings that differ from what you ran with Postfix.

Peripheral not-quite-right items that might give Yahoo cause to NOT let
you thru greylisting on second and subsequent attempt, and for longish
periods thereafter where your FIRST attempt would be accepted.

EX:

- do you 'HELO' with a FQDN that is an exact match to that which a
reverse-lookup recovers?

- does your DNS entry have UPPER CASE where lower-case is expected?

- do you perhaps hit a significant number of non-existent Yahoo accounts?

- are you jumping-off from an IP block that is unwelcome?

- are you stuck with a <tld> country-code that has a reputation as a
highly probable spam source?

- Is all else about your message headers, content, and attachments
'proper' and of a sort above suspicion?

Feel free to send me a direct test message and I'll see what the
'scores' are in my logs - we're generally more strict than Yahoo, AND
rather more verbose w/r logging.

Bill Hacker