I'm not sure what context is describe in which "hector" will
comment about this. Our server is a complete MSA/MTA/MDA
system
Yes, that's the point. Keith apparently envisions a system
where the functions MTA (incl. MX) and MSA are separated, so
you can always say "this box follows 2476 rules" (= MSA) and
"this other box follows 2821 rules" (= MTA).
Well, mail submission and relaying are subtly different operations, and
they do need to be treated differently even if they're implemented by
the same code (with occasional if (role==MSA) { ... } else { ... }
constructs). For instance:
- in mail submission it's some desirable to modify a message under some
circumstances (say to add a missing Date field), whereas a mail relay
should preserve the message with as few changes as possible
- in mail submission the client is the originator, in mail relaying the
client is just a random MTA. so authentication means different things
in the two cases.
- the rules for accepting mail are different for submission than for
relaying between mail networks
That's not to say that MSA and MTA have to be separate "boxes" - but we
shouldn't treat them as if they're the same function.
And the "2821-rules" include stuff like "don't mess with the
mail header" (excl. trace header fields for the moment).
or for that matter the message body (modulo 8-to-7 bit conversion)
Since authorization is a prearrange relationship, return path
validation overhead is deemed unnecessary.
If an authorized user can still use any MAIL FROM he likes
you're in trouble as soon as one of your users is a zombie.
eventually I think we need a way for originators to demonstrate that
they have permission to use a particular MAIL FROM, but this requires
protocol extensions will take a while to iron out, and we'd like to get
something less ambitious out the door sooner than that.
also (and this is a separate issue) we need to stop trying to overload
MAIL FROM, From, Sender, etc to be the originator identity. We need a
new concept for that. Sender was close to the right idea but it's been
too widely abused to fix, also it's probably not a good idea to assume
that the originator ID is an email address.
Keith