Given you can't get these sites to update that software now, how do we
fix this without their cooperation?
That this problem with outdated software will exist no matter what
solution is used (unless its designing new protocol). But once some
solution or protocol extension is widely accepted, receiving mail server
or end user can use the fact that email is received from outdated system
as additional filter to determine if its spam or not with outdated email
server making it say twice more likely that its spam...
But in either case we do need to keep in mind that simpler solutions are
easier and faster to implement, the question becomes how effective this is.
Also I want to point out that while current RFCs (I believe its RFC822)
say that email has to be accepted no matter what headers, what are Mail TO
and FROM are and how it came to the system, this is no longer true in
practical terms for more then 50% of the email servers. So this particular
part of the RFC is de-facto history... and should not be used for any new
design or rfc.
P.S. It would be usefull to actually list all parts of current mail rfcs
that are puroposely not supported either in implimentation or operation of
large number or majority of active mail servers.
One way, frankly, would be to make a decision to no longer accept email
from sites running these ancient versions of the software, a variation
of the current black holes. Might not be a bad thing to consider: it's
easier than a relay check, and sites could then sign up and simply say
"we won't accept email from broken sites any longer".
any other ideas?
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg