David Woodhouse wrote:
> On Wed, 2006-10-18 at 19:30 +0800, W B Hacker wrote:
*snip*
>
>>>While we happen to be connected after a successful callout, we try a
>>>second RCPT with an address which is fairly sure to fail.
>>
>>and which RFC and paragraph defines how *those* SHOULD / MUST be responded to?
>
>
> RFC2821 defines the responses to RCPT TO:
>
> Either the server accepts the RCPT, in which case Exim won't bother with
> further callouts on the assumption that they'll all 'succeed' even for
> invalid addresses.
>
> Or the server rejects the RCPT, in which case Exim assumes that callouts
> are effective for the site in question, and may do further callouts for
> other addresses at the same domain.
>
Odd. I cannot find any mention of 'Exim' in the RFC cited...
More there than just 'selective quoting'.
How about the actual RFC, then - keeping in mind that any not-currently-valid
user may well be a former-user, so we are not always required to do immediate
'hard' rejection on mis-match.
See RFC2821:
=========
3.4 Forwarding for Address Correction or Updating
(third paragraph - isolated for emphasis)
Alternately,
* Servers MAY reject or bounce messages when they are not
deliverable when addressed. When they do so, they MAY either
provide address-updating information with a 551 code, or
may
reject the message as undeliverable with a 550 code and no
address-specific information.
But, if a 551 code is used, they
MUST NOT assume that the client will actually update address
information or even return that information to the user.
======
By convention, so long as the '550' appears, the rest is largely optional.
But the issue at hand is not the rejection message, or even that it *was* rejected.
The issue is where and how one attempts to justify issuing the *bogus probe* in
the first place.
*where* pray tell, is the part of the (*ANY*) RFC or standard that defines how
one MUST or MAY deliberately craft and send to a *known-invalid* address - and
not (at least) be considered impolite?
A callout is intended to confirm an MX by seeking a presumed-always-valid
address (postmaster) ELSE confirm the specific currently-on-the-teat sender, not
some for-sure-invalid and irrelevant to either *hash* at a random time period.
There *were no* other connections in our logs to that IP OR hostname OR even
<domain>.<tld> anywhere near the same day, so a sender verify it certainly was NOT.
But creative garbage of that sort is what DOES make support hard for sender
verification hard to justify.
Meanwhile, if it looks like a duck, waddles like a duck, and smells of duck
feces, we will call it a duck and blacklist the source like any other dictionary
attack source.
Absent any time-related connections, how should one expect to spot the difference?
Bill
