Just to open a whole new can of worms here...
In all practicality what in my view is the major problem with spam, and
dealing with such email, is that the original SMTP specification (much like
most of the standards in general) were created when the majority of
'internet' use was for academic purposes. Nothing wrong with that.
However, the standards were purposely made to be open, because no one at the
time thought that people would send thousands or millions of messages to
users just because they can.
However, the RFC specifications for internet messaging are very straight
forward, well documented, and when implemented and enforced drastically
reduce the majority of illegitimate emails.
We have seen as time has gone on, that many implementations of MTA/MUA's in
the past five years or so have NOT been following (or at least enforcing)
the RFC standards, people got lazy, programmers never looked, etc., but who
cared, no one was enforcing the standards anyway, and the messages were
accepted and sent, so now, most user bases just expect everything to work as
it has before and continue to use 'broken' implementations of MTA/MUA's,
hacked together 'group' and 'lists' implementations, improper message
header/body formats..., need I go on....?
It is amazing how many problems have gone away (and been created) just by
forcing all messages to conform to the RFC's during the entire SMTP session
from the initial helo to the end of the data command. Everything else that
is left can be reduced by message filtering techniques of various styles.
There are many, many problems out there with mail administrators who also do
not understand the RFC's and mis-configuring there systems, items range from
not accepting and bounce messages (MAIL FROM: <>), using rDNS PTR
verification on HELO information, not accepting <postmaster>, improper DNS
MX/A/CNAME records, etc. There are some things that must be done in certain
ways to conform to the SMTP RFC standards.
Client MUA's are just as bad, default timeout settings too short/long,
sending improper message formats, yada yada yada.
As for what is delivered to a users account and/or if the message is ever
accepted at data time, there are many things that can be done by the MTA to
reduce all kinds of things from email bourne viruses to spam identification
(as much of a moving target that is), from tools such as spam tagging
engines, not accepting any message that contains uncompressed executable
attachments, sender verification, etc.
These are all just tools, use as many or as few as you like, but don't
complain about 'when' a mail-admin does these checks: i.e. if yahoo does
recipient checks at delivery time then who cares, just as long as what they
send and how they send is RFC compliant. They are under no requirement to
make your life easier in verifying a sender address. There is also nothing
they can do about other people saying they are yahoo.com, or sending from a
yahoo.com account. What you can do however is decide exactly what messages
your system is going to accept (if you reject a lot of things because you
find them unacceptable, then don't gripe when someone does not want to
accept email from your server/domain, and don't expect everyone else is
going to be as restrictive as you are).
I suppose that in all of this ranting and raving the point is this...
Everyone is going to need to go back to the agreed upon standards in the
RFC's (not the proposed, in some/most cases, not even the commonly
practiced) at both the MTA and the MUA level for message formats and SMTP
transactions, or else, don't expect other people to accept your messages.
The world has gotten to lose on this and now it is time to go back to the
basics. Messages and SMTP transactions that follow the RFC's make all of
the other peripheral checks much easier.
--EAL--
_________________________________________________________________
Tired of slow downloads and busy signals? Get a high-speed Internet
connection! Comparison-shop your local high-speed providers here.
https://broadband.msn.com
