fetchmail-friends
[Top] [All Lists]

Re: [fetchmail] Re: bouncing on empty return-path

2003-01-10 04:57:37
Sunil Shetye <shetye(_at_)bombay(_dot_)retortsoft(_dot_)com> writes:

Quoting from Matthias Andree's mail on Fri, Jan 10, 2003 at 04:23:10AM +0100:
1. do we want to bounce on MDA issues or just retry or what do we do?

Yes, fetchmail should bounce. Atleast for specific exit codes.

I think we agree it should not bounce for EX_TEMPFAIL (see sysexits.h).

2. if we bounce, do we use the MDA, require an MTA, or try SMTP?
   the MDA would be rather a notification service (rather than bounce)
   if it's e. g. procmail.

An MTA option seems to be a good solution. Fallback would be SMTP?

I don't like fallbacks, they always make up for astonishment.

I'd rather think that the "mta" option could either be a command (if it
starts with /, such as /usr/sbin/sendmail -f %F %T) or it could be a
protocol token such as SMTP or SMTP:next_hop or SMTP:next_hop,port (I
suggest the comma to separate the port to avoid clashes with IPv6
address notation that uses a colon.)

(Before someone speaks up quoting sendmail(8) about dead.letter, it says
"if the sender is local to this machine". %F however will usually NOT be
local to the machine, so no dead.letter will be saved.)

3. (not directly related:) can we make sure MDA has only ever one
   recipient for %T in multidrop? An option (default 1) to allow more
   than one recipient might be OK for sendmail, but it's not suitable
   for maildrop or procmail.

Specifying more than one recipient would mean that fetchmail will not
know for which of the recipients the mail has been rejected. I think,
fetchmail should send to only one recipient at one time. I
guess, this would require that the whole mail be saved in a file and
then used for delivering to each recipient.

"file" should be "RAM" for mails below a configurable limit (say 64 k
which is 27% of fetchmail's in-core size on my machine). There's no
point in saving temporary files of like 3 kByte, some file systems,
notably traditional ffs or logging ufs, are way too slow. mfs or tmpfs
or ramdisks would be ok though.

-- 
Matthias Andree