On Fri, Jul 25, 2008 at 11:57 AM, Sam Clippinger <[EMAIL PROTECTED]> wrote: > The "max-recipients" option limits the number of recipients per message > for all messages that come into your server (through spamdyke). So if
This is pretty well understood from the docs. > your clients are using your mail server as their outbound SMTP server, > this feature will limit the number of recipients on each of their > outbound messages. If they are running their own mail servers or are > using a different outbound SMTP server, this option will have no > effect. If you're using a mailing list software that delivers its > messages by making SMTP connections to a mail server (e.g. Mailman), > this feature will interfere with delivery. If your mailing list > software runs the "sendmail" command to deliver its messages (e.g. PHP), > this option will have no effect. > They're relaying the messages though our server, directly from their MUA, with, say, 1500 different e-mail address in the "To:" field. > Also, "the number of recipients per message" may be very different from > "the number of addresses on the To: line". This is due to the way SMTP > works. After a remote client connects to the server, it first takes > care of any preliminaries (initial greetings, authenticating, starting > encryption, etc), then it identifies the sender's address. The sender > address is the address to which a bounce message will be sent and may be > completely different from the "From" address that appears in the message > (the "From" address is part of the message data). Next, the remote That's well understood also. On a server level, there's not much difference between "to:", "cc:" or "bcc:" fields. I once implemented an SMTP-to-SMS in Java and have some knowledge about how the things operate on a lower level. > client begins sending recipient addresses. The server must accept or > reject each address individually. This is where the "max-recipients" > option becomes active. spamdyke will accept recipients until the > maximum is reached, then it will reject the rest. If the remote client > doesn't disconnect when it receives the errors, it may send the message > data. > > This feature is primarily intended to prevent spammers from connecting > to a mail server and delivering a single message to thousands of > recipients in a single session. When legitimate mail servers are That was that I thought initially... So far, we are not too much concerned about spam hitting our box. We just don't want to be listed on spammers databases so "regular" clients sharing the same IP address won't be affected also. We're also renting a separated service to provide mass mailing services, so the users could have an option to send e-mails to thousands of customers, but we also want a way to "force" the use of this other server. > blocked by this feature, they will retry the rejected recipients later. > For example, if a remote server tries to deliver a message to 20 > recipients but the maximum is set to 5, it will (should) make 4 > different connections. The first time, 5 recipients will be accepted > and 15 will be rejected. The second time, 5 recipients will be accepted > and 10 will be rejected, etc. (Some mail servers won't attempt to > deliver to multiple recipients after the first connection where some are > rejected. If that's the case, a message to 20 recipients will be > delivered in 16 different connections, not 4.) > That's an interesting side effect I didn't realize... But, since we're talking about _sending_ emails directly from people's MUA, not _receiving_ from other MTAs, we should be in good shape. Also, I don't think we have more than about 50 users in any hosted domain. So, setting max-recipients to 50 should do the trick. > However, most MUAs don't work this way. If your clients are delivering > their mailings by adding thousands of addresses to Outlook's "Bcc" line, > Outlook will see spamdyke's rejection code and it will stop the > delivery. The user will see an error message (which they won't > understand). You'll get phone calls. That's exactly what we want... Of course we're talking about the technical side of an entire solution. Before this migration, there will be plenty of talk to our customers and they'll know "something will not be ok when sending mass mail". Also, the customer may send the same message to thousands of clients in groups of 50 recipients per email... > > Authenticated clients are not blocked by the "max-recipients" filter anyway. > > The "filter-level" option is mostly intended to provide an easy way to > require authentication before messages will be accepted, which many > administrators have requested. The "allow-all" and "reject-all" values > are included for completeness; I don't really think anyone will need them. > Hmm... that's bad. I'm a bit rusty on C programming, but is there any chance to a patch to include filtering for _authenticated_ users be accepted? > I'm sure you've already tried this (and I sympathize, having tried the > same thing) but the correct solution is to educate your users. They > need to understand that their actions are irresponsible and they are > disrupting mail services for everyone. Try pointing them towards a > reputable mailing list provider (I've worked with Maestro, Blue Hornet > and Exact Target in the past). If they won't stop, point to your Terms > of Service which (should) prohibit this kind of activity. If they still > won't stop, you can set up another mail server just for their use so > your other clients won't be inconvenienced when it gets blacklisted. Or > you can cancel their accounts. > You're right, but non technical people tend to stray away from good technical advices... As I told before, we're already setting another email server to handle this situation, but there are some issues also. This new server will do only relaying, but we're looking for a way to ensure that a few "bad" users won't affect the "good" users in no way. Of course there's other things on the table, like blocking access to port 25 from a few IP ranges, but I don't think it's a clean solution. Also, we have customers using NAT (who hasn't nowadays?) and the same IP will be used for both "bad" and "good" people. > Good luck. > Thanks, Sam. I enjoyed this talk. > -- Sam Clippinger > > Marcus Andree wrote: >> Hello guys, >> >> I'm doing some consulting services for a small hosting company and >> we're evaluating >> the use of spamdyke with out plesk-based Linux servers. >> >> We host about 100 domains and spammers have been hitting us hard. >> After some work >> we were able to live with a spam hit of 100000+ incoming spam messages >> per day, as >> they were not affecting our business. Spamassassin was activated to >> limit the noise. >> >> Now, we're migrating one of our servers to a new machine and this time >> we need to >> address other issue: many of our clients have internal lists of >> customers e-mail addresses. >> Quite a few trigger daily emails to thousands of recipients. Our email >> server was listed >> a couple times on a number of spamming servers lists. >> >> So, we need to limit the number os recipients that our clients may >> send. I was looking >> for some clues on max-recipients usage on this list archives and have >> a few doubts: >> >> - it seems to be a feature aimed primarily to limit the number of >> _incoming_ messages, >> not _outgoing_ emails, right? >> >> - does it work with _authenticated_ clients that use our email server >> as relay from MUA >> software as Outlook and Eudora or by authenticating, users will >> bypass all filters? >> >> - will max-recipients settings affect the mailing lists processing? >> >> I've read the documentation about the "filter-level" option, but it >> isn't clear for me if >> setting it to "normal" will have the desired effect... >> >> Any ideas on this? >> >> Thanks in advance. >> >> Marcus >> _______________________________________________ >> 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 > _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
