Some Exchange systems wrap lines over 75 characters long while converting
messages to quoted-printable, preventing ctm_rmail from reassembling
emailed deltas. For a negligible loss of encoding efficiency, this change
allows ctm deltas to once more pass through Exchange undamaged.
I am the maintainer of CTM. There is a problem that when very large deltas
are created, that the program ctm_smail, which is responsible for mailing
the deltas out, will instead create a single message that says the delta
is too large. However, if the -q option is set, instead of placing this
message in the queue (as it would have done with the deltas), it mails it
out directly. This conflicts with the current working of CTM in that the
email address is set as %%REPLACE-ME%% so that the created mailing pieces
can be signed by gnu-pgp, and then have the mailing address changed.
This fix means that if the -q option is set, and the delta is too large,
the "too large" message is placed in the queue.
Also, I made the "too large" message a little more up to date.
Submitted by: Stephen Montgomery-Smith <stephen@math.missouri.edu>
PR: bin/50328
MFC After: 2 weeks
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
- add ctm_conf.gnats from freefall
- add support for doing both the immediate mailout and the queued mailout.
- use "sendmail -odq -t" rather than "sendamil -t" to make it queue to
the mailqueue rather than immediately begin transmission. This allows
us to take advantage of our ordered dequeueing system without blowing
WC's T1 to hell with a 50 part mailout in parallel.
- bump the max ctm size from 3MB to 10MB.... This is mainly for the fast
list.
of delta's to be mailed out every hour (or however often you schedule
the cron job).
ctm_dequeue is the cron job which takes the stuff from the
queue directory and punts it into sendmail. The chunks of
the deltas (and the complete deltas if they are that small)
are sorted into order before being dispatched, so the people
subscribing should still get the bits in the right order.
The changes to ctm_smail should be fairly safe as they won't be
activated unless you go for the new queue directory option.
