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

On 10/25/11 9:15 AM, Dave CROCKER wrote:
> On 10/25/2011 9:10 AM, Carl S. Gutekunst wrote:
> > Dave CROCKER wrote:
> > > It would be quite simple to add a Received header field, when a 
> > > message is
> > > placed into a moderation queue, noting that fact.
> > What problem you're trying to address? A mechanism to report any 
> > arbitrary
> > delay, or are you specifically thinking about moderator delays on a 
> > list?
>
> My formulation of the generic issue is to have the Received audit 
> trail mark processing events other than simple smtp exchanges.
Does this mean you want to restrict it to only non-SMTP exchanges, or do 
you mean it should also apply to non-simple SMTP exchanges?
> 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 are caused by greylisting? I think it could help to trace down the 
delay in the delivery of the mail, but I don't see why an SMTP client 
should mark this event in a Received header. It'd be rather marked in a 
'Tried-To-Send' header, or a 'Delayed-By' header.
> My thought is about the generic "internal processing" construct, if it 
> causes meaningful delay, and is not meant to be restricted to the 
> particular case of moderation.
The same is true for greylisting. An important question here is: what 
problem do we want to solve. And who is the intended 'consumer' of these 
Received lines?
An important caveat of using the Received line for this purpose: there 
are quite a number of MTA's which check for the number of Received lines 
in the header of a message; they may hold a message or sideline it when 
the number of Received lines is exceeding a threshold. Adding Received 
lines at various locations for various reasons may interfere with the 
current installed base and configurations in use. Furthermore, I would 
not be suprised if anti-spam software is also checking the number of 
Received lines, in standard or homegrown rules. For example rules in 
SpamAssassin etc.
Another issue might be, that AS software like SpamAssassin parses 
Received lines in order to perform DNSBL and similar lookups. Not sure 
whether adding Received lines may interfere with this common practice.
Using a new header might introduce overhead, but it can prevent 
confusion and it can prevent impact on the installed base of systems 
that use Received lines in some way or another.
/rolf