[Top] [All Lists]

Re: request discussion of two documents on SMTP relaying

2005-06-18 14:30:19

I'm not sure what context is describe in which "hector" will
comment about this.   Our server is a complete MSA/MTA/MDA

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.


<Prev in Thread] Current Thread [Next in Thread>