anti-spam false positive ... egad, that was annoying to track down ...
So ... got posting failure(s), e.g. (slightly trimmed):
----- Forwarded message from MAILER-DAEMON ----- ----- The following addresses had permanent fatal errors ----- balug-announce@temp.balug.org (reason: 550-Rejected message body text: URL link to prohibited file:) ----- Transcript of session follows ----- ... while talking to mx.temp.balug.org.:
DATA
<<< 550-Rejected message body text: URL link to prohibited file: <<< 550-http://search.cpan.org/~oalders/WWW-Mechanize-1.86/lib/WWW/Mechanize.pm <<< 550-. <<< 550-[EximConfig-2.5-temp.balug.org-Body-Reject] <<< 550-. <<< 550-.Verify: verified-32928-balug-announce@temp.balug.org <<< 550-Contact: postmaster@temp.balug.org <<< 550-. <<< 550-Sorry, your message has been rejected because <<< 550-its body text/content is prohibited for the <<< 550-above reason. <<< 550-. <<< 550-We apologise if you have sent a legitimate <<< 550-message and it has been blocked. If this is <<< 550-the case, please re-send adding verified-32928- <<< 550-to the beginning of the E-mail address of each <<< 550-recipient. If you do this, your message will <<< 550-get through these restrictions. <<< 550-. <<< 550-If your message has been incorrectly blocked, <<< 550-please let us know at the above contact address. <<< 550 . 554 5.0.0 Service unavailable ----- End forwarded message -----
/var/log/exmi4/rejectlog: rejected after DATA: Message body matched in /etc/exim4/eximconfig/reject/body (URL link to prohibited file: http://search.cpan.org/~oalders/WWW-Mechanize-1.86/lib/WWW/Mechanize.pm)
well ... misleading diagnostic ... not at all triggered from /etc/exim4/eximconfig/reject/body ... in fact fully commenting out everything in there (and config reloaded and such) - and it was still getting rejected in exact same manner
Anyway, dug backwards from the diagnostic message, etc. ... eventually traced it back to: $ cat /etc/exim4/eximconfig/accept/attachment_executable_body # List of executable file types that will be excluded from blocking in # http:// URL links present in body text. For example, extensions used # by server-side scripting. # For blocked executables, see: reject/attachment_executable_inbound eml|js|pl|pm $ Had to add the pm in there for it to not reject body containing URL ending in .pm
Also found it was inconsistent in rejecting such a URL ... somewhat different manners of emailing/encoding - and sometimes it wouldn't reject it.
The verified- addresses also seem not-so-useful. Thus far every time I've tried such, messages still fail in exact same manner.