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
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
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
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> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"And this too shall come to pass"
Asrg mailing list