At 17:17 2002-11-21 -0800, J Wermont wrote:
I have a UNIX shell account and I use procmail to filter all my
mail into separate files for different email lists, etc. Something
I've noticed is that when someone sends out an attachment to an
email to one of my email lists,
FTR, some listservs hose attachments anyway. Traditionally, most lists
have discouraged the use of attachments ('here is my 2MB picture of my
baby, more to come' to 2,000 subscribers is a mammoth waste of bandwidth,
and unless a list *REFUSES* attachments, it can't easily control their use).
the encoding or something is broken on the attachment, so that when I
download it using Eudora (over my PPP account),
Eudora downloads via POP or IMAP. PPP is a dialup protocol (which
basically replaced SLIP and CSLIP), and the mail client is wholly detached
from that protocol, excepting that Eudora can use your PC's networking to
initiate a dialup connection (and even so, Eudora doesn't implement the
protocol itself).
I regularly download email via Eudora, from mailboxes filtered by procmail
- most messages are even _modified_ by procmail, and I've had no
procmail-induced problems which weren't directly tied to a fsk'd-up recipe.
I just get the garbagy encoded file rather than
the Word file or jpg or whatever.
try:
:0c
$DEFAULT
BEFORE any of your other recipes and see if that changes anything. You'll
get two copies of messages, but you wouldn't run this for long - just fire
off a test message at your account with an attachment, then check mail and
see if both of them are hosed, or if just one is. If only one is, then
something *IN* your .procmailrc is hosed and you should work to identify
it. If both are, you should then try disabling your .procmailrc entirely
('mv .procmailrc .procmailrc.disabled', but then, if you invoke from a
.forward, you may need to tweak that instead) and repeat the test - if it's
STILL hosed, then the problem probably rests with your POP/IMAP daemon,
your MTA, or a problem with how your procmail is configured as LDA (if it
even is, and I rather doubt that is the problem), or something else - but
once you've removed procmail from the equation, you'll at least know where
NOT to look.
FTR, it is generally useful if you identify what version of procmail you
are running.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail