Re: [OT] Sendmail vs. Exim, and SMTP Advice
Hi Dave,
* 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.
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?
> Any powerful tool can be a major problem if used improperly.
Sure, but that's not the problem here.
> > 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.
> 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?
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?
I have even seen bounce mails getting certified as spam by spamassassin.
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.
> 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.
> 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.
As I told: I do not know that much spam tools at the MTA level.
> 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?
> > 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.
And I do not like to get the some informational messages from your spam
tools.
> > 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.
> 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.
> 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.
> 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.
> 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.
Regards,
Spiro.
--
Spiro R. Trikaliotis
http://www.trikaliotis.net/
http://www.viceteam.org/