Though Monday was not an officiall xmpp meeting date, some of us had a
brief chat. Here is a follow-up to something I mentioned on the marid
channel.
This is the RFC that defines "Message Submission" or "MSA" and specifies
that port 587 should be used for this.
http://www.ietf.org/rfc/rfc2476.txt
The reason I mentioned it was that I think referring to this previous RFC
will lend a lot of strength to our own RFC/Draft. This previous RFC
(December 1998) reinforces the idea that MUAs should submit their mail to a
local MSA, and the MSA has some responsibilities for 1. checking
authorization, correctness, etc, and 2. adding data where it is missing.
Then, the message begins its journey to the next MTA in line.
This is good for us because it actually relaxes some of the requirements
for the MUA when submitting, and specifies that the MSA may accept some
things that a relay MTA might not (like missing Message-Id: for example).
Thus we have some kind of precedent if we want to state that MTAs should do
a certain thing when talking to other MTAs, but that it may not apply to
MSAs talking to (hopefully locally-authorized) MUAs. For example, we might
say "HELO name must be a FQDN and use of a non-FQDN for HELO is deprecated"
-- but MUAs could be exempted.
Here is another part of it that is good for us. RFC2476 states this:
If an MSA is not able to determine a return path to the submitting
user, from a valid MAIL FROM, a valid source IP address, or based on
authenticated identity, then the MSA SHOULD immediately reject the
message. A message can be immediately rejected by returning a 550
code to the MAIL FROM command.
Basically, that means that the MSA is responsible for verifying that the
return path and the locally-known-user match up, and that user is
authorized to send mail using that return path. This will come in handy
later, possibly, because it means that accepting a bogus return-path from a
local user is not appropriate, not just because WE say, but based on a
long-standing RFC.
Here is yet another positive thing we can use:
The MSA MAY add or replace the 'Sender' field, if the identity of the
sender is known and this is not given in the 'From' field.
The MSA MUST ensure that any address it places in a 'Sender' field is
in fact a valid mail address.
Another note from our brief chat. I have a general sense of "paralyzing
fear" when discussion turns to not supporting something that has been
working in the past. Some amount of fear is healthy, but at the same time
we can't fix the forgery problem by changing nothing.
So we have a requirement for change, but we don't necessarily have to break
a lot of stuff "right out of the gate." Instead of drafting something that
says "Stop doing X right now" it might be more acceptable to people if we
say "X is deprecated. Please start doing Y instead."
In other words, the day before our draft becomes RFC will be very similar
to the day after. Nobody here is out to kick all mobile users in the head.
As we lay out proposals, there will be some implications to certain groups
(mobile users, greeting cards, forwarders, mailing lists, newsletters, etc)
and we don't necessarily have to solve all of them in order to talk about
the idea -- we may not even *know* all the implications right now. A
working group is actual *work* and this is part of it. There will be tough
problems, and there will be creative solutions coming from unexpected
places.
Anyway... we should feel comfortable amongst ourselves to make suggestions
for stuff that is "to be deprecated"... *especially* if it is something
already supported by another RFC. Don't Panic. :)
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>