Re: Q: RCPT Check by acting as a mailproxy?
Hugo Monteiro <hugo.monteiro <at> fct.unl.pt>
2008-06-03 11:24:49 GMT
John Simpson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On 2008-06-01, at 1722, Hugo Monteiro wrote:
>> All that said, i'm starting to think about:
>> - Alter Soffian's patch to set two other env vars. HELO and MSGSIZE
>> (or similar)
> i've just added it to my combined patch. i took your suggestion and
> added a HELO variable to my version- it was literally one line added
> to the patch. thanks for the idea.
I'm very happy to see you decided to include Soffian's patch in yours,
plus the the HELO setting and stdout redirection. =)
> however, i don't think a MSGSIZE variable would be possible (unless
> i'm not understanding what you mean.) remember that the program is
> called after the client sends a RCPT command. at this point in the
> SMTP conversation, the message itself hasn't been sent so the size is
> not known (unless the client added a SIZE= extension to their MAIL
> command, and that number may or may not be accurate.)
I should have clarified that i was in fact referring to the SIZE= ESMTP
extension. I'm aware that the message SIZE advertisement is voluntary
and might not even be correct. However, I believe that if the client
decides to advertise such value, it's the clients responsability if the
message doesn't get accepted because it's providing wrong information.
The goal in incorporating that information, in my perspective, is to
save server resources in the case that the client wants to cooperate and
the message is actually larger that the "allowed" size.
>> - Write a program that does the recipient checking in the usual
>> places (~qmail/users/assign, /etc/aliases.cdb - a la fastforward, dot
>> qmail files in ~alias), custom cdb file, ldap and mysql. The program
>> could be configured to return success on the first match or go
>> through all the defined backends (multiple backends would be
>> supported). More details on this one below.
> so... in order to save one syscall within qmail-smtpd, you're adding
> fork/exec to run another program, plus however many syscalls that
> other program does to read all of these files, while qmail-smtpd is
> waiting for the external program to finish.
> to me it doesn't sound like you're actually saving any CPU cycles.
> you list "custom cdb file" as one of your options... why not have that
> as your ONLY option, and only spend the CPU cycles needed for checking
> all of these other sources, when you rebuild that cdb file?
> personally, the only reason i added the RCPTCHECK patch to my own is
> that i plan to set up 3-tuple greylisting with it. and while i could
> easily add a validrcptto.cdb check to such a program, i still think it
> makes more sense to do the check within qmail-smtpd, since it's only a
> stat() and open() when the program starts, and no more than two
> seek()/read() calls per RCPT command.
> plus as kyle said, it opens the doors to so many other potential uses
> in the future...
Indeed the cdb file lookup could (and should) be done inside
qmail-smtpd. The main reason why i said the external program would
support such lookups is because i would also like be see the "usual
places" looked up, such as:
1 - system users - this can be easily done with a getpwnam() call and a
3 or 4 more lines for logic.
2 - /var/qmail/users/cdb (built from the assign file) - The cdb lookup
code could be used here also, with some minor tweaks since the key
layout isn't exactly the as values to match. One could also add the
check for the referenced ~alias/.qmail files, for sanity checking, but i
think that it might not be worth the trouble.
3 - /etc/aliases.cdb (used with fastforward) - Again the cdb lookup code
and again with some minor changes since the key layout also differs.
If you feel confortable adding support for this in your patch, I won't
have second thoughts about starting using it =)
As for Kyle's suggestion regarding mailman lists. That could either be
done by stat()'ing the list directory name in the mailman installation
(eg. /var/lib/mailman/lists/). The problem is that there are a lot of
other associated addresses, such as -owner, -subscribe, etc.
There is already an easy way for doing this, i think. In my
qmail+mailman installations i always found easier to pipe -default
entries in the ~qmail/users/assign file to the mailman
qmail-to-mailman.py script. That way lists are automagically set up once
i just define something like in the assign file.
And have a general ~alias/.qmail-mlists like
|preline /usr/bin/python /usr/lib/mailman/bin/qmail-to-mailman.py
Comments are most welcomed.
ci.fct.unl.pt:~# cat .signature
Email : hugo.monteiro <at> fct.unl.pt
Telefone : +351 212948300 Ext.15307
Centro de Informática
Faculdade de Ciências e Tecnologia da
Universidade Nova de Lisboa
Quinta da Torre 2829-516 Caparica Portugal
Telefone: +351 212948596 Fax: +351 212948548
www.ci.fct.unl.pt apoio <at> fct.unl.pt