Hi,
[repost from yesterday, I was not using the correct From address for this
list...]
Yes, it means that every Received: header in an email is valid with a
valid IP, valid configuration (whatever that is deemed to be), and valid
DNS. Only servers that were correctly classified as mailservers would
even be able to be verified. Mailservers that were spam sources would be
easily identified and blacklisted across the board. Or something.
I am a bit lost here. Are you saying that right now the *main* problem
with spam is "source spoofing" and that just by having a strict format for
emails in the protocole we would turn the whole spam fighting industry
into a single huge database of "known spammers" ?
If it were true, I think it still raises a few issues. First, not all
providers agree to implement SPF currently. One of the reasons being that
I am [EDIT: usually !!] using a totally legitimate @wanadoo.fr address but
I am not currently connected through their network. So basically all
providers would have to issue SSL certificates for all their clients that
could be of course stolen by malware etc. and become "legit". What I mean
is that the very first step of email sending between my favorite mail
reader and the SMTP/IMAP server would still be a weak point (Like we say
in French "l'enemi, c'est l'utilisateur" i.e. "the end-used is the
enemy/the source of all evil"). And I am not even talking about all the
email domains that are not ISPs such as hotmail or yahoo and the like: you
can secure all the way from their server to yours, it will never prevent
the "garbage in - garbage out" approach.
Second, I am not aware of any lawsuits yet against RBLs but I am quite
surprised no "official spammer" has already done that, or tried direct
attacks targeted at the RBLs servers: they have enough zombies to spam, so
they could.
Furthermore, let me be the devil's advocate for a second: would not you
agree that many a rule in SA can actually catch spam because they are RFC
compliant but stupid enough to add fancy headers or fancy header
formatting ?
> Putting this on a distinct port seems more a marketing thing. Why not
> add it as a capability in a normal SMTP server?
Because the idea is to be able to simply retire the current SMTP and
that will be a lot simpler if the new service is on a new port.
I would agree to that. Http already does (i.e. port 8080 vs port 80), it
would facilitate migration.
A secure verifiable delivery chain from server to server would almost
completely eliminate the need for SA.
I can not agree to that. The point of entry has to be secured and I am
afraid it will be a pain to do so.
And I'm not saying it would be easy, or happen over-night. I figure if
people started working on an RFC right now we might see the end of the
current SMTP in 15-20 years unless there was a huge push in which case
it could maybe happen in 10-15 years.
Might be. We have been talking over and over about IPV6 for about 15 years
now, and currently it only incurs problems between compliant and
non-compliant equipmentswith zero gain.
I'm not saying it would ELIMINATE Spam, but it would certainly reduce it
to a manageable level.
Having an authenticated chain can only help if it is not broken or if we
can detect it was broken, otherwise it will have the reverse effect of
spammers injecting massive spam into "trusted" network chains that can not
be banned for fear of hitting legit users.
Nothing we're doing now is reducing it at all, the amount of spam has
been increasing steadily every year since the very first Green Card
posting to USENET.
Amen to that.
To come back (a little) to the original post, IMHO we can not and should
not do without specs i.e. RFCs. THe existing ones are not that bad, I sent
my firts emails back in 1992 with my mom's address, so these RFCs have
made the world communicate (for better and worse) for 20 years. Back at
the time, the bandwith was so low and email access so controlled (add to
that a tiny bit of optimism about the kind human nature) that spam was not
an issue. A new RFC can be needed, but I really can not believe its main
improvement would be protocole formatting...
HTH
JG
