On 30-Mar-2009, at 19:58, Kenneth Porter wrote:
On Monday, March 30, 2009 2:13 PM -0600 LuKreme <krem...@kreme.com>
wrote:
The changes (RFC2822) did not change enough. What is really needed
is
SoSMTP (Son of SMTP) defined for port 26. It would be 8bit
compatible
and would NOT be backward compatible with current SMTP. It would not
have folding of headers lines and it would have exact standards on
every
header (the precise format of every date, for example). Any
message that
failed to be to the standards would be rejected for transfer on
port 26.
Of course, it would require a valid SASL chain on all servers from
source
to destination.
Ah, yes: SMTP is 7-bit and line-oriented, and those contributed to
the faults in RFC2822. Allowing 8-bit and unlimited line length
would largely eliminate the encoding and wrapping issues that the
video covers.
I don't know what SASL addresses. Does it somehow eliminate
anonymity of the sending server?
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.
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. It
will also be much easier to justify.
"Yes, Mr. CEO the figures are Mail inbound on port 25 is 98% spam,
mail on port 26 is 3% spam. We still get 200 mails a week on port 25
that are valid, but 18,000 on port 26."
"Well boys, I think it might be time to close down that gaping spam
hole in our network and save a few $100K in bandwidth costs next year
so I can get my $100,000,000 bonus check."
Messages that advertise strict compliance and pass a validator could
be given a suitable negative "reward" score by SA. (Probably a batch
of meta scores that null out some normal rules that invalid messages
would be subject to.)
A secure verifiable delivery chain from server to server would almost
completely eliminate the need for SA.
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.
I'm not saying it would ELIMINATE Spam, but it would certainly reduce
it to a manageable level. 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.
--
Far away, across the fields, the tolling of the iron bell calls the
faithful to their knees to hear the softly spoken magic spells.
