[Top] [All Lists]

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

2003-11-30 22:26:20
Hector Santos wrote:
when you lock into the specs that a DOMAIN and a ADDRESS will be expected to
be valid, then you inherently and immediately begin to address a high
percentage of the spammer problem.

From my understanding, what you are basically asking is to make every single email on the Internet have a valid return address which will be checked by every system. This would require an RFC to be published laying out this requirement, which would in my view change the current SMTP specification, or in your view would consistute the codification of the "spirit" of the law, as it is inherently present today.

But, why lock down the actual email address instead of the domain? Why require every email to have a valid return address and domain? Shouldn't requiring a valid domain name suffice?

Let's say you have verified either the domain or the address, and the
message in question turns out to be spam. In both cases, you are going
to complain to the ISP of the domain, not the actual user! So why go
through the trouble of verifying the actual email address, when a domain
is sufficient?

Like I said, above, that is none of your business.  You are complicating
what is otherwise a technical problem with a very easy technical solution.
You just need to make it possible.

By attempting to get into "interpretation" of the data, then you are going
into a fuzzy logic and that's not the purpose of SMTP.

The SMTP specification and related RFCs make it very clear that parsing the RCPT TO and MAIL FROM addresses is perfectly fine, and that is done all the time (DATA is a different story). I do not see any problems with "interpretation" of email addresses used in RCPT TO and MAIL FROM commands, and having them split into domain/address sections. Why is that fuzzy logic if the SMTP specification defines a very specific format that addresses must follow?

Why go through the trouble of having to do an RCPT TO callback, when an easier and more lighweight mechanism will do fine (like a LMAP cached DNS query)?

With that said, that does not mean the SMTP server should not offer some
level of control here for "data interpretation."     Like I said before, I
see only some sort of CRC32 checker maybe to be added, but that's it.
The compliant server can not use the CRC32 to make sure the data integrity
is ok.

What the point of having a CRC check? TCP assures an error-free connection and SMIME/PGP can assure integrity with a digital signature?


Yakov Shafranovich / asrg <at>
SolidMatrix Technologies, Inc. / research <at>
"And this too shall come to pass"

Asrg mailing list

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