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

["Mark E. Mallett" <mem@mv.mv.com>]

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