|----- Original Message ----- |From: "Gary Smith" <[EMAIL PROTECTED]>
|Here is one thing that we have encountered before though. We had a |client that used to send out his newsletter to about 4000 people once a |month but he didn't use SMTP to do it. He wrote a creative PHP page |that would do it for him. I think some of the spammers do this as well. |They can have a simple pre-designed web page that pulls they emails from |a database, then they start spamming until the ISP shuts client down |(during which time they get another freebee or cheap account). SMTP |AUTH would do nothing to prevent this. That's a different issue, once the user has any kind of auth the server will act as an open relay to them (as it is supposed to). Sending mail via PHP is a common practice. and we see both spam and non-spam originating from this type of source. The unfortunate part is the base implementation of the mail() function sends mail from the server rather than via an SMTP server, but spammers don't care about that. (not to say all users of the default mail() function are spammers). This is also a good argument for using SA to filter content. We have clients that love spam (spam is their friend) and those at the other end of the spectrum that go into cardiac arrest if they get one spam. So we let them set their own level and I don't hear about it. I have been researching the SPF model and see some benefit in the scoring ability to identify the afore mentioned servers as well as protection from the joe-jobs. One of our domains got hit hard a while back with a joe-job and it became a real job emptying out the postmaster mail box with the bounces, so we just sent everything that wasn't a real address to the bit bucket. From what I've read, SPF is supposed to send the bounces back to the last server in the chain and not the reply-to address... not 100% about this -- still new. My guess is the SA implementation will be a scoring method and not a bounce which sounds like the best way to deal with this (traffic wise). This way even a fail will be able to be scored appropriately depending on the scenario. Greg -----Original Message----- From: Eric W. Bates [mailto:[EMAIL PROTECTED] Sent: Thursday, March 11, 2004 6:53 AM To: [EMAIL PROTECTED] Subject: Re: pop-before-smtp Was: Opinions About SPF Greg Cirino - Cirelle Enterprises wrote: > | > -----Original Message----- > | > From: Bart Schaefer [mailto:[EMAIL PROTECTED] > | > > POP-before-SMTP requires no special client support. Just check your > | > > mail before you send any. There is no "problem" to discuss. > > SMTP-AUTH is a much better solution than P-b4-S and is more secure > > Greg We run an ISP, and have used a combination of pop-before-smtp and SMTP-AUTH for the last several years. We use both because customers are simply ineducable. When we can, we instruct folks to authenticate. We have not experienced race conditions. Since the tool tails a log file it is easy to tweak to parse the output from an imap (pop-before-smtp simply being a shorter name than parse-logfile-for-successful-authentication-under-other-protocol-before- allowing-smtp). Yes, many clients attempt to send before a pop; but believe it or not, the customers seem to prefer clicking "send/receive" twice rather than call us and learn. -- eric
