[Top] [All Lists]

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

2011-10-25 06:19:17

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.