Re: Interaction of reformail -D with EX_TEMP FAIL

This is a MIME GnuPG-signed message.  If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--===============8261188647520195415==
Content-Type: multipart/signed;
    boundary="=_ripper.email-scan.com-1599348-1773143809-0001";
    micalg=pgp-sha1; protocol="application/pgp-signature"
Content-Transfer-Encoding: 8bit

This is a MIME GnuPG-signed message.  If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--=_ripper.email-scan.com-1599348-1773143809-0001
Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Julian Gilbey writes:

> Hello!
>
> I'm using maildrop, and I have lines early in my .mailfilter which
> read:
>
> # Drop duplicate emails
> `reformail -D 10000 $HOME/var/maildrop/seen-msgids`
> if ($RETURNCODE == 0)
> {
>   to "Mail/spool.duplicates"
> }
>
> which should work great.  For some reason, messages are occasionally
> being rejected with error code 75 (EX_TEMPFAIL) for no obvious reason,
> and are then successfully delivered on a second attempt.  But one
> consequence is that they are passed through maildrop twice, and they
> got at least this far in the .mailfilter file the first time, because
> the second time through, the msgid has already been seen, and so the
> message is regarded as a duplicate.  (Good job I'm saving these
> messages rather than discarding them!)
>
> Is there any straightforward way of handling this strange situation
> with maildrop, that is, to ensure that an EX_TEMPFAIL doesn't leave a
> trace in the seen-msgids file?

When solving an XY problem, the correct approach is to solve the X, that is  
determine why mail delivery fails with an EX_TEMPFAIL, instead of solving  
the Y, figuring out a way to try again.

Presuming that you don't see anything in syslog or maillog, as a measure of  
last resort, one could invoke maildrop under strace:

| strace -s 256 -o /var/tmp/maildrop.strace.$$ maildrop

Another script needs to be run periodically by cron, to clean up old log  
files and keep /var/tmp from filling up. Then, once a mail delivery fails,  
grep the strace files for the "exit" code, find the one that corresponds to  
the failed delivery, and investigate further.


--=_ripper.email-scan.com-1599348-1773143809-0001
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQRupkKLJP96aW75pIOKYPgoojZS4gUCabAHAQAKCRCKYPgoojZS
4rCbAQC940zrcwEALbKl9OD2YMV+ie+QtLq9nRgSgn8T3M8H3AD+K2ImSP60nrKA
5u259wTlMeJP+wQ1w2k/U2XgAnTudwo=
=/xIw
-----END PGP SIGNATURE-----

--=_ripper.email-scan.com-1599348-1773143809-0001--


--===============8261188647520195415==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============8261188647520195415==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Courier-maildrop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/courier-maildrop

--===============8261188647520195415==--