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

["Hector Santos" <winserver.support@winserver.com>]

If am I still able to follow this thread, I believe I said:

In the case of the SMTP system,  at this level UUCP doesn't apply yet.
The validation proposed is at the SMTP level.

----- Original Message ----- 
From: "Mark E. Mallett" <mem@mv.mv.com>
To: "Hector Santos" <winserver.support@winserver.com>
Cc: "Mark E. Mallett" <mem@mv.mv.com>; "Brett Watson"
<famous-asrg@nutters.org>; <asrg@ietf.org>
Sent: Monday, December 01, 2003 7:16 AM
Subject: Re: [Asrg] 0. General - anti-harvesting (was Inquiry about CallerID
Verification)


> On Mon, Dec 01, 2003 at 06:06:10AM -0500, Hector Santos wrote:
> > > There are various legitimate situations in which VRFY or RCPT TO
> > > verification wouldn't presently work.  These would have to be solved.
> > > For example:
> > >
> > > - UUCP (mentioned elsewhere in this long thread.)  The host system
> > >   doesn't have any chance of verifying users behind the UUCP
connection.
> > >   You'd get false positives here.
> >
> > I already addressed this. This is a SERVER implementation issue.
> >
> > We had the same problem in our UUCP software awhile back.   The solution
was
> > to support  RFC 1128 5.2.8 and make sure that delay validation performed
by
> > the UUCP/gateway software supported it by expecting the specific header
> > line:
> >
> >              "Return-Path: <original-mail from:>
> >
> > If the UUCP software does not support it, then you are correct.
> >
> > The Return-Path is persistent across the route until final delivery is
> > reached.
>
> OK, but what does that have to do with the paragraph that this is
> allegedly a response to?  And did you really mean RFC 1128?
>
>
>
> > > - As with UUCP, other sorts of disconnected delivery systems where the
> > >   receiving MTA doesn't know anything about the usernames attached to
> > >   a domain.  e.g. the user who has a catchall box for all
> > >   *@example.com addresses, who periodically accesses that box and
> > >   applies local filtering rules.  The user who just has a single
> > >   maildrop from which mail is retrieved via something like fetchmail
> > >   (or a number of equivalents).  Again, false positives.
> >
> > Well,  its a compatibility issue.  Absolutely.
> >
> > But in the case of the SMTP system,  at this level UUCP doesn't apply
yet.
> > The validation proposed is at the SMTP level.
> >
> > In our case, where the hosting sysop may have UUCP downlinks, he may not
be
> > a candidate to use a SMTP based validation.  So he would have to turn it
> > off.
> >
> > I should point out that our SMTP customers with UUCP downloads are
becoming
> > obsolete. <g>
> >
> > But we still needed to support it because in our design,  a design since
> > 1984 before SMTP was added in 1996,   still used a UUCP mail/news format
and
> > interface between each part of the systems:
> >
> >        SMTP <--> UUCP SPOOLS<---> LOCAL MAIL/GATEWAY <--> SERVER
DATABASE
> >
> > UUCP customers then use uucico to move their mail to their downlinks.
>
> OK, but what does this have to do with the paragraph that it is
> supposedly responding to?  (a) that paragraph was specifically
> about things *other* than UUCP, and (b) even if it was about UUCP,
> how does address the VRFY issue?
>
>
>
> > > - The recipient address that is only valid under certain circumstances
> > >   (e.g. graylisted, or firewalled such that it only accepts mail from
> > >   certain sources, or has a filter installed such that it only
> > >   accepts mail from certain senders).  False negatives here.
> >
> > Ok, but I think what with a callerid standard a place, it will help make
> > some of this unnecessary.
>
> I doubt it.  I imagine that with or without spam, more sophisticated
> filters that apply at SMTP time will be more and more common.  RCPT TO
> validation will become more and more fuzzy as that will depend more
> on connection-time filter logic.  Spam may be the prime factor promoting
> the development of interfaces supporting them, but once they are there,
> they will be used.
>
> Yours,
> mm
>



_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg