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.
- 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.
- 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.
- The system that accepts all mail so that it can update its
'corpus' of spam mail. False positives.
True, which was something we though YAHOO was doing but they are validating
in the DATA state.
Maybe they can be solved by extending the capabilities of VRFY,
but I doubt they can be solved by changing usage behaviour.
What would be another way?
There is never going to be a 100% solution.
The proposal simply highlights the dearth of the SMTP controls which is what
80% of the spammers are exploiting.
My contention is that you can address the 80% of the problem by having
strict definitions of the specs. If by change there are made strict, then
there a big part of the problem is solve when the software begins to comply.
Sure, there could be zombies. My WCSAP implementation is using a second
fake address test and I was able to pick up many of these as an OPEN RELAY
site.
But you will not get them all. In this case, when the controls are in place,
the spammers will be reduced to traceable systems.
---
Hector Santos, CTO
WINSERVER "Wildcat! Interactive Net Server"
support: http://www.winserver.com
sales: http://www.santronics.com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg