David Woodhouse wrote:
> On Fri, 2006-07-14 at 08:02 +0800, W B Hacker wrote:
>
>>>mail from: <>
>>>250 Ok
>>>rcpt to: test@???
>>>450 <test@???>: Recipient address rejected: Greylisted for 300
>>>seconds (see http://...)
>>>
>>
>>The above is only one of many false-positives.
>
>
> 'many'?
>
> Poor greylisting implementations (at RCPT instead of DATA time) do
> interact badly with sender verification callouts sometimes -- but the
> message should get through after it's retried. When they attempt to
> resend the message from test@???, once the 300 seconds has
> elapsed, it should get through.
>
Successive sender verify attempts will not necessarily open a greylist, so no,
it may not *ever* be passed if you use a 'hard' rejection.
>
>>The Exim MLM on sesame, for example fails sender verify at 'recipient', yet is
>>certainly on MY list of 'good guys'.
>
>
> What address? exim-users@???? That fails sender verification
> because it's never used as an SMTP reverse-path in valid mail.
By no means a situation unique to sesame, Mailman, or even mailing lists.
> It's the
> same with the address 'dwmw2@???'. In both cases, sender
> verification does exactly the right thing.
Correct as to what it is designed to provide tools to support.
Not necessarily desirable as a universal block rule if one uses only a subset of
the sender verify capability and/or considers the result 'gospel'.
>
> Using sender verification as an all-or-nothing test, and either
> rejecting or deferring (as in the above-quoted example) is something
> that works well for many people.
>
... my point is that it works better if used with more care.
> The only time it breaks is when people are sending you messages that you
> can't send bounces for -- which means you're likely not to be able to
> reply either. So they'll _think_ that they managed to communicate, but
> in fact you can't get back to them. It's better, in most of those cases,
> for the mail never to leave their own system. That way they know they've
> broken it.
That would break more than just a few mailing lists.
Many large ISP's have dodgy cluster configuration, either odd DNS, refusal to
respond to verification calls, or both. Some even blacklist what they tconsider
may be probing behaviour.
One can be a 'purist' and block all of these as a developer, hobbyist, 'persona;
MTA' user - but not when serving commercial clients who value communication more
than RFC compliance.
A more reasoned approach as to how you use the sender verify tool can retain its
value with lower risk of rejecting these (and others).
>
> Btw, your MUA is misbehaving -- your replies have neither In-Reply-To:
> nor References: headers, so they're not associated with the thread to
> which you replied. Please could you fix that so that you don't break the
> threading on the list?
>
Pipermail (online archives) handles that well enough, and Mozilla Mail has no
problem at all with it. Which MUA is not following it?
Bill
