Re: [Asrg] 0. General - anti-harvesting (was Inquiry about CallerID Veri

On 2003-11-30 20:12:34 -0500, Yakov Shafranovich wrote:
> Hector Santos wrote:
> > ----- Original Message -----
> >
> > > Allows me to rephrase this - This is a requirement that the receiver is
> > > required to send the delivery failure notice back to the sender. It is
> > > not a requirement that the address for that notice should exist and be
> > > functional, or in your case be able to reach the RCPT TO stage.
> > Sorry, I disagree with your interpretation of the current specification.
> >
> > A Mail From:  must be valid if all other RFC specifications is to fit.
> [..]
> > I am failing to see why so much resistance?  All you are basically proving
> > is how the CURRENT specification needs to be tighten up.
> [..]
>
> What I am trying to point out that your specific proposal is not 
> compliant with the current architecture.
I do think it is compliant. RFC 2821 mentions here and there that mail
may not be accepted for unspecified policy reasons, for example:

    3.3

    MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>
    [...]
    If the mailbox specification is not acceptable for some reason, the
    server MUST return a reply indicating whether the failure is
    permanent (i.e., will occur again if the client tries to send the
    same address again) or temporary (i.e., the address might be
    accepted if the client tries again later).

    [...]
    - If the verb is initially accepted and the 354 reply issued, the
      DATA command should fail only [...] or if the server determines
      that the message should be rejected for policy or other reasons.

    3.7

    If it declines to relay mail to a particular address for policy
    reasons, a 550 response SHOULD be returned.

etc.

I believe that these are left intentionally undefined ("some reason",
"policy or other reasons", "policy reasons") to allow the administrator
to impose arbitrary (but hopefully sensible) rules on his systems
without violating the RFC. 

So, I believe that Wildcat or Exim servers which try to validate the
whole return path are just as compliant as sendmail or qmail servers
which try to only validate the domain part of the return path.

> Whether the RFCs require a valid return address, or not, in spirit or in 
> letter of the law, is something Dave Crocker and Eric Raymond, and 
> others, who worked on the original 821 and 2821 RFCs can tell us.
Eric told us, but I'm not convinced. I would agree with him that it is
the spirit of the law, but the letters he has shown us to support his
interpretation are rather weak. Anyway, I think this is a red herring.
SMTP doesn't have to require return-path validation, it only has to
allow it.

> But the fact today is that no one is expected to provide a valid
> address, and any system relying on this, will fail in some cases
> unless the existing RFCs are changed.
Yes, but that's the whole point, isn't it? Some people choose to send
out messages with invalid return paths. Many of them are spammers, some
are only incompetent. In any case, they cause problems: DSNs cannot be
delivered and often replies won't work either (if the message headers
contain the same sender address). So it do agree with Hector that it is
a sensible policy decision to not accept such messages in the first
place. 

        hp

-- 
   _  | Peter J. Holzer    | In this vale
|_|_) | Sysadmin WSR       | Of toil and sin
| |   | hjp(_at_)hjp(_dot_)at         | Your head grows bald
__/   | http://www.hjp.at/ | But not your chin.           -- Burma Shave

pgpjvr6gGeWdn.pgp
Description: PGP signature