You have not yet begun to try my patience. :)
I guess I just don't understand the full difference between the way you think
of whitelisting and authentication. Here's how I think of them:
When I have a machine (e.g. a web server) that needs to send mail using
my mail server without being blocked, I whitelist it. That bypasses all of the
spam filters and allows the remote machine to send email to remote recipients
(relaying). In the absence of spamdyke, I would add that machine's IP address
to my /etc/tcp.smtp file instead.
When I have a user who travels around with his laptop and needs to send
email through my server to remote recipients, I ask him to authenticate. That
bypasses the spam filters and allows him to send to remote recipients
(relaying). In the absence of spamdyke, I would need a patched version of
qmail.
When I have a legitimate sender who is trying to reach one of my users
but is being blocked by a filter, I whitelist him. That bypasses all of the
spam filters. Depending on how I whitelisted him, it may allow him to send to
remote recipients.
Perhaps the last scenario is the problem you're describing -- if I add the
sender to a global whitelist (e.g. not using a configuration directory), this
sender can now use my server as a (nearly) open relay. If I added him by IP or
rDNS, he could use any sender address he wanted (fully open relay). If I added
him by sender address or sender domain, he could only relay if he used the
whitelisted sender address. If I added him by sender address using a
configuration directory so it only affects the recipient's domain, he can't
relay at all.
I guess that could be considered a problem, except for a few considerations.
First, I don't (as I assume you don't) just whitelist anyone who asks -- one of
my users has to make the request. Then I ask the sender to fix the problem
that caused the rejection. I often find that senders who are having trouble
reaching my users are also having problems reaching lots of other people too --
i.e. they've been blacklisted somewhere or they have no rDNS. Second, I very
rarely use the global whitelists. I prefer to whitelist a sender's domain
within a configuration directory for the recipient's domain. That effectively
allows anyone in the sender domain to send to anyone in the recipient domain.
It prevents relaying and it also prevents them from spamming anyone else on the
server (e.g. me). Third, I have trouble picturing a spammer using this route
to gain access to a server. They'd have to contact one of my users somehow,
convince them they are legitimate, convince them they are being blocked and ask
the user to ask me to whitelist them. If I used the global whitelist, they'd
be able to relay until I caught them and removed the whitelist entry.
Anything's possible of course, but that seems a little farfetched to me.
As for adding headers to messages, I've often considered it. I think it would
be handy to have spamdyke insert a header that gave the real envelope sender
and envelope recipient addresses, since sometimes that's hard to figure out.
I've often thought it would be interesting to add a "would have been blocked
by" header to show which filters /could/ have stopped the message but didn't.
This would be useful for administrators who are considering enabling a filter
but aren't sure how many messages it would block. spamdyke could also add a
header if the message was accepted due to a whitelist entry. I haven't done
anything with these ideas yet because I've always felt there were bigger fish
to fry. But now that I've added the header blacklist, spamdyke understands how
to parse message headers. Inserting new ones wouldn't be very hard.
-- Sam Clippinger
On Jul 25, 2012, at 10:15 PM, Eric Shubert wrote:
> On 07/25/2012 12:28 PM, Sam Clippinger wrote:
>> Well, "enough information" in this case refers to the options you're used in
>> the configuration file. If spamdyke knows what domains it controls
>> (local-domains-file or local-domains-entry) and knows the relaying rules
>> (access-file), it has enough information to control relaying and it sets
>> RELAYCLIENT.
>>
>> Changing a process' environment variables after the process has started is
>> impossible. As for starting qmail-smtpd after authentication, I suppose
>> nothing is absolutely impossible, but it would be difficult. Very
>> difficult, given spamdyke's current code structure.
>>
>> In order to start qmail-smtpd after authentication, spamdyke would have to
>> cache the entire SMTP conversation until that point, then start qmail-smtpd
>> and replay it. That would mean spamdyke would have to fake two parts of the
>> conversation: it would have to send its own greeting banner and it would
>> have to send its own list of capabilities. The greeting banner isn't a big
>> deal, it's almost always ignored by mail clients as long it contains at
>> least some text. The capabilities list is important, however. That's how
>> the server tells the client whether it supports authentication (and what
>> protocols it uses), TLS, pipelining and other stuff. spamdyke wouldn't know
>> what to say except for authentication and TLS, if they were configured.
>> That would effectively remove features from the mail
>> server, since clients wouldn't know they were supported.
>>
>> Also, if this delay is added for authentication, I think it should probably
>> also be added for the other filters as well. For example, if the recipient
>> address could possibly be whitelisted, spamdyke should delay starting
>> qmail-smtpd until it knows for sure. If the address isn't on a whitelist,
>> there's no point in setting RELAYCLIENT. (The same is true of the sender
>> whitelist.) But that's even more problematic, because now spamdyke is
>> caching a huge part of the SMTP conversation without knowing what
>> qmail-smtpd's real responses will be. For example, if qmail-smtpd has been
>> patched to do recipient validation or quota enforcement, spamdyke might
>> accept a recipient address that qmail-smtpd will reject when the
>> conversation is replayed. Then the client thinks the address was accepted
>> but
>> it wasn't -- what to do?
>>
>> One possible workaround would be to save the conversation AND run
>> qmail-smtpd (as it does now). Then if authentication succeeds or a
>> whitelist is triggered, spamdyke could kill qmail-smtpd, set the RELAYCLIENT
>> variable, restart qmail-smtpd and replay the conversation up to that point.
>> That is, unless qmail-smtpd has been patched to change its behavior after
>> authentication, which means some of its responses might change.
>>
>> Caching conversations also gets tricky due to memory usage -- if spamdyke
>> tries to use too much memory, the "softlimit" program (if in use) will cause
>> it to malfunction. Even without "softlimit", spamdyke needs to be very
>> careful about its memory footprint (busy servers, lots of connections,
>> limited RAM). The data can be cached to disk, but then there's a risk of
>> stale cache files, running out of disk space and exposing sensitive
>> information.
>>
>> spamdyke wasn't written with any of this in mind; it'd take a pretty big
>> overhaul of the codebase. So it's difficult.:) Patching simscan is much
>> easier.
>>
>> As for whitelisting vs. authentication, they're the same thing as far as
>> spamdyke is concerned. Either one turns off all of spamdyke's filters and
>> allows relaying. That's a holdover from the days before spamdyke supported
>> authentication -- when I added the authentication code I just made it set
>> the same flag as the whitelist code. FWIW, I disagree that whitelisting
>> shouldn't allow relaying -- I often use it for exactly this purpose,
>> especially when sending email from web servers.
>>
>> BTW, what does "BL" mean?
>>
>> -- Sam Clippinger
>
> I'm beginning to see the difficulties presented with spamdyke handling
> authentication. I'm going to have to disagree with you though regarding
> the nature of authentication and relaying vs. whitelisting. I don't
> believe they're naturally the same, although spamdyke treats them as such.
>
> In a traditional setup, the ability to relay (more appropriately termed
> "submit" IMO) is controlled by authentication and by IP address via
> tcpserver, and nothing else. Whitelisting has had no effect on relay.
> This seems to me to be adequate and appropriate.
>
> From what you describe, when spamdyke is configured with access-file,
> whatever whitelist entries exist (regardless of their type) now become
> able to submit to external domains (relay), making the host more of an
> open relay than I would like. While whitelisting is something that's to
> be discouraged, its use becomes significantly more dangerous when
> access-file is used, given that anyone who can can spoof any one of the
> whitelisted entries can also use the host as a (semi-open) relay. This
> makes me very hesitant to use spamdyke's access-file configuration
> option as it's presently implemented. I don't mind whitelisting so much
> when its effects are limited to local domains, but when it can affect
> external domains and increase the risk of my IP address being
> blacklisted, I'm wary.
>
> Am I misunderstanding anything here?
>
> Of course I'm not about to throw the baby out with the bath water. :)
>
> I see what you mean regarding spamdyke having to fake the greeting and
> capabilities replies. The greeting is of course trivial, as the
> smtpgreeting file is already there, and could be an additional spamdyke
> parameter. Faking the capabilities is a little trickier, given that
> there's no persistence anywhere. They could be cached in a file
> somewhere, but that leaves the problem of knowing if and when they've
> changed. Two options here are to either start up a dummy qmail-smtpd and
> query it for its capabilities (fairly expensive to do for every session
> I would think), or manually set up a "capabilities" configuration for
> spamdyke to use. I think the later would be a better approach of the
> two, although neither is attractive.
>
> I don't think the "delay" (as you call it) should be added for or
> applied to any (other?) filters. As you pointed out, that gets to be a
> real mess, and I don't see any value or purpose in doing so.
>
> I'm not really comfortable using spamdyke's access-file parameter as
> it's presently implemented, which means that using spamdyke for
> authentication is a no go for me. That's unfortunate, as I was hoping
> that spamdyke might one day be able to enforce use of encrypted
> passwords. Might spamdyke be able to do so without handling
> authentication itself? That would seem to be fairly easy to do. Much
> easier than delaying qmail-smtpd at any rate.
>
>
> I'd like to conclude by looking at perhaps another way to let the scan
> controller (be it simscan or amavisd-new) know that authentication has
> taken place. It's not so tough as it turns out.
>
> Here's from a header of a message authenticated by qmail-smtpd:
> Received: from unknown (HELO ?192.168.70.31?)
> ([email protected]@192.168.70.31)
> by tacs-mail.shubes.net with ESMTPA; 26 Jul 2012 00:49:59 -0000
>
> Here's from a header of a message authenticated by spamdyke:
> Received: from unknown (HELO ?192.168.70.31?) (192.168.70.31)
> by tacs-mail.shubes.net with SMTP; 26 Jul 2012 00:56:17 -0000
>
> The scan controller (ie simscan) could conceivably tell from the message
> header whether or not this is a submission (authentication has taken
> place). Provided of course that the relevant information (authentication
> account) is there. When qmail-smtpd authenticates, it's there
> ([email protected] in this case). When spamdyke authenticates, it's
> not, simply because qmail-smtpd generates the Received: header, and the
> qmail-smtpd isn't aware of any authentication data when spamdyke does
> the authentication.
>
> Which begs the question, why doesn't spamdyke insert a Received: line in
> the message header? It could be done in the same way that qmail-smtpd
> does, and provide authentication data when it does the authentication.
> Then it could be left up to the scan controller to determine whether or
> not authentication has taken place based on the contents of the first 1
> or 2 message header Received: lines. Of course simscan would need to be
> patched to do this.
>
> Even if spamdyke and simscan were made to play well together, I still
> have reservations about the way whitelisting is handled with spamdyke
> authentication. So the Bottom Line (BL) appears to me to be, if
> qmail-smtpd has the smtp-auth patch, use it. I see no advantage to using
> spamdyke's auth capability, while there are a couple disadvantages.
>
> I'd still like to have a way to enforce encrypted passwords though
> (TLS/SSL or cram-md5). That would be a very valuable feature regarding
> security.
>
> As always, thanks for the great work, Sam. I hope I haven't tested your
> patience with all this. ;)
>
> P.S. Not that it matters to me, but using spamdyke's authentication
> would also defeat the badmailfromnorelay and badmailtonorelay
> parameters. I don't expect they're used much, but I could see where
> badmailtonorelay might be useful in some situations.
>
> --
> -Eric 'shubes'
>
>
>
> _______________________________________________
> spamdyke-users mailing list
> [email protected]
> http://www.spamdyke.org/mailman/listinfo/spamdyke-users
_______________________________________________
spamdyke-users mailing list
[email protected]
http://www.spamdyke.org/mailman/listinfo/spamdyke-users
