On Mon, Jun 14, 2004 at 06:46:18AM EDT, Spiro Trikaliotis wrote: > * On Mon, Jun 14, 2004 at 03:51:41AM -0400 David Yitzchak Cohen wrote: > > On Fri, Jun 11, 2004 at 09:58:46AM EDT, Spiro Trikaliotis wrote: > > > A program which is so hard to config is a security problem. > > > It's only a security problem per se if you aren't prepared to learn > > how to use it properly. > > No, that's not what I meant. A program which is so hard to config > BECAUSE THE CONFIG IS CRYPTIC and not human-readable is a problem. > That's what I wanted to say. Blame history ;-) Terseness was much more of an issue back in the age of small drives, slow CPUs, and QWERTY keyboards. You've definitely got a point in that a modern equivalent could just as easily be more human-legible. Since few people ever actually edit their .cf files directly (since m4 is a rather impressive preprocessor), the point is rather moot. All you need to do is make sure your m4 expansions are thoroughly debugged ... which unfortunately is not always the case. > Do you think anyone will directly know what > > DM Dj R$ R< > > (just taken from some random web sites) > > mean? Why can't sendmail use human readable texts for these purposes? As I said, in 2004, you've got a point. In the 1980s, you wouldn't've. The bottom line is that in 2004, nobody's put together a free (or even a commercial, AFAIK) SMTP server approaching the flexibility of sendmail (which was most definitely _not_ created in 2004). If somebody did, I assume it'd probably have a much more human-friendly configuration method. However, there's nothing stopping you from writing a quick little filter to translate back and forth between English (or German, or whatever) and .cf-speak, and then you don't need a whole new SMTP server :-) > > > Well, but if a SPAM tool like spamassassin drops a mail, this is not > > > allowed? Do I have to look through all my SPAM? (BTW: Something I do > > > at the moment.) I doubt that. > > > > If a SPAM tool like SpamAssasin decides something is SPAM, it'll > > return a failure error code, and the MTA calling it will refuse the > > mail with an anti-spam complaint. > > >From my experience, this is not the most common usage of Spamassassin. > Most people use it locally, from an MDA. Most SA "users" are actually behind SMTP servers (say, their ISP's servers) that run SA, AFAIK. > > If you're calling SA from an MDA like procmail, the MDA will typically > > return a DSN to the sender (as best it's able to guess said entity > > from the mail). > > Typically? Can you name anyone (despite you) who does this? This is basic SMTP (or LMTP, in this case). AFAIK, every major MDA not made by DJB (who's notorious for not liking "stupid" standards - his papers are good reading and I very much admire his approach and dedication, but the point remains that when confronted by a "stupid" standard, he can't be counted on to support it in his software ... as I said, I can't fault him for that, and I don't think anybody else can ever hope to, either) complains to the MTA (which takes appropriate action) if delivery can't be completed for any reason. I don't know what DJB's MDA does. > Furthermore: I DO NOT WANT THIS! There is much spam out there, which > seems to originate from valid address, but these addresses never sent > the spam. Now, you do not get the spam, but the person in the from field > gets it? Is this really what you want? Make your problem a problem of > others? That's one of the reasons to check for SPAM in the MTA. Once you've closed your MTA connection, you've lost the guarantee of being able to talk back to the MTA on the other side. If the MTA on the other side disappears afterwords, how can you tell it about the bounce? That's why I suspect it'll be far easier to claim you didn't receive a mail with a bad bounce path than one with a good bounce path. (You can say "my SPAM filter got a false positive and tried to give it back to him, but he left me a bogus return addy.") > I have even seen bounce mails getting certified as spam by spamassassin. That's really bad. When you get a bounce mail, the first thing you need to do is to check whether or not the Message-ID there was actually sent by you. If not, the correct response for an MTA is to complain about a wrong destination. An MDA should probably just throw something like that on the floor, since the MDA is unlikely to be able to trace a misdirected/bogus mailer error, anyway. > I like to see your spamassassin (from the MDA) and the one of another > person to whom you're bouncing playing ping-pong with the reject > messages. That's another reason why an MDA should probably throw the thing on the floor. The problem is that SA isn't template-based, so all your bounce messages can potentially become false positives, setting off a chain effect, until the quoting level gets deep enough so SA no longer thinks the mailer errors are SPAM. If your SA is greedy and your MDA returns the whole message (not just the headers), I suppose you can probably get yourself a pretty good game before everything finally winds down. (With my templates, quoting a SPAM message (say, complaining to me about a SPAM sent by one of my users, or sent by some SPAMmer claiming to be in one of my domains) doesn't qualify as SPAM. In fact, that's the original reason for my own filter: I needed that capability. It also has the neat side effect that mailer errors aren't classified as SPAM unless they themselves match a template.) > > If not, you're failing to follow the rules of SMTP, and ought to be > > shot (regardless of what German courts may rule) ;-P > > Even without SPAM and the like, after getting a mail via SMTP for > delivery, no one guarantees that the server is on long enough to deliver > it. As mail is unreliable by nature, I don't see the point. SMTP is a reliable transport layer. In other words, an SMTP node either acknowledges successful receipt or failure. In a multihop setting, though, things get more complicated. However, with conformant SMTP implementations on every node, no forward path can be open while the corresponding return path is down (just graph theory - nothing fancy). In other words, if an SMTP node wants to send an error mail back to a node several hops back, it can, as long as the network hasn't changed in the intervening time period. If it has, SMTP still dictates retries every so often. Clearly, any SMTP node that wants to get all its mail can. > > Most MTAs have plugins for anti-spam tools. > > Yes, they have. But comparably not-so-many people deliberately run their > own SMTP engines, do they? (I do not look at the SMTP engines installed > by Virus and Trojans) So, they have no chance of using a spam tool at > the MTA level. So, you have to use what your provider gives you, don't > you? But filtering mail away - even if it is very likely to be spam - > will get punished by court if the user of the mail did not allow you to > do. More and more providers (at least here in the US) seem to actually be promoting anti-SPAM as a feature. I think it's ridiculous, but it's still the trend. My provider was downright surprised when I called to complain about their new anti-virus "feature." > As I told: I do not know that much spam tools at the MTA level. Well, the MTA level is really the right place to put the SPAM tool. Remember, the SPAM tool's advice is important to you not just in "when do I want to read this mail?" but also in "do I want to accept this mail?" ... and that decision is ideally made by the MTA, so any info it needs for making that decision (including the SPAM filter report) should be available to it. > > Under normal circumstances, if you run the anti-spam tool from your > > MDA instead of your MTA (where it really _should_ be run), your MDA > > will automatically get a DSN out to the supposed sender if his message > > was rejected. > > And you're sure you are preventing bounce loops? An SPAM filter should at least be smart enough to recognize its own reports and whitelist them as long as they're plausible. Still, though, the MTA really is the Right Place (TM) to run your SPAM tool. > > > I hope not, because I get enough confirmations from anti-virus > > > tools. > > > > huh? > > What I mean: Most antivirus tools send you an information that a mail > that was supposed from you contained some malware. In fact, I get more > of these informations than I get malware itself. Another fact is that it > is comparably easy to filter the malware itself, because I can filter on > executables, but it is very hard to filter out all of these informations > (which I consider "advertisements" for the antivirus tools, as the > company already knows that the from: was spoofed), because there are so > many different tools, with so different messages. This is getting > boring. LOL :-) > And I do not like to get the some informational messages from your spam > tools. My SPAM tool has zero false positives by design. It knows that it's found SPAM when it's found SPAM. It's that simple. It reports its finds back to the MTA, which then tells the other SMTP server to bite me. > > > Most spam tools look at more than one characteristic to decide of > > > something is spam or not. Looking at spamassassin, I know enough > > > people who discard anything above 5.0 completely. > > > > You _can_, if you want. However, if a real sender gets a mailer > > daemon error in his inbox, he'll read it, and realize his message > > didn't go through because it failed the anti-spam test. He's now got > > the opportunity to "deSPAMify" his mail and resend. (A real SPAMmer, > > of course, isn't gonna want to "deSPAMify" his mail, and so is > > probably not going to bother resending until the next batch.) > > Mailer daemon errors are worthless nowadays, as malware started to use > them. Furthermore, I don't want to get thousends of these errors in my > inbox from people I never wanted to contact. As I said before, you need to check the Message-IDs. > > I've had zero false positives, but that's because my SPAM detector is > > template-based, and with my conservative templates, I don't expect to > > ever have a false positive. > > Well, my false positives seem to be mostly generated from my > anti-antivirus rules in procmail. I do not want my anti-antispamtools > rules to generate more of these false positives. LOL. . . > > How are you supposed to prove that a mail reached the right recipient > > without stealing his computer? > > That's exactly the problem. You can solve it indirectly. If you get an > answer AND YOU CAN PROVE CAN ONLY BE GENERATED by the recipient of the > first mail, and it contains your first mail, you know it has reached the > recipient, and you can prove it. For this, you would need some > cryptography. That sounds crazy. I'd rather encrypt my message to a one-time key, and give him directions to retrieve the key. > > Clearly, anybody who sets up an MX record and advertizes in the banner > > that he supports SMTP is agreeing to abide by the SMTP protocol, and > > by saying "I got the message" in SMTP-speak, he's essentially > > acknowledging receipt of the mail. > > Well, if I send an SMS via mobile phone, I get a confirmation that is > has been sent. I even have to pay it. Anyway, no mobile phone provider > will guarantee that is reaches its destination. Even the "confirmation" > responses I can get if I want do not add anything to this, they can lie > to me. I don't know much about SMS, sorry. (All I know is that T-Mobile charges me 5 cents a pop - sending or receiving.) > > At least MailMan-run lists have a plugin architecture to handle SPAM. > > MailMan attempts to notify senders when incoming mail is bad, IIRC. > > I don't know about MailMan, but I believe it might be an option for the > list maintainer. And many choose not to send spam notifications out. I > assume it is because this would cost more bandwidth, but I'm not sure. It's an option for the MailMan admin, presumably for the reasons you just mentioned above. - Dave -- Uncle Cosmo, why do they call this a word processor? It's simple, Skyler. You've seen what food processors do to food, right? Please visit this link: http://rotter.net/israel
Attachment:
pgpQ3psSJlyoF.pgp
Description: PGP signature