[Top] [All Lists]

Re: Received header field for special processing, such as "held for moderation".

2011-10-25 11:22:11

--On Tuesday, October 25, 2011 14:00 +0200 Dave CROCKER
<dhc(_at_)dcrocker(_dot_)net> wrote:

For example, sometimes a header field is added for the
mailing list module's processing. The proposal is for
yet-another Received field if the MLM decides to hold for
moderation (or whatever.)

Another example is greylisting: should a sending SMTP client
mark events that

Greylisting generates an SMTP reply code, whether distinctive
or not.  Strictly speaking, the message does not enter a new
queue.  It merely stays in the transmission queue it was
already in.

But certainly there would be nothing wrong with the added
Received logging, modulo the looping count check that's
already been mentioned.


Back in the days of gateways that needed to do lots of
processing, the informal guideline (i.e., oral tradition) was
that it was desirable for an MTA to add a trace field each time
it did something with/to the message, whether that was an
authority handoff, a transformation of either message or
addressing, or some action that caused or documented a delay.
We still see much the same thing with mailing lists, where we
have one trace field for receiving the message and another for
handoff to the list exploder, even if it is on the same host. As
long as those fields are consistent with the syntax in 5321 and
a little good sense, they are certainly permitted.  For a
variety of reasons including the loop count issue to which Dave
refers, I think requiring them would be a bad idea.

Starting to add more types of trace fields has a lot of appeal
but we haven't done well with ideas like that in the past.  They
raise important design issues about ordering (there is a bit of
history of filtering arrangements treating messages with
material inserted among the Received fields as bogus) and
require additional work.