-----BEGIN PGP SIGNED MESSAGE----- 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 |> RCPT |> | 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 */ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCsuz+/pZz8n1+XzcRAvOjAKCFtoh/HlCJUdxoPE6Nsyx+rJPzBwCfV3Uo m+0MseXOizxfbRkU07l/rNM= =xygd -----END PGP SIGNATURE-----
