[Top] [All Lists]

RE: FW: I-D Action: draft-kucherawy-received-state-00.txt

2012-01-12 14:53:27

-----Original Message-----
From: Robert A. Rosenberg [mailto:hal9001(_at_)panix(_dot_)com]
Sent: Thursday, January 12, 2012 11:11 AM
To: Murray S. Kucherawy
Cc: ietf-smtp(_at_)imc(_dot_)org
Subject: RE: FW: I-D Action: draft-kucherawy-received-state-00.txt

I was thinking of checking the message to see if it were possible spam.
You might have some cases where your processing can not do an immediate
SPAM/HAM determination but have some delay in making that decision.
Thus the spam state while the message is delayed while the extended
check is being done.

OK, this makes more sense.  What I'd seen so far suggested using "state spam" 
to indicate that the agent adding the field tagged it as spam.  The intent here 
is to show a transition into a processing state.  The particular impact I'm 
hoping to enable is the ability to see why there was a delay between timestamps.

If however there are extant or possible implementations that actually queue a 
message for spam evaluation by some other agent, and that's a totally separate 
step (even by separate software) than the basic message intake, then it makes 
sense to denote that as a state in this context.

My own experience with various MTA implementations is that spam, virus, and 
other content evaluation is all part of the intake step, before it hits a queue 
where prolonged delay is likely.  That's why this is giving me quite a bit of 

<Prev in Thread] Current Thread [Next in Thread>