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.
THat's a distinction that exists in the email architecture document only. RFC
5321 doesn't follow this convention, preferring instead the older relay vs
gateway distrinction.
The problem with the old relay versus gateway distinction is that it is so
coarse grained that if you use it as a loophole for every implementation that,
say, does case-insensitive address comparisons, you quickly find that
everything is a gateway and you've spent a huge amount of time specifying
precise behavior for essentially nothing.
(This reminds me of an amusing math story. A few years back a bunch of papers
were written about a particular family of sets, sorry, I forget the exact set
of properties but it included paracompact and maybe semimetrizable. Then along
came a paper that proved the only set in the family was the empty set. Oops.)
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.
I agree it falls into the mediator category. But it if falls into RFC 5321
gateway category, it ends up dragging almost everything else in there with it.
And we're left with a document that goes to enormous trouble to specify
behavior something that for all intents and purposes doesn't exist.
Ned