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

At 11:41 AM -0800 11/29/03, Matthew Elvey wrote:
> On 11/28/2003 12:39 PM, Yakov Shafranovich sent forth electrons to convey:
>
> > Hector Santos wrote:
> >
> > > YAHOO.COM,  AOL.OCM and others accepts "billions" of mail therefore might
> > > deem it necessary to delay any mail validation process.  Again, it does not
> > > mean it doesn't work.    It means, these guys are the PROBLEM, but anyone in
> > > the mail server business knows that.   You are comparing it against the
> > > AOL.COM, YAHOO.COM, etc.  Yet, in the same breath,  I read how these guys
> > > are trying to define or hijack your efforts.
> >
> > There is a reason to their madness - it discourages spammers from 
> > harvesting email addresses.
> It's a poor excuse.  There are ISPs that detect harvesting attacks 
> and when they do, deal with it - some then refuse even email to 
> valid addresses.  They can refuse the email without stating or 
> otherwise giving away the information that the reason for refusal is 
> email to a nonexistent account. IMO, MAIL FROM: <> needs to be 
> deprecated in favor of refusal during SMTP.
The null sender for system-generated messages about system-level 
issues should NOT be deprecated without providing some solution for 
everything that it is currently useful for. Bounces are just one 
variation on the broader theme of DSN's.
>  There is no compelling reason to delay the mail validation process.
Whether that is true really depends on how narrowly you want to view 
the email world. If you want to ordain that all mailable domains must 
have the full knowledge of their namespace in every host that they 
have an MX record pointing at, this is a very tall order for changes 
from how a significant fraction of the net works today.
>   It provides no benefit that cannot be met with immediate 
> validation, barring the super-secure bastion host scenario Bill Cole 
> mentions, which could be resolved with some work. (I should admit - 
> I don't do what I preach, as the provider I choose to have host my 
> domain does accept spam that I'd prefer it refuse during SMTP, but I 
> have pushed them to fix the problem, and they do refuse a good 
> fraction of the spam during SMTP.)
That example was ONE case. Without delaying the validation of the 
target address, every domain in which there are mail addresses would 
need published MX records pointing to machines with live access to 
the authoritative knowledge store for each domain it serves. We could 
kiss UUCP goodbye finally, and if you think no one still uses it you 
are quite wrong. Large organizations that now have single external 
faces on their mail systems for many possible subdomains which 
actually route internally in complex ways would need to be 
redesigned. As an example of this, I work with a major systems vendor 
with a global workforce whose individual email addresses reflect 
their geographic location, yet the exterior MX record set for all of 
the subdomains is one server farm. That server farm has to know how 
to route mail to many different subdomains handled on many different 
machines around the world. It DOES NOT have access to the full user 
namespace for all of those domains, it merely knows that it accepts 
mail for the various subdomains and hands it off internally to 
machines closer to the HR departments for the various branches. Even 
without exposed subdomains, such situations are problematic because 
companies beyond a certain size simply do not operate as single 
entities and cannot operate their email systems on single giant 
machines that know everything simultaneously. The fact of an address 
no longer being valid can easily take a day to propagate throughout a 
global operation, and it is a rare large company that can make the 
event of a user add or delete look instantaneous to their entire 
email system.
> I forget whether SpamAssassin supports what we're currently calling 
> CallerID Verification.  It has NO_DNS_FOR_FROM: Domain in From 
> header has no MX or A DNS records, but I think it doesn't have the 
> full CallerID Verification.
I admit to having only skimmed the stuff on 'CallerID' because it 
looks like the same unscaleable stuff that has been in in some MTA's 
for a while with essentially tries a RCPT verification of every MAIL 
FROM given, and there are probably enough of us managing mail servers 
who will address that sort of behavior as just another attack (null 
route the offending machine) so that the inherent scaling and 
indirect attack problems don't ever make it to visibility.
That said, the practice of a DNS check on any non-null MAIL FROM 
argument is reasonable and done by many modern MTA's as a basic bar 
to the most clueless spammers. Doing the same on From lines is a 
little more problematic, but it is not completely unreasonable.
--
Bill Cole                                  
bill(_at_)scconsult(_dot_)com

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg