On Thu, 24 Jun 2004 15:39:04 +0200, Jonas Eckerman wrote:
> evaluating a pretty involved validation scheme, and it does seem
> to work out so far.
Ok. Been running it for one more week now. t does work rather good and rejects a lot,
but I've decided that even with the results so far I'm not go
On Thu, 24 Jun 2004 15:39:04 +0200, Jonas Eckerman wrote:
> If this stuff keeps working without problems, I'll
> post again if I actually start rejecting based on it.
Ok. Now the test has been running for a week, and it has hit exactly *no* legit mail.
I just upgraded it from data collection t
On Fri, 25 Jun 2004 18:41:15 -0500, Les Mikesell wrote:
> If your server can't handle a database update, it's going to have
> a hard time delivering or bouncing the message...
True.
> it would be nice to avoid any more connections to the spoofed
> From: hosts than necessary. However, maybe
On Fri, 2004-06-25 at 15:20, Jonas Eckerman wrote:
> > rejects should start with
> > a short life but live increasingly longer as the use count
> > increases.
>
> That could work. But that would also mean the database has to be updated for for
> every incoming mail. With a static (short) li
On Fri, 25 Jun 2004 10:01:37 -0500, Les Mikesell wrote:
> Wouldn't this work best with a database approach similar to
> greylisting? That is, store the results of your tests with a
> count and timestamp so you don't have to repeat them often.
Yes, some kind of cache is probably a good idea. I
On Fri, 2004-06-25 at 05:53, Jonas Eckerman wrote:
> > (I suppose you use "MAIL FROM: <>" ;-)
>
> Yep. Don't want to get into a recursive loop with another server doing similar
> checks. :-)
I was wondering about that possibility.
> Yes, there are problems, wich is why my little test is done
On Fri, 25 Jun 2004 12:01:35 +0200 (CEST), Steffen Kaiser wrote:
> Wouldn't you qualify as an address harvester by some IDSes,
> because you just connect to the server issue the RCPT TO then drop
> the connection?
I guess that's a possible problem if you get a lot of mail from one domain. Have
On Thu, 24 Jun 2004, Kelson Vibber wrote:
The logic is more along the lines of:
- Sender claims to be [EMAIL PROTECTED]
- Look up MX records for speed.net
- Connect to mail.speed.net and see if it accepts mail for [EMAIL PROTECTED]
- From "User unknown" error, conclude that the sender is invalid an
On Thu, 24 Jun 2004 13:12:36 -0400 (EDT), David F. Skoll wrote:
> See the thread at [...] for some pitfalls.
Thanks for the link.
That thread seems to mostly deal with <> and postmaster. I don't try to validate <> or
[EMAIL PROTECTED] My current list of patterns to validate looks like this:
On Thu, Jun 24, 2004 at 09:35:35PM -0500, Daniel Taylor wrote:
> |>The SPF Milter allows you to define a default SPF record
> |>to be used when the site does not have a published record.
> |
> | I use the SPF Milter.. and missed the concept of default SPF record.
> What would
> | make sense as a va
On Thu, 24 Jun 2004 11:00:04 -0500, Daniel Taylor wrote:
> It is easier to use SPF for this.
Nah. SPF is a completely different thing. SPF is for checking wether the relay sending
to me is supposed to send mail from a specific domain. That's not what I'm testing at
all. I'm testing wether a se
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tony Nelson wrote:
| Quoting Daniel Taylor <[EMAIL PROTECTED]>:
|
|>The SPF Milter allows you to define a default SPF record
|>to be used when the site does not have a published record.
|>
|
|
| I use the SPF Milter.. and missed the concept of default S
Quoting Daniel Taylor <[EMAIL PROTECTED]>:
> -BEGIN PGP SIGNED MESSAGE-
[snip]
> The SPF Milter allows you to define a default SPF record
> to be used when the site does not have a published record.
>
I use the SPF Milter.. and missed the concept of default SPF record. What would
make
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David F. Skoll wrote:
| On Thu, 24 Jun 2004, Daniel Taylor wrote:
|
|
|>It is easier to use SPF for this. Then you can access the Received-SPF:
|>header both for SA rules and Bayesian filtering.
|
|
| That relies on the domain owners publishing SPF reco
On Thu, 24 Jun 2004, Daniel Taylor wrote:
> It is easier to use SPF for this. Then you can access the Received-SPF:
> header both for SA rules and Bayesian filtering.
That relies on the domain owners publishing SPF records, which still isn't
very common.
Regards,
David.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It is easier to use SPF for this. Then you can access the Received-SPF:
header both for SA rules and Bayesian filtering.
Jonas Eckerman wrote:
| The idea of validating addresses in MAIL FROM with MX servers has been
around for sometime, but has some pro
[EMAIL PROTECTED] wrote on 06/24/2004 01:08:10
PM:
> Or did I misunderstand the question?
Nope. I misunderstood what you were testing for. Like I said I haven't
programmed in a long time...
___
Visit http://www.mimedefang.org and http://www.canit
On Thu, 24 Jun 2004, Kelson Vibber wrote:
> It looks like he's not checking that the sending server *is* an MX for the
> domain, (which would cause problems with sites that use separate servers
> for incoming and outgoing mail), but checking *an* MX to see if it
> recognizes the supposed sender's
On Thu, 24 Jun 2004 11:59:43 -0400, [EMAIL PROTECTED] wrote:
> Can you explain your criteria for accepting a sender if the host
> is not an MX for the domain?
I never check wether the host sending the mail to our server is an MX for the domain
or not because:
1: The fact that a host is respon
At 08:59 AM 6/24/2004, [EMAIL PROTECTED] wrote:
Can you explain your criteria for accepting a sender if the host is not an
MX for the domain? We have CanIT Pro and the mismatch rules tened to
block alot of the "send the page to a friend" and e-card type emails. I
had to give up on them (the misma
[EMAIL PROTECTED] wrote on 06/24/2004 09:39:04
AM:
> The idea of validating addresses in MAIL FROM with MX servers has
> been around for sometime, but has some problems. I'm currently
> evaluating a pretty involved validation scheme, and it does seem to
> work out so far.
I'll trust you on th
The idea of validating addresses in MAIL FROM with MX servers has been around for
sometime, but has some problems. I'm currently evaluating a pretty involved validation
scheme, and it does seem to work out so far.
If anyone sees anything obviously stupid in the snippets below, please tell me. If
22 matches
Mail list logo
