ietf-smtp
[Top] [All Lists]

[john Re: comments on draft-klensin-rfc2821bis-00]

2005-09-09 05:00:27


I wrote this to John:

2.3.1
    originator address (to which error reports should be
directed)

There seems to be much debate on this.  For instance: Who is
originator when the .forward mechanism is used?  See also
2.3.8

And John replied:

And how, and why, would you propose to discuss ".forward" in
an MTA document?   It is a non-standard (even if common)
feature applied after what as far as the SMTP model is
concerned is final delivery.  Again, suggestions like this
would be easier to evaluate if you supplied specific text you
would like to see inserted.

Clearly John and I are on the same side here. .forward is
something that happens after final delivery.  Many people
believe this is not the case, they do not read their mail
at that point, they forward it elsewhere, hence it is not
final<< delivery.  (Again, I disagree with them).

In SPF-discussions it happens more than once that people talk
about the "SPF breaks forwarding" problem.  Let's not go down
that road here, but let's do define clearly what an originator
is, when a certain address can be (re)used and when not.
The debate on this alleged problem comes down to people having
another idea about rfc(2)821(bis) than other people.

I do not want to fight the SPF-battle here. I'm merely pointing
out that the current text leaves room for interpretation.

The .forward case seems to be quite clear.  Yet, others
disagree -strongly- with this and feel they have the right
to reuse the original originator when they send (forward) mail.

Other cases are less clear.  What if in stead of .forward equal
results are reached by means of alias tables (or equivalent)
from within the MTA process?  What about procmail (called by
the MTA)? (people, these are rhetorical questions...)

There seem to be multiple challenges here.  The first task is
to define precisely what is meant by "originator". The next task
is to find wording to describe it in the RFC.  This should then
result in an unambiguous definition.

This is how I feel about the subject:

As long as both sender and recipient stay the same, the message
is transfered.  As soon as the recipient is changed, one way or
another, things get tricky.

Change only the left-hand side, for instance to allow delivery
to a new address for the same mailbox within the same organization.
In this case, there is no need to alter the originator.  The
message is delivered to the same mailbox at the same place, no
rerouting needs to occur.

Change the right-hand side and we're talking about something
quite different.  In this case I believe alias expansion (as
discussed in rfc2821bis 3.9.1) does not apply.  Mail is not
delivered to the same mailbox.  Sure, it may be delivered to
the same person but we're talking mailboxes, not people here.

Can we discuss this first before trying to change the text in
the RFC?

regards
alex

<Prev in Thread] Current Thread [Next in Thread>
  • [john Re: comments on draft-klensin-rfc2821bis-00], Alex van den Bogaerdt <=