Red Hat Bugzilla – Bug 218018
Review Request: spampd - Transparent SMTP/LMTP proxy filter using spamassassin
Last modified: 2013-12-17 08:26:48 EST
Spec URL: http://ftp.es6.freshrpms.net/tmp/extras/spampd.spec
SRPM URL: http://ftp.es6.freshrpms.net/tmp/extras/spampd-2.30-2.src.rpm
Spampd is a program used within an e-mail delivery system to scan messages for
possible Unsolicited Commercial E-mail (UCE, aka spam) content. It uses
SpamAssassin (SA) to do the actual message scanning. Spampd acts as a
transparent SMTP/LMTP proxy between two mail servers, and during the
transaction it passes the mail through SA. If SA decides the mail could be
spam, then spampd will ask SA to add some headers and a report to the message
indicating it's spam and why.
Unofficial review as I am just a contributor.
rpmlint gives two warnings on the src.rpm
W: spampd strange-permission spampd.init 0744
W: spampd setup-not-quiet
First one can be ignored, second one can be silenced adding -q to %setup
rpmlint gives the following on the binary:
E: spampd non-standard-uid /var/spool/spampd spampd
E: spampd non-standard-gid /var/spool/spampd spampd
E: spampd non-standard-dir-perm /var/spool/spampd 0750
These can be safely ignored, the daemon runs as (newly created) user spamd
W: spampd no-reload-entry /etc/rc.d/init.d/spampd
Can be ignored
W: spampd incoherent-subsys /etc/rc.d/init.d/spampd $prog
This one can be ignored, it is triggered by usage of the shell variable $prog
for "spampd" in the script
Not a blocker: BuildRoot is not the one recommended at
- package meets naming guidelines
- package meets packaging guidelines
- license is GPL, as mentioned on the upstream project page. However it is not
included in the tar.gz, so upstream SHOULD be bugged to included it; for the
time being, the license is (correctly) not included in %doc
- spec file legible, in am. english
- source matches upstream (742c6f2cb75db54e59d044a8ee40445f spampd-2.30.tar.gz)
- package compiles in mock on i386 and x86_64 architectures
- no missing BR
- no unnecessary BR
- no locales
- not relocatable
- owns all files and directories that it creates
- no duplicate files
- permissions ok
- %clean ok
- macro use consistent
- code, not content
- no need for -docs
- nothing in %doc affects runtime
- not a GUI so no need for .desktop file
- not a devel package, no header / static libraries / .la / .pc files
- no need for post/postun ldconfig
- service is added to list of services but not started by default and also
removed at uninstallation time
- all pre/post scripts are sane
I guess that someone with more power then me should APPROVE it, especially if
you silence the %setup stage.
As a personal question: why is the initial rpm release labeled -2 ?
Isn't anyone interested in making a formal review of this package? :-(
Why was it put as NEEDINFO? I don't see any needed info... silencing %setup is
trivial an non-mandatory, and the BuildRoot is the one I use. For anything else,
It looked to me as a forgotten package, because there was no reaction, so I have
put the status to NEEDINFO. And I will do the formal review.
There is a small typo in the "pre" script - /dev/nulll vs. /dev/null
In all other points I agree with Manuel, so with the typo fixed there are no
blockers and the package is APPROVED
I'd love to have this on my mail server...
The pacakge looks good, but I think you should fix line 55 ( s/nulll/null/ ) and
as suggested in:
Thanks! You can quickly check the latest package if you want, just in case :
- Fixed spampd.init mode to 755
- Fixed type in %pre (/dev/nulll)
- Silenced the %setup step
- Add scriplet chkconfig and service requirements
Note that I've been running this in production since November... works great for me!
Package Change Request
Package Name: spampd
I have requested commit access to this package in order to fix bugs #1038388 and #678137. In addition, the patches will convert this package to systemd.
Could you please add me to the list of committers. I have not had any reply from the maintainer or on the devel list.
This is handled in pkgdb.
(In reply to Jon Ciesla from comment #8)
> This is handled in pkgdb.
I am aware of that. Fedora wiki says that it is OK to involve admin when the maintainer is unresponsive.
Also, I have already submitted commit requests in pkgdb.