Re: [exim] conducive.org

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: W B Hacker
Ημερομηνία:  
Προς: exim users
Αντικείμενο: Re: [exim] conducive.org
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