--
La información incluida en el presente correo electronico y cualquier archivo
adjunto al mismo están dirigidos exclusivamente a su destinatario.Pueden
contener información confidencial o privilegiada. Si recibe esta comunicación
sin ser el
On Wednesday 19 July 2006 00:13, Stephen Gran wrote:
This one time, at band camp, Thomas Bushnell BSG said:
Loïc Minier [EMAIL PROTECTED] writes:
Can we get greylisting now?
We have it, duh. Have you not been paying attention?
We don't have it yet. Have you not been paying
Thomas Bushnell BSG [EMAIL PROTECTED] schrieb/wrote:
So the meaning of 4xx is temporary local problem.
RFC 2822 says 4yz Transient Negative Completion reply (p. 42). The
standard also encourages the re-use of existing error codes for
slightly different situations (p. 43).
Claus
--
To
Le mardi 18 juillet 2006 à 12:22 -0700, Thomas Bushnell BSG a écrit :
Josselin Mouette [EMAIL PROTECTED] writes:
I have refused greylisting for a long time for that exact reason.
However the setup Pierre Habouzit describes does not delay most of
legitimate mail. Frankly, the remaining
On Tue, Jul 18, 2006 at 12:24:21PM -0700, Thomas Bushnell BSG wrote:
So the meaning of 4xx is temporary local problem. Sending that when
you don't have a temporary local problem is a violation, right there.
Must the standard repeat after every sentence, oh, and don't lie.
If it helps, think
Le mar 18 juillet 2006 00:08, Magnus Holmgren a écrit :
On Monday 17 July 2006 23:41, Pierre Habouzit took the opportunity to
write:
Le lun 17 juillet 2006 19:53, Adrian von Bidder a écrit :
So the question is, imho, not if we should potentially lock out
users of big mail pools - those
On Mon, Jul 17, 2006 at 11:48:21PM +0200, Pierre Habouzit wrote:
Le lun 17 juillet 2006 22:29, Lionel Elie Mamane a écrit :
Here is one: I am strongly opposed to greylisting (on mail sent to
me or that I send), for the reason that it delays legitimate mail.
which shows that you didn't read
On Tue, Jul 18, 2006 at 12:47:49AM +0200, Josselin Mouette wrote:
Le lundi 17 juillet 2006 à 22:29 +0200, Lionel Elie Mamane a écrit :
On Sun, Jul 16, 2006 at 08:36:31AM +0200, Christian Perrier wrote:
Quoting Wolfgang Lonien ([EMAIL PROTECTED]):
Do we use greylisting on the @debian.org
* Stephen Gran [EMAIL PROTECTED] [2006-07-17 18:43]:
It's not uncommon for big sites to have pools of high throughput
machines that don't have qrunners, and larger pools of machines that do.
The first group gets a message, and tries to deliver immediately, and
any temporary failure gets the
Le mardi 18 juillet 2006 à 09:47 +0200, Lionel Elie Mamane a écrit :
That is the crux of the disagreement. You guys think that as long as
most of the legitimate mail is not delayed, the price is worth it. I
don't think so.
If too much spam gets through, *all* legitimate mail gets delayed. It
Le mar 18 juillet 2006 09:34, Lionel Elie Mamane a écrit :
This will still include legitimate mail.
something like 50 over 300k is less than 0.016%.
which is also really less than the usual number of false positives of
your bayesian mail filter. see end of mail.
and if you never actually
* Lionel Elie Mamane [EMAIL PROTECTED] [2006-07-17 22:32]:
On Sun, Jul 16, 2006 at 08:36:31AM +0200, Christian Perrier wrote:
So far and unless I forget someone, I haven't seen much other people
being strongly opposed to greylisting on Debian hosts,
Here is one: I am strongly opposed to
(afaik, it's very obvious that I'm subscribed to -devel and, unless I'm
wrong, I never requeted for being CC'ed in private)
Lionel Elie Mamane a écrit :
Wrong. Disagreeing with you is not the same as not reading your
arguments. Sorry that you were not convincing.
I'm afraid you failed
On Tue, Jul 18, 2006 at 10:22:41AM +0200, Christian Perrier wrote:
Lionel Elie Mamane a écrit :
Bingo: Legitimate mail slowed down. You think the price is worth
it, which is a valid opinion. I happen not to think so.
The question becomes: aren't you in a small minority?
That may very well
Then it would be OK to implement it. The very best would be to do the
same I do on my mail server, where users can individually choose
greylisting or not for personal mail to them, by a settings file in
their home directory. But if a strong majority wants greylisting, it
is OK to just do it
Le mar 18 juillet 2006 11:51, Christian Perrier a écrit :
Then it would be OK to implement it. The very best would be to do
the same I do on my mail server, where users can individually
choose greylisting or not for personal mail to them, by a settings
file in their home directory. But if
On Tue, Jul 18, 2006 at 09:47:13AM +0200, Lionel Elie Mamane wrote:
On Tue, Jul 18, 2006 at 12:47:49AM +0200, Josselin Mouette wrote:
* Exim sender/callout fails with a fatal error.
Fatal means not temporary?
Yes. It means exim did this to one of the MX hosts listed for the
domain:
Apart from the fact that the opinions seem to be set (and haven't really
changed since the last time the discussion came up IIRC, so we really can
stop arguing - nothing new for quite some time...): am I correct in my
observation that nobody who has participated in this discussion up to now
is
Le mar 18 juillet 2006 13:20, Adrian von Bidder a écrit :
Apart from the fact that the opinions seem to be set (and haven't
really changed since the last time the discussion came up IIRC, so we
really can stop arguing - nothing new for quite some time...): am I
correct in my observation that
Josselin Mouette [EMAIL PROTECTED] writes:
I have refused greylisting for a long time for that exact reason.
However the setup Pierre Habouzit describes does not delay most of
legitimate mail. Frankly, the remaining delays are sporadic and one can
live with them.
What bothers me is that we
Stephen Gran [EMAIL PROTECTED] writes:
This one time, at band camp, Thomas Bushnell BSG said:
And finally, if we don't care about standards conformance, I have said
that a good second-best is to document exactly what our requirements
are, rather than burying them in apparent secrecy.
What
Adam Borowski [EMAIL PROTECTED] writes:
Even worse, there's nothing preventing a site from saying it has a
temporary local problem when it _does_. Thus, if your mail server
can't handle retrying, it will drop mail every time something is not
in perfect working order. And hardware or network
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Jul 17, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
Still, if you think it's just nitpicking, then why not ask the IETF to
amend the standard to clearly permit this practice?
Because there is no reason to do this, this is not a standard issue but
Pierre Habouzit [EMAIL PROTECTED] writes:
For the record (it was already said in the thread IIRC), the setup we
are discussing is in production on alioth since sth like 4 or 5 monthes
now (maybe a bit less) on my idea, and thanks to Raphael Hertzog for
actually using his alioth admin hat
On Tue, Jul 18, 2006, Thomas Bushnell BSG wrote:
If the anti-spam advocates consistently said our measures impose
such-and-such a cost, but we think it's worth it, I would be
delighted.
the measures impose a cost, but we think it's worth it
Can we get greylisting now?
--
Loïc Minier
On Jul 18, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
Because there is no reason to do this, this is not a standard issue but
plain operations.
Really? So you think the IETF would happily issue a statement
agreeing?
Yes.
Of course, the facts are that the IETF regards graylisting as a
On Jul 18, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
Yes, and this is not the point. The point is that the standard does
*not* say that the retry must come from the same place, or even
anything like the same place.
The point is that in the real world nobody cares that this is not
specified
Loïc Minier [EMAIL PROTECTED] writes:
On Tue, Jul 18, 2006, Thomas Bushnell BSG wrote:
If the anti-spam advocates consistently said our measures impose
such-and-such a cost, but we think it's worth it, I would be
delighted.
the measures impose a cost, but we think it's worth it
Can you
Le mar 18 juillet 2006 21:26, Thomas Bushnell BSG a écrit :
Pierre Habouzit [EMAIL PROTECTED] writes:
For the record (it was already said in the thread IIRC), the setup
we are discussing is in production on alioth since sth like 4 or 5
monthes now (maybe a bit less) on my idea, and thanks
This one time, at band camp, Thomas Bushnell BSG said:
Loïc Minier [EMAIL PROTECTED] writes:
On Tue, Jul 18, 2006, Thomas Bushnell BSG wrote:
If the anti-spam advocates consistently said our measures impose
such-and-such a cost, but we think it's worth it, I would be
delighted.
the
This one time, at band camp, Thomas Bushnell BSG said:
So the meaning of 4xx is temporary local problem. Sending that when
you don't have a temporary local problem is a violation, right there.
Must the standard repeat after every sentence, oh, and don't lie.
Actually, that's just the error
On Sunday 16 July 2006 04:35, Thomas Bushnell BSG took the opportunity to
write:
Stephen Gran [EMAIL PROTECTED] writes:
I suggest that when we find a domain that sends mail from 120 /27's
(roughly a /20), we worry about it then.
An excellent strategy.
I think so. How many systems (aside
This one time, at band camp, Magnus Holmgren said:
On Sunday 16 July 2006 04:35, Thomas Bushnell BSG took the opportunity
to write:
Stephen Gran [EMAIL PROTECTED] writes:
I suggest that when we find a domain that sends mail from 120
/27's (roughly a /20), we worry about it then.
An
[sending systems that don't deal with greylisting]
On Monday 17 July 2006 17:36, Magnus Holmgren wrote:
[...]
Also, this kind of information can be
shared so that not every mail admin has to find it out himself by users
complaining.
Some data points:
* the default greylist shipped by
On Sun, Jul 16, 2006 at 08:36:31AM +0200, Christian Perrier wrote:
Quoting Wolfgang Lonien ([EMAIL PROTECTED]):
Do we use greylisting on the @debian.org domain and especially on
@lists.debian.org?
So, up to now, we've found Thomas Bushnell who seems really hardly
voting against greylisting
Christian Perrier [EMAIL PROTECTED] writes:
So, up to now, we've found Thomas Bushnell who seems really hardly
voting against greylisting on Debian hosts, with arguments about it
breaking established standards. I personnally find these arguments
very nitpicking and mostly aimed at finding a
Magnus Holmgren [EMAIL PROTECTED] writes:
Do you have some mechanism in place to detect
such a case when or if it happens?
Deal with it when people complain. Also, this kind of information can be
shared so that not every mail admin has to find it out himself by users
complaining.
Are
Le lun 17 juillet 2006 19:53, Adrian von Bidder a écrit :
So the question is, imho, not if we should potentially lock out users
of big mail pools - those are in the default whitelists anyway by
now. The question is: can we temporarily (until they can be
whitelisted) lock out users of
This one time, at band camp, Thomas Bushnell BSG said:
And finally, if we don't care about standards conformance, I have said
that a good second-best is to document exactly what our requirements
are, rather than burying them in apparent secrecy.
What standards, exactly? Can you be specific?
Le lun 17 juillet 2006 22:29, Lionel Elie Mamane a écrit :
Here is one: I am strongly opposed to greylisting (on mail sent to me
or that I send), for the reason that it delays legitimate mail.
which shows that you didn't read the discussion that was about enabling
greylisting on *certain*
On Mon, Jul 17, 2006 at 10:42:22PM +0100, Stephen Gran wrote:
This one time, at band camp, Thomas Bushnell BSG said:
And finally, if we don't care about standards conformance, I have said
that a good second-best is to document exactly what our requirements
are, rather than burying them in
On Monday 17 July 2006 23:41, Pierre Habouzit took the opportunity to write:
Le lun 17 juillet 2006 19:53, Adrian von Bidder a écrit :
So the question is, imho, not if we should potentially lock out users
of big mail pools - those are in the default whitelists anyway by
now. The question
On Monday 17 July 2006 23:27, Thomas Bushnell BSG took the opportunity to
write:
Magnus Holmgren [EMAIL PROTECTED] writes:
Deal with it when people complain. Also, this kind of information can be
shared so that not every mail admin has to find it out himself by users
complaining.
Are you
Le lundi 17 juillet 2006 à 22:29 +0200, Lionel Elie Mamane a écrit :
On Sun, Jul 16, 2006 at 08:36:31AM +0200, Christian Perrier wrote:
Quoting Wolfgang Lonien ([EMAIL PROTECTED]):
Do we use greylisting on the @debian.org domain and especially on
@lists.debian.org?
So, up to now,
On Jul 17, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
Still, if you think it's just nitpicking, then why not ask the IETF to
amend the standard to clearly permit this practice?
Because there is no reason to do this, this is not a standard issue but
plain operations.
--
ciao,
Marco
Quoting Wolfgang Lonien ([EMAIL PROTECTED]):
Hi all,
this is maybe the wrong group for it (sorry in that case), but:
Do we use greylisting on the @debian.org domain and especially on
@lists.debian.org?
So, up to now, we've found Thomas Bushnell who seems really hardly
voting against
On Thu, Jul 13, 2006 at 11:01:09AM -0700, Thomas Bushnell BSG wrote:
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes:
The specific example used was some spam source sitting in the same /27
netblock in a colo server room, and getting through the graylister because
a proper MTA from
Wouter Verhelst [EMAIL PROTECTED] wrote:
On Thu, Jul 13, 2006 at 11:01:09AM -0700, Thomas Bushnell BSG wrote:
[...]
Ok, now I understand. As I've already said, graylisting on /27
netblocks amounts to inventing new network standards, which I believe
should go through the IETF standardization
This one time, at band camp, Andreas Metzler said:
Wouter Verhelst [EMAIL PROTECTED] wrote:
On Thu, Jul 13, 2006 at 11:01:09AM -0700, Thomas Bushnell BSG wrote:
[...]
Ok, now I understand. As I've already said, graylisting on /27
netblocks amounts to inventing new network standards, which
On 7/15/06, Andreas Metzler [EMAIL PROTECTED] wrote:
Hello,
The following setup would be in compliance with rfc2821 but would
not be able to deliver mail to a greylisting host:
- retrying every hour for up to five days
- messages are sent out from 120 different IP-addresses all living in
Martijn van Oosterhout [EMAIL PROTECTED] wrote:
On 7/15/06, Andreas Metzler [EMAIL PROTECTED] wrote:
Hello,
The following setup would be in compliance with rfc2821 but would
not be able to deliver mail to a greylisting host:
[...]
I thought the point was that someone with such a setup is
Andreas Metzler [EMAIL PROTECTED] writes:
This in an extreme setup,
...or a setup designed to be used as an argument against greylisting.
--
Stig Sandbeck Mathisen [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
Wouter Verhelst [EMAIL PROTECTED] writes:
Greylisting already exists. This would just make it _less_ of a problem.
By greylisting from /27 netblocks, you wouldn't block any additional
mail as opposed to greylisting in general; quite to the contrary.
Yes, I understand. What I'm saying is
Stephen Gran [EMAIL PROTECTED] writes:
I suggest that when we find a domain that sends mail from 120 /27's
(roughly a /20), we worry about it then.
An excellent strategy. Do you have some mechanism in place to detect
such a case when or if it happens?
Thomas
--
To UNSUBSCRIBE, email to
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes:
The specific example used was some spam source sitting in the same /27
netblock in a colo server room, and getting through the graylister because
a proper MTA from the same /27 netblock had already been added to the
approve it, it does
On Mon, Jul 10, 2006 at 06:28:40PM +0100, Stephen Gran wrote:
This one time, at band camp, Henrique de Moraes Holschuh said:
On Mon, 10 Jul 2006, Adrian von Bidder wrote:
As I know it, the receiving MX connects the regular MX for the
sender address to see if *that* is ready to receive mail.
This one time, at band camp, Lionel Elie Mamane said:
On Mon, Jul 10, 2006 at 06:28:40PM +0100, Stephen Gran wrote:
This one time, at band camp, Henrique de Moraes Holschuh said:
On Mon, 10 Jul 2006, Adrian von Bidder wrote:
As I know it, the receiving MX connects the regular MX for the
On Tue, Jul 11, 2006 at 08:56:52AM +0200, Lionel Elie Mamane wrote:
On Mon, Jul 10, 2006 at 06:28:40PM +0100, Stephen Gran wrote:
This one time, at band camp, Henrique de Moraes Holschuh said:
On Mon, 10 Jul 2006, Adrian von Bidder wrote:
As I know it, the receiving MX connects the
On Tue, Jul 11, 2006 at 08:48:43PM +1000, Hamish Moffatt wrote:
On Tue, Jul 11, 2006 at 08:56:52AM +0200, Lionel Elie Mamane wrote:
On Mon, Jul 10, 2006 at 06:28:40PM +0100, Stephen Gran wrote:
This one time, at band camp, Henrique de Moraes Holschuh said:
On Mon, 10 Jul 2006, Adrian von
On 7/11/06, Lionel Elie Mamane [EMAIL PROTECTED] wrote:
Some sites verify the [EMAIL PROTECTED] and
[EMAIL PROTECTED] addresses before accepting mail with sender
[EMAIL PROTECTED] .
IIRC sourceforge verifies for the existence of a postmaster@ address
--
To UNSUBSCRIBE, email to [EMAIL
This one time, at band camp, Török Edvin said:
On 7/11/06, Lionel Elie Mamane [EMAIL PROTECTED] wrote:
Some sites verify the [EMAIL PROTECTED] and
[EMAIL PROTECTED] addresses before accepting mail with sender
[EMAIL PROTECTED] .
IIRC sourceforge verifies for the existence of a postmaster@
On Tue, Jul 11, 2006 at 01:28:47PM +0200, Lionel Elie Mamane wrote:
On Tue, Jul 11, 2006 at 08:48:43PM +1000, Hamish Moffatt wrote:
That doesn't add up. Since never sends mail, there will never be
a sender verification callback TO that address either.
Some sites verify the [EMAIL
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes:
On Mon, 10 Jul 2006, Thomas Bushnell BSG wrote:
martin f krafft [EMAIL PROTECTED] writes:
That's better than not greylisting anyone. Nobody is trying to
design the perfect spam filter. We just want to reduce spam on
debian.org.
A
On Tue, 11 Jul 2006, Thomas Bushnell BSG wrote:
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes:
On Mon, 10 Jul 2006, Thomas Bushnell BSG wrote:
martin f krafft [EMAIL PROTECTED] writes:
That's better than not greylisting anyone. Nobody is trying to
design the perfect spam filter.
Thomas Bushnell BSG tb at becket.net writes:
martin f krafft madduck at debian.org writes:
[...]
It assumes, for example, that the remote MTA will use the same IP
address each time it sends the message.
[...]
eh no. Standard greylisting practise nowadays (it already was standard when
sarge
On Sun, 09 Jul 2006, Thomas Bushnell BSG wrote:
I don't think I understand just what you're saying. Can you spell out
the details for me?
Does the second email I sent (with the missing stuff) provides the
clarification you asked for?
It distresses me that I have said twice now that a
On Mon, 10 Jul 2006 06:15:55 + (UTC), Andreas Metzler
[EMAIL PROTECTED] wrote:
Thomas Bushnell BSG tb at becket.net writes:
martin f krafft madduck at debian.org writes:
[...]
It assumes, for example, that the remote MTA will use the same IP
address each time it sends the message.
[...]
also sprach Marc Haber [EMAIL PROTECTED] [2006.07.10.0930 +0200]:
eh no. Standard greylisting practise nowadays (it already was
standard when sarge was released) is to not greylist on host IP
but at least on the /27 netblock.
So you will whitelist the spamming customer in the same rack farm
On Jul 10, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
I am concerned that you not use a spam-defeating technique which
blocks perfectly legitimate and standards-compliant email.
Then why you are not loudly complaining about the antispam software
currently applied to our mail lists and BTS,
On Mon, Jul 10, 2006 at 07:39:19AM +0200, Pierre Habouzit wrote:
Le lun 10 juillet 2006 02:17, Matthew R. Dempsky a écrit :
On Sun, Jul 09, 2006 at 05:02:39PM -0700, Thomas Bushnell BSG wrote:
Another problem is with hosts that do not accept a message from an
MTA unless that MTA is
On Sunday 09 July 2006 15:48, Martijn van Oosterhout wrote:
[greylisting]
The point was about mailers sending mail to debian. If they receive a
4xx they have to queue the mail and retry later. It's cheap for
debian, but expensive for everyone else.
Does anybody have sensible numbers about
On Monday 10 July 2006 02:17, Matthew R. Dempsky wrote:
On Sun, Jul 09, 2006 at 05:02:39PM -0700, Thomas Bushnell BSG wrote:
Another problem is with hosts that do not accept a message from an MTA
unless that MTA is willing to accept replies. This is a common spam
prevention measure.
It
On Monday 10 July 2006 06:58, Thomas Bushnell BSG wrote:
Doing sender verification and graylisting are both violations of the
RFCs.
Which rfcs and where, exactly? Specific filename, version and line numbers,
as Kimball would say it.
AFAICT, the protocol allows the receiving end to
On Mon, Jul 10, 2006 at 05:57:45PM +0200, Adrian von Bidder wrote:
On Monday 10 July 2006 02:17, Matthew R. Dempsky wrote:
On Sun, Jul 09, 2006 at 05:02:39PM -0700, Thomas Bushnell BSG wrote:
Another problem is with hosts that do not accept a message from an MTA
unless that MTA is willing
This one time, at band camp, Thomas Bushnell BSG said:
martin f krafft [EMAIL PROTECTED] writes:
Anyway, I'll be interested to hear a summary of their arguments, as
Christian Perrier requested. I find it hard to imagine how properly
configured greylisting should cause any problems.
On Mon, 10 Jul 2006, Adrian von Bidder wrote:
On Monday 10 July 2006 02:17, Matthew R. Dempsky wrote:
On Sun, Jul 09, 2006 at 05:02:39PM -0700, Thomas Bushnell BSG wrote:
Another problem is with hosts that do not accept a message from an MTA
unless that MTA is willing to accept replies.
Andreas Metzler [EMAIL PROTECTED] writes:
Thomas Bushnell BSG tb at becket.net writes:
martin f krafft madduck at debian.org writes:
[...]
It assumes, for example, that the remote MTA will use the same IP
address each time it sends the message.
[...]
eh no. Standard greylisting practise
martin f krafft [EMAIL PROTECTED] writes:
That's better than not greylisting anyone. Nobody is trying to
design the perfect spam filter. We just want to reduce spam on
debian.org.
A perfect spam filter is one which catches all spam and bounces no
valid mail. Saying we aren't trying to be
On Jul 10, Adrian von Bidder [EMAIL PROTECTED] wrote:
AFAICT, the protocol allows the receiving end to temporarily reject email,
and the sending end will retry. AFAICT QUIT is allowed after RCPT TO to
abort a mail transaction - and sender verification is no different from a
normal mail
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes:
Read below. When you do, please remember that many of us consider that a
fully-open system which drowns us in SPAM is also broken, because you do
lose information for failure of locating it among the noise.
You may lose that information;
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Jul 10, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
I am concerned that you not use a spam-defeating technique which
blocks perfectly legitimate and standards-compliant email.
Then why you are not loudly complaining about the antispam software
On Jul 10, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
I want you to be explicit and clear about which new rules you are
writing into the RFCs, so that people can conform to them. You are
making up new standards and hosing people who do not comply; at the
very least you have an obligation
This one time, at band camp, Henrique de Moraes Holschuh said:
On Mon, 10 Jul 2006, Adrian von Bidder wrote:
On Monday 10 July 2006 02:17, Matthew R. Dempsky wrote:
On Sun, Jul 09, 2006 at 05:02:39PM -0700, Thomas Bushnell BSG wrote:
Another problem is with hosts that do not accept a
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Jul 10, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
I want you to be explicit and clear about which new rules you are
writing into the RFCs, so that people can conform to them. You are
making up new standards and hosing people who do not comply;
On Jul 10, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
I'm speaking about Debian here. We stand for openness, clarity, and
free software. We stand for the interests of our users. We do not
We used to. Nowadays we stand for the mechanical veneration of holy
principles.
--
ciao,
Marco
On 2006-07-10 Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
Andreas Metzler [EMAIL PROTECTED] writes:
Thomas Bushnell BSG tb at becket.net writes:
martin f krafft madduck at debian.org writes:
[...]
It assumes, for example, that the remote MTA will use the same IP
address each time it
On Mon, 10 Jul 2006, Marco d'Itri wrote:
On Jul 10, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
I am concerned that you not use a spam-defeating technique which
blocks perfectly legitimate and standards-compliant email.
Then why you are not loudly complaining about the antispam software
In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes:
At least for the BTS, those messages are not discarded; they're just
separated out and processing on them is halted. Blars spends a lot of
time looking at borderline messages to put back in non-spam into the
queue, and catches most of them.
On Mon, Jul 10, 2006 at 05:57:45PM +0200, Adrian von Bidder wrote:
On Monday 10 July 2006 02:17, Matthew R. Dempsky wrote:
On Sun, Jul 09, 2006 at 05:02:39PM -0700, Thomas Bushnell BSG wrote:
Another problem is with hosts that do not accept a message from an MTA
unless that MTA is willing
On Tue, Jul 11, 2006 at 02:39:00AM +0200, Adam Borowski wrote:
In fact, broken servers which don't obey MX will _already_ fail:
[ demonstration that debian.org doesn't accept RCPT TO @debian.org ]
The issue isn't whether MTA's check against MX or A records, it's
whether they check the IP that
On Mon, 10 Jul 2006, Thomas Bushnell BSG wrote:
martin f krafft [EMAIL PROTECTED] writes:
That's better than not greylisting anyone. Nobody is trying to
design the perfect spam filter. We just want to reduce spam on
debian.org.
A perfect spam filter is one which catches all spam and
Quoting Thomas Bushnell BSG ([EMAIL PROTECTED]):
martin f krafft [EMAIL PROTECTED] writes:
This has been brought up. Basically I don't think people were
opposed to it, but there was noone available to implement it.
There were people opposed to it, in fact.
What were their arguments?
On Sun, 9 Jul 2006 08:14:20 +0200, Christian Perrier
[EMAIL PROTECTED] wrote:
Quoting Thomas Bushnell BSG ([EMAIL PROTECTED]):
martin f krafft [EMAIL PROTECTED] writes:
This has been brought up. Basically I don't think people were
opposed to it, but there was noone available to implement it.
also sprach Marc Haber [EMAIL PROTECTED] [2006.07.09.1430 +0200]:
For example, that greylisting puts significant load on systems
that deliver mail to us,
I am sorry, I don't buy this argument at all. First, a 4xx is not
significant load on any mailer unless you're running some piece of
crap.
also sprach Thomas Bushnell BSG [EMAIL PROTECTED] [2006.07.09.0557 +0200]:
There were people opposed to it, in fact.
Sure, nobody expected it to be any different. This is Debian, after
all. :)
There will always be opposers. If we let our work be hindered by
them, we're going to stagnate.
On 7/9/06, martin f krafft [EMAIL PROTECTED] wrote:
also sprach Marc Haber [EMAIL PROTECTED] [2006.07.09.1430 +0200]:
For example, that greylisting puts significant load on systems
that deliver mail to us,
I am sorry, I don't buy this argument at all. First, a 4xx is not
significant load on
also sprach Martijn van Oosterhout [EMAIL PROTECTED] [2006.07.09.1548 +0200]:
The point was about mailers sending mail to debian. If they receive a
4xx they have to queue the mail and retry later. It's cheap for
debian, but expensive for everyone else.
My point was: even 100 such queued mails
Martijn van Oosterhout [EMAIL PROTECTED] wrote:
[...]
The point was about mailers sending mail to debian. If they receive a
4xx they have to queue the mail and retry later. It's cheap for
debian, but expensive for everyone else.
A far more reasonable solution is to only greylist mail with an
On Sun, 2006-07-09 at 16:14 +0200, martin f krafft wrote:
A far more reasonable solution is to only greylist mail with an
unreasonably high spamassassin score. Normal mail I assume generally
doesn't score high and is not susceptable to greylisting.
Sure. Or greylist only when it's from a
also sprach Thijs Kinkhorst [EMAIL PROTECTED] [2006.07.09.1622 +0200]:
Indeed, the current Alioth config only greylists those hosts that have
some kind of 'problem', like no reverse DNS entry or are featured on
some kind of RBL.
Any decent mailserver is allowed right through. Any indecent
1 - 100 of 261 matches
Mail list logo
