ietf-asrg
[Top] [All Lists]

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

2003-12-01 06:13:39
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(_at_)mv(_dot_)mv(_dot_)com>
To: "Hector Santos" <winserver(_dot_)support(_at_)winserver(_dot_)com>
Cc: "Mark E. Mallett" <mem(_at_)mv(_dot_)mv(_dot_)com>; "Brett Watson"
<famous-asrg(_at_)nutters(_dot_)org>; <asrg(_at_)ietf(_dot_)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
  *(_at_)example(_dot_)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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>