|
|
|
|
|
|
| Author |
Message |
martin f krafft
*nix forums Guru
Joined: 01 Mar 2005
Posts: 360
|
 Posted: Sun Jul 09, 2006 2:20 pm Post subject:
Re: greylisting on debian.org?
|
|
|
also sprach Martijn van Oosterhout <kleptog@gmail.com> [2006.07.09.1548 +0200]:
| Quote: | 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 are not expensive nowadays
(unless your MTA is crap). If you have more than 100 queued mails
due to greylisting on debian.org, you are either a big provider and
can handle it, or a spammer.
| Quote: | 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 dynIP address.
| Quote: | Not that I mind, the amount of spam received via this mailing list is
so marginal I can hardly imagine people worrying about it.
|
Your email address doesn't appear to be plastered all over Debian
package control files, changelogs, the bug tracking system, and the
mailing lists. Or at least not as much as some others. I get
somewhere between 200-400 spam messages into my debian.org account
per day.
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer and author: http://debiansystem.info
`. `'`
`- Debian - when you have better things to do than fixing a system
*** important disclaimer:
by sending an email to any address, that will eventually cause it to
end up in my inbox without much interaction, you are agreeing that:
- i am by definition, "the intended recipient"
- all information in the email is mine to do with as i see fit and
make such financial profit, political mileage, or good joke as it
lends itself to. in particular, i may quote it on usenet.
- i may take the contents as representing the views of your company.
- this overrides any disclaimer or statement of confidentiality that
may be included on your message. |
|
| Back to top |
|
 |
Andreas Metzler
*nix forums Guru Wannabe
Joined: 20 Mar 2005
Posts: 170
|
| Posted: Sun Jul 09, 2006 2:30 pm Post subject:
Re: greylisting on debian.org?
|
|
|
Martijn van Oosterhout <kleptog@gmail.com> wrote:
[...]
| Quote: | 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
unreasonably high spamassassin score. Normal mail I assume generally
doesn't score high and is not susceptable to greylisting.
|
Greylisting after DATA sounds like a bad idea to me:
1. The bandwith has already been wasted.
2. The bandwith will be wasted again if the host retries
3. spamassassin is a performance hog, and you'll need to rerun it when
the host retries.
*If* you want to be picky about greylisting use something *cheap*,
e.g.
- greylist only hosts listed on a DNS blacklist.
- Don't greylist on host/sender/receipient triples but check
network/sender/receipient. And possibly combine this with *not*
greylisting _any_ sender/receipient tuple iff $host already passed
greylisting for another sender/receipient tuple. (We already know
the host to do proper retries, no use in greylisting again.)
| Quote: | Not that I mind, the amount of spam received via this mailing list is
so marginal I can hardly imagine people worrying about it.
|
We are not (only) talking about lists.d.o. primarly but the
developer@debian.org addresses. /These/ gather loads of spam.
cu andreas
--
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken. (c) Jasper Ffforde
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Thijs Kinkhorst
*nix forums addict
Joined: 14 Mar 2005
Posts: 94
|
| Posted: Sun Jul 09, 2006 2:30 pm Post subject:
Re: greylisting on debian.org?
|
|
|
On Sun, 2006-07-09 at 16:14 +0200, martin f krafft wrote:
| Quote: | 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 dynIP address.
|
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 mailserver
is told to wait just a little bit, but is still allowed to send its
mail.
On Sun, 09 Jul 2006 14:30:33 +0200, Marc Haber wrote:
| Quote: | and that it is only a question of time before spam zombies retry.
|
That's not really relevant: if we can block spam now, we should do it
now. Sure, we still need to be looking for new measures for when
greylisting stops to work, but that doesn't exclude using it now in any
way.
Thijs |
|
| Back to top |
|
|
martin f krafft
*nix forums Guru
Joined: 01 Mar 2005
Posts: 360
|
| Posted: Sun Jul 09, 2006 2:40 pm Post subject:
Re: greylisting on debian.org?
|
|
|
also sprach Thijs Kinkhorst <thijs@debian.org> [2006.07.09.1622 +0200]:
| Quote: | 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 mailserver
is told to wait just a little bit, but is still allowed to send its
mail.
|
postgrey, for instance, whitelists hosts that have 5 successful
deliveries. In the presence of this option, you can just greylist
*everything*.
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer and author: http://debiansystem.info
`. `'`
`- Debian - when you have better things to do than fixing a system
mumlutlitithtrhreeaadededd s siigngnatatuurere |
|
| Back to top |
|
|
Christian Perrier
*nix forums Guru Wannabe
Joined: 22 Mar 2005
Posts: 204
|
| Posted: Sun Jul 09, 2006 3:20 pm Post subject:
Re: greylisting on debian.org?
|
|
|
Quoting Marc Haber (mh+debian-devel@zugschlus.de):
| Quote: | For example, that greylisting puts significant load on systems that
deliver mail to us, and that it is only a question of time before spam
zombies retry.
|
Yep, I know about these arguments but Pierre Habouzit bringed an
interesting enhancement to greylisting by greylisting only systems
that are in some carefully chosen blacklists.
This is what is currently operational on lists.alioth.d.o
I see this as an interesting combination of RBL (which I dislike A LOT
when used alone) and greylisting. It reduced the amount of spam in
Alioth mailing list significantly. |
|
| Back to top |
|
|
Pierre HABOUZIT
*nix forums beginner
Joined: 16 Apr 2006
Posts: 42
|
| Posted: Sun Jul 09, 2006 10:30 pm Post subject:
Re: greylisting on debian.org?
|
|
|
Le dim 9 juillet 2006 14:30, Marc Haber a écrit :
| Quote: | On Sun, 9 Jul 2006 08:14:20 +0200, Christian Perrier
bubulle@debian.org> wrote:
Quoting Thomas Bushnell BSG (tb@becket.net):
martin f krafft <madduck@debian.org> 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?
For example, that greylisting puts significant load on systems that
deliver mail to us, and that it is only a question of time before
spam zombies retry.
|
hence a good way to achieve that, is to apply greylisting on hosts that
do not seem to be a valid SMTP server. good hints are:
* beeing listed in some RBL's (like 'dynamic IPs' rbls),
* not having a valid reverse DNS,
* using very curious EHLO/HELO,
* ...
all those checks are really cheap, and almost never makes the thing
greylist really big and well known SMTP's, since it's useless to
greylist SMTP's anyway, it only makes them unhappy (which is your
point).
as said a couple of times in that thread, such a policy is already in
place on alioth with quite a good result IMHO.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org |
|
| Back to top |
|
|
Thomas Bushnell BSG
*nix forums Guru
Joined: 20 Feb 2005
Posts: 806
|
| Posted: Mon Jul 10, 2006 12:10 am Post subject:
Re: greylisting on debian.org?
|
|
|
martin f krafft <madduck@debian.org> writes:
| Quote: | 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.
|
It's a violation of the standard. It is especially problematic,
because it is a violation against the spirit of being liberal in what
you accept, and conservative in what you require.
It assumes, for example, that the remote MTA will use the same IP
address each time it sends the message. If the remote MTA is a big
server farm, with a lot of different hosts that could be processing
the mail, what is your strategy for preventing essentially infinite
delay?
So far, all I have seen in response to this particular problem is to
say that "properly configured" includes an exactly accurate hardcoded
list of all such sites on the internet.
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. The graylisting host cannot then send mail to
such sites until they've been whitelisted, because when they try the
reverse connection out, it always gets a 4xx error. I've been bitten
by this one before.
Thomas
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Matthew R. Dempsky
*nix forums Guru Wannabe
Joined: 11 Mar 2006
Posts: 110
|
| Posted: Mon Jul 10, 2006 12:20 am Post subject:
Re: greylisting on debian.org?
|
|
|
On Sun, Jul 09, 2006 at 05:02:39PM -0700, Thomas Bushnell BSG wrote:
| Quote: | 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 also prevents mail from setups that use different servers for inbound
and outbound mail.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Thomas Bushnell BSG
*nix forums Guru
Joined: 20 Feb 2005
Posts: 806
|
| Posted: Mon Jul 10, 2006 1:40 am Post subject:
Re: greylisting on debian.org?
|
|
|
"Matthew R. Dempsky" <mrd@alkemio.org> writes:
| Quote: | 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 also prevents mail from setups that use different servers for inbound
and outbound mail.
|
Yes that's right. This is what happens when people start breaking
protocols in attempts to defeat spam. This is why I'm against
graylisting.
Thomas
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Henrique de Moraes Holsch
*nix forums Guru
Joined: 21 Feb 2005
Posts: 541
|
| Posted: Mon Jul 10, 2006 3:40 am Post subject:
Re: greylisting on debian.org?
|
|
|
On Sun, 09 Jul 2006, Thomas Bushnell BSG wrote:
| Quote: | It assumes, for example, that the remote MTA will use the same IP
address each time it sends the message. If the remote MTA is a big
|
The earlier *implementations* of greylisting did that, true. They were
simple-minded at best.
| Quote: | server farm, with a lot of different hosts that could be processing
the mail, what is your strategy for preventing essentially infinite
delay?
|
You can, for example, use dynamic IP supersets to do the greylisting
"triplet" match. Now the problem is a matter of creating the supersets in a
way to not break incoming email from outgoing-SMTP clusters.
You can also only graylist sites which match a set of conditions that flag
them as suspicious. Depending on what conditions you set, you do not have
the risk of blocking any server farms we would want to talk SMTP to.
| Quote: | So far, all I have seen in response to this particular problem is to
say that "properly configured" includes an exactly accurate hardcoded
list of all such sites on the internet.
|
Then you are hearing differently now.
| Quote: | 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. The graylisting host cannot then send mail to
such sites until they've been whitelisted, because when they try the
reverse connection out, it always gets a 4xx error. I've been bitten
|
Why will the host implementing incoming graylisting *always* get a 4xx error
on his outgoing message? I am curious.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Thomas Bushnell BSG
*nix forums Guru
Joined: 20 Feb 2005
Posts: 806
|
| Posted: Mon Jul 10, 2006 3:50 am Post subject:
Re: greylisting on debian.org?
|
|
|
Henrique de Moraes Holschuh <hmh@debian.org> writes:
| Quote: | You can, for example, use dynamic IP supersets to do the greylisting
"triplet" match. Now the problem is a matter of creating the supersets in a
way to not break incoming email from outgoing-SMTP clusters.
|
Is there a way of doing this which doesn't require you to know in
advance the setup of remote networks and such? Does it scale?
| Quote: | You can also only graylist sites which match a set of conditions that flag
them as suspicious. Depending on what conditions you set, you do not have
the risk of blocking any server farms we would want to talk SMTP to.
|
You don't have the risk? Are you saying that there is exactly *zero*
risk? Please, if you don't mean that, be more precise.
| Quote: | So far, all I have seen in response to this particular problem is to
say that "properly configured" includes an exactly accurate hardcoded
list of all such sites on the internet.
Then you are hearing differently now.
|
What ar the "dynamic IP supersets" you speak of, then?
| Quote: | 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. The graylisting host cannot then send mail to
such sites until they've been whitelisted, because when they try the
reverse connection out, it always gets a 4xx error. I've been bitten
Why will the host implementing incoming graylisting *always* get a 4xx error
on his outgoing message? I am curious.
|
The other way round.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Henrique de Moraes Holsch
*nix forums Guru
Joined: 21 Feb 2005
Posts: 541
|
| Posted: Mon Jul 10, 2006 4:20 am Post subject:
Re: greylisting on debian.org?
|
|
|
On Sun, 09 Jul 2006, Thomas Bushnell BSG wrote:
| Quote: | Henrique de Moraes Holschuh <hmh@debian.org> writes:
You can, for example, use dynamic IP supersets to do the greylisting
"triplet" match. Now the problem is a matter of creating the supersets in a
way to not break incoming email from outgoing-SMTP clusters.
Is there a way of doing this which doesn't require you to know in
advance the setup of remote networks and such? Does it scale?
|
Yes. The most absurd way is to consider every non-stolen, valid for the
public Internet IPv4 netblock as belonging to a single IP superset, and
flushing the graylisted database often (but mind your outgoing email retry
policy!).
Another is to
| Quote: | You can also only graylist sites which match a set of conditions that flag
them as suspicious. Depending on what conditions you set, you do not have
the risk of blocking any server farms we would want to talk SMTP to.
You don't have the risk? Are you saying that there is exactly *zero*
risk? Please, if you don't mean that, be more precise.
|
We == Debian.
Server farms we want to talk to == those professionaly run by
non-botnet-<censored>. We also want to talk to MTAs run by geeks on their
home connections, but those are *not* outgoing SMTP farms, so they are not
an issue.
If you graylist only people on DUL and with severily broken DNS, you don't
hit professionaly run SMTP farms like the one for gmail, yahoo, or any other
gigantic email provider. Chance is not zero, it is very small. And it is
even smaller if you consider it over a three-days retry window.
Never mind nobody suggested using a dumb, deprecated graylister for @d.o.
| Quote: | So far, all I have seen in response to this particular problem is to
say that "properly configured" includes an exactly accurate hardcoded
list of all such sites on the internet.
Then you are hearing differently now.
What ar the "dynamic IP supersets" you speak of, then?
|
In their dumbest form, match using big, static netmasks like 255.255.128.0.
That should give you a hint of what I am talking about.
| Quote: | 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. The graylisting host cannot then send mail to
such sites until they've been whitelisted, because when they try the
reverse connection out, it always gets a 4xx error. I've been bitten
Why will the host implementing incoming graylisting *always* get a 4xx error
on his outgoing message? I am curious.
The other way round.
|
Here's what I understood of what you wrote:
Alice wants to send email to Bob. Alice graylists incoming email. Bob does
sender verification trying to email people back before accepting a message.
You claim Alice cannot send mail to Bob because Bob will attempt to "almost
send email back to Alice", thus Bob's verification attempt will be
graylisted (with a 4xx), causing Bob to deny the delivery of Alice's message
with a 4xx.
If that's not correct, please clarify.
If it is correct, I am asking you *why* Alice's system will never let Bob's
verification probe through (thus allowing her email to be delivered to Bob).
I *can* see a scenario where delivery might never happen (I am ignoring
configuration error scenarios on Alice's side), but it depends on Alice also
doing the same type of sender verification, and on one or both sides
violating RFC 2821.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Henrique de Moraes Holsch
*nix forums Guru
Joined: 21 Feb 2005
Posts: 541
|
| Posted: Mon Jul 10, 2006 4:50 am Post subject:
Re: greylisting on debian.org?
|
|
|
On Mon, 10 Jul 2006, Henrique de Moraes Holschuh wrote:
| Quote: | Is there a way of doing this which doesn't require you to know in
advance the setup of remote networks and such? Does it scale?
Yes. The most absurd way is to consider every non-stolen, valid for the
public Internet IPv4 netblock as belonging to a single IP superset, and
flushing the graylisted database often (but mind your outgoing email retry
policy!).
Another is to
|
Argh. I must have deleted part of the message by mistyping in vim and didn't
notice it before sending. Sorry about that.
Another way to avoid problems with clusters is to assume certain common
setup patterns for server farms, like a cheap netmask match. This does, in
a way, "require you to know in advance the setup of remote networks", in the
sense that you need to know the common patterns that will be used. At
least now you are dealing with patterns, and not specific instances.
It is not as bad as it sounds. Small clusters of less than five machines
are not supposed to be an issue (you will graylist-approve the entire
cluster before the retry limit is over for reasonable retry policies).
Large clusters are almost always made of a number of islands of nodes with
IPs close to each other, and graylist-approving different islands will also
work if you don't manage to match all islands as a single set).
Scaling is obviously a problem if you have many incoming SMTP hosts, as the
graylisting knowledge should be shared among all of them. Other scaling
issues depend on how you calculate the IP sets, but for IP distance like the
above example, it is pratically the same as for dumb graylisting.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Thomas Bushnell BSG
*nix forums Guru
Joined: 20 Feb 2005
Posts: 806
|
| Posted: Mon Jul 10, 2006 5:00 am Post subject:
Re: greylisting on debian.org?
|
|
|
Henrique de Moraes Holschuh <hmh@debian.org> writes:
| Quote: | On Sun, 09 Jul 2006, Thomas Bushnell BSG wrote:
Henrique de Moraes Holschuh <hmh@debian.org> writes:
You can, for example, use dynamic IP supersets to do the greylisting
"triplet" match. Now the problem is a matter of creating the supersets in a
way to not break incoming email from outgoing-SMTP clusters.
Is there a way of doing this which doesn't require you to know in
advance the setup of remote networks and such? Does it scale?
Yes. The most absurd way is to consider every non-stolen, valid for the
public Internet IPv4 netblock as belonging to a single IP superset, and
flushing the graylisted database often (but mind your outgoing email retry
policy!).
|
I don't think I understand just what you're saying. Can you spell out
the details for me?
| Quote: | You can also only graylist sites which match a set of conditions that flag
them as suspicious. Depending on what conditions you set, you do not have
the risk of blocking any server farms we would want to talk SMTP to.
You don't have the risk? Are you saying that there is exactly *zero*
risk? Please, if you don't mean that, be more precise.
We == Debian.
Server farms we want to talk to == those professionaly run by
non-botnet-<censored>. We also want to talk to MTAs run by geeks on their
home connections, but those are *not* outgoing SMTP farms, so they are not
an issue.
|
Keeping a list of such server farms is exactly what I meant by a
nonworking pseudo-solution. I said, specifically, "is there a way of
doing this which doesn't require you to know in advance the setup of
remote networks and such?" This was the same idea I had already said
in terms of "all I have seen is to...[include] an exactly accurate
hardcoded list of all such sites."
It distresses me that I have said twice now that a "solution" which
requires a hardcoded list of special sites exempted from the rules is
not a solution I regard as answering my objection.
| Quote: | Never mind nobody suggested using a dumb, deprecated graylister for @d.o.
|
Any graylister which requires a specific list of sites counts as a
dumb one in my book. I want a solution which specifically *never*
needs any preset hardcoded "this set of addresses/domains gets a
pass".
| Quote: | In their dumbest form, match using big, static netmasks like 255.255.128.0.
That should give you a hint of what I am talking about.
|
A hardcoded list is the problem. Got it? A loose hardcoded list is
still a problem.
| Quote: | 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. The graylisting host cannot then send mail to
such sites until they've been whitelisted, because when they try the
reverse connection out, it always gets a 4xx error. I've been bitten
Why will the host implementing incoming graylisting *always* get a 4xx error
on his outgoing message? I am curious.
The other way round.
Here's what I understood of what you wrote:
Alice wants to send email to Bob. Alice graylists incoming email. Bob does
sender verification trying to email people back before accepting a message.
You claim Alice cannot send mail to Bob because Bob will attempt to "almost
send email back to Alice", thus Bob's verification attempt will be
graylisted (with a 4xx), causing Bob to deny the delivery of Alice's message
with a 4xx.
If that's not correct, please clarify.
If it is correct, I am asking you *why* Alice's system will never let Bob's
verification probe through (thus allowing her email to be delivered to Bob).
|
Because Bob never sends a complete email message to Alice.
| Quote: | I *can* see a scenario where delivery might never happen (I am ignoring
configuration error scenarios on Alice's side), but it depends on Alice also
doing the same type of sender verification, and on one or both sides
violating RFC 2821.
|
Doing sender verification and graylisting are both violations of the
RFCs. You can hardly say "this will work as long as everyone else
follows the RFC" when you aren't doing so yourself. My point is that
this is a case where two RFC-noncompliant spam pseudo-solutions
interact badly, because each is making up their own new requirements,
not in the RFCs, and those new requirements interact poorly.
If your system causes any RFC-compliant mail to lose, then your system
loses. So far you have argued at best that you are willing to ignore
the cases where it loses. Great. I'm not.
Thomas
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Thomas Bushnell BSG
*nix forums Guru
Joined: 20 Feb 2005
Posts: 806
|
| Posted: Mon Jul 10, 2006 5:10 am Post subject:
Re: greylisting on debian.org?
|
|
|
Henrique de Moraes Holschuh <hmh@debian.org> writes:
| Quote: | Another way to avoid problems with clusters is to assume certain common
setup patterns for server farms, like a cheap netmask match. This does, in
a way, "require you to know in advance the setup of remote networks", in the
sense that you need to know the common patterns that will be used. At
least now you are dealing with patterns, and not specific instances.
|
This is not adequate, sorry, at least, not in my book.
I am concerned that you not use a spam-defeating technique which
blocks perfectly legitimate and standards-compliant email.
What I object to is specifically the attempt to create *new*
standards, by blocking legitimate email. There is no standard
requirement that a server farm use a small netmask or one of a set of
common patterns. If you want such a requirement, please propose one
to the IETF. You know how.
Saying "if everyone followed rule X (and heck, lots of people already
do!) my system would work perfectly" is irrelevant to me. What
matters to me is "my scheme works when everyone follows the actual
public standards for email."
Thomas
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Sat Nov 22, 2008 7:05 am | All times are GMT
|
|
Hackers | Car Finance | Cheap mp3 players | Internet Advertising | Loans
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
Linux
»
Distributions
»
Debian
»
devel
