Hash: SHA1

Bruno Negrão wrote:
| Hi Matt, thanks for answering.
|> |  a.. CHKUSER_SENDER_FORMAT: checks if the SENDER of each message has
|> the
|> | username part matching [a-z0-9_-], and the domain part matching
|> | [a-z0-9-.] with not consecutive "-.", not leading or ending "-." ==>
|> | Great for identifying spam.
|> This really doesn't do much to identify spam.  In fact, the only purpose
|> it would tend to serve, is to limit the users on your system to
|> traditional email addresses, which could, ironically, make your system
|> more easily spammed.
| When the SENDER is a local user, I have to agree with what you say.
| But when the SENDER is a remote user, specially a spammer, this check
| will block all those weird fake addresses the spammers like to use,
| that's why
| I told this feature was good to block spam. Can you comment on this?
| Would this
| case worth to enable this feature?

Basically, you're breaking RFCs with the idea that somehow this will
protect your system from addresses only a spammer would use.  On the
same token, you could also restrict the letter 'x' citing that real
people generally don't have an x in their names.  It really offers
no extra protection, and it breaks RFCs.  If I try to send you a piece
of mail from my non-standard, wacky address containing characters most
people have never seen in an email address, you're going to reject it.

| But now I looking closely to this check I'm recalling some of my
| customers like to have e-mails of the format: [EMAIL PROTECTED]
| I't seems that this check would block my usernames with the
| 'user.lastname' syntax, since it doesn't accept a '.' character in the
| USER part. Is this customizable? If it's not, this feature does not work
| even for me!!

Address names are quite limited already, there's no need to further
limit them.  I recommend against use of this feature.

|> |  a.. CHKUSER_RCPT_FORMAT: Equals to the above checking, but for the
|> | of each message. Good to prevent your users to send crap to the net.
|> Same as CHKUSER_SENDER_FORMAT except here, if your users try to relay
|> mail to a non-traditional email address, you will find yourself with
|> a phone call from a curious customer :)
| Hmmm, oh no!! :-) So I see no utility at all to this feature.
|> |  a.. CHKUSER_SENDER_MX: Checks if the SENDER domain has a valid MX
|> | configured for it, thus, discovering fake domain names. Great for
|> | identifying spam.
|> Unfortunately, while we'd all love to force everyone to have an
|> MX record, the fact remains that some hosts just dont have them.
|> Connecting directly to the host named should be left available,
|> for now.
| I didn't understand what you said in "Connecting directly to the host
| named should be left available, for now".
| Can you explain it better?

Since some mail (and DNS) administrators sometimes neglect to add
an MX record for their domain, if you try to email [EMAIL PROTECTED],
and example.com has not published MX records, most MTAs will take
the step to try to connect directly to example.com's A record IP
if one exists.

|> Also, being dictionary attacked could leave you making a good
|> deal of DNS lookups, which can sometimes be slow.
| Yes...
| I'm seeing there are some good reasons for these features being
| commented out...
| Regards,
| bnegrao

- --
~    Matt Brookings <[EMAIL PROTECTED]>       GnuPG Key 7D7E5F37
~    Software developer                     Systems technician
~    Inter7 Internet Technologies, Inc.     (815)776-9465
Version: GnuPG v1.2.6 (GNU/Linux)


Reply via email to