David MacQuigg wrote:
At 03:02 AM 3/5/2009 -0800, Ned Freed wrote:
So yes, this may be an example of an SMTP relay violating RFC-5321. The
quote above was from a paragraph in 5321 talking about recipient
addresses, however.
The quote in question is from section "2.3.11 Mailbox and address" and
that's under the SMTP terminology heaing. It is in no way specific to
recipient addresses.
OK, if we interpret the MUST in section 2.3.11 to mean all email addresses,
then something should be fixed. The prohibition on SMTP relays changing or
re-interpreting local parts should apply only to recipient addresses.
Changing a Mail From address should be allowed. I do that so as to redirect
any bounces back to my domain where I can deal with them summarily. I
suspend the recipient's account immediately, and wait until he tells me the
problem is fixed. Any other policy could get me on some blacklist.
I think the exchange you are having with Ned hinges on a couple of oints of
disconnection:
1) Implementation versus architecture.
2) Relay vs. Mediator
An implementation can be a mixture of architectural functions. Many
implementations that we think of as "Relays" are actually Mediators -- the mess
with the message and, therefore, take on some significant responsibility for it.
Note, for example, the "Alias" role:
<http://bbiw.net/specifications/draft-crocker-email-arch-11.html#rfc.section.5.1>
This was wrestled with, over the course of the email-arch draft development.
The message is, in fact, delivered to the Alias Mediator. The Alias Mediator
then re-posts the message to the alias address. That this service is typically
implemented in software we generally think of as an MTA is confusing. But for
this function, the MTA is actually a Mediator, not a relay.
SMTP (RFC 5321) makes the distinction between relay and gateway, where I read
the latter as matching the Mediator construct in email-arch. And it is rather
specific about the functional distinctions. What you are describing doing
clearly falls into the camp of gateway/mediator.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net