I had written ...
| > Procmail freely
| > adds new mail ... by writing the
| > "F" of "From", waiting one second, and then continuing with "rom " and the
| > rest of the From_ line ...
jimd(_at_)saluki-dns2(_dot_)it(_dot_)siu(_dot_)edu responded,
| Ah HA! The above 'write a character, wait a second' action by Procmail
| explains EXACTLY what was happening to mail files that are also handled by
| IPOP3D on our campus-wide mail host.
|
| I kept seeing mailfiles with 'corrupted' "From:" headers in the first two
| notes. The 1st one would be "FFrom:" and the 2nd one would be "rom:".
Well, no. It would happen on the From_ line, not the From: header. You'd
see "FFrom<space>" or just "rom<space>" if this is biting you. If you're
seeing "FFrom:" and "rom:", you have a locking problem (or your MDA is
changing "From " to "From:" in the From_ line, which results in confusion
with the true From: header).
| Now I just need to find a cooperative way to prevent such Procmail
| results, and I can try using it again.
You can recompile procmail without the feature; I think the option in
config.h to uncomment is called NO_USER_ATIME_HACK or something similar.
However, if IPOP3D and procmail were using compatible locking schemes,
it wouldn't happen either.