RBL Features for SMTP

Hi,

everbody has different opinions about security.

I think RBLs are a good way to prevent spam
from even reaching the smtp agent.
another way would be greylisting.

I think security and stability are the most
important topics for a mail server.
Also a good interaction with other tools
like amavisd-new, clamav....

Bye
Sebastian

Am 01.08.2006 um 22:18 schrieb Paul Gear:

> Sebastian Döll wrote:
>> Hallo,
>>
>> I've wondered where the RBL in the SMTP Agent has
gone?
>
> RBLs are a bad idea anyway.  
>
> --  
> Paul
> <http://paulgear.webhop
.net>
> --
> Tired of paying for Microsoft Office?  Running an
illegal copy and  
> want
> to make it legal?  Try OpenOffice.org!  It's free and
does most of the
> things Microsoft Office does.  <http://www.openoffice.o
rg>
>
> _______________________________________________
> Hula-general mailing list
> Hula-generalforge.novell.com
> http://forge.novell.com/mailman/listinfo/hula-general

_______________________________________________
Hula-general mailing list
Hula-generalforge.novell.com
http://forge.novell.com/mailman/listinfo/hula-general

Hi,

I personally _hate_ greylisting. It creates admin overhead
without real 
gain. With RBL you can
force people to secure their systems, with greylisting you
create calls 
from users to the admin
since they get an error message from the mailer. In most
configurations 
I know the user is informed
that his mail could not be delivered and that the mailer
will continue 
to try deliver the message. The
problem I see is that as soon as enough people use
greylisting it will 
be without any gain since the
spammers will implement resending the mail in their bots.
They want you 
to get their spam, right?
I agree on the different opinions about security. And I
don't really see 
a problem with RBLs since
all other effective means against spam also require outside
trust and/or 
produce false positives and
false negatives. Just use one that is not overly aggressive.
BTW is there a way in hula to immediately drop connections
if the sender 
tries something that is
not conform to the protocol-standards? That blocks many
spammers at our 
gateway atm.

Greetings,
Stefan

Sebastian Döll wrote:

> Hi,
>
> everbody has different opinions about security.
>
> I think RBLs are a good way to prevent spam
> from even reaching the smtp agent.
> another way would be greylisting.
>
> I think security and stability are the most
> important topics for a mail server.
> Also a good interaction with other tools
> like amavisd-new, clamav....
>
> Bye
> Sebastian
>
> Am 01.08.2006 um 22:18 schrieb Paul Gear:
>
>> Sebastian Döll wrote:
>>
>>> Hallo,
>>>
>>> I've wondered where the RBL in the SMTP Agent
has gone?
>>
>>
>> RBLs are a bad idea anyway.  
>>
>> --  Paul
>> <http://paulgear.webhop
.net>
>> -- 
>> Tired of paying for Microsoft Office?  Running an
illegal copy and  want
>> to make it legal?  Try OpenOffice.org!  It's free
and does most of the
>> things Microsoft Office does.  <http://www.openoffice.o
rg>
>>
>> _______________________________________________
>> Hula-general mailing list
>> Hula-generalforge.novell.com
>> http://forge.novell.com/mailman/listinfo/hula-general
>
>
> _______________________________________________
> Hula-general mailing list
> Hula-generalforge.novell.com
> http://forge.novell.com/mailman/listinfo/hula-general
>

_______________________________________________
Hula-general mailing list
Hula-generalforge.novell.com
http://forge.novell.com/mailman/listinfo/hula-general

Hi,

at the moment we use a combination of postfix + openldap +
amavisd- 
new + clamav
on three produtive servers. Greylisting is no problem with
postfix,  
because you can
exactly specify the return message/code for the client. When
the  
client uses the
protocoll specifications it should try it again. But that's
only our  
solution.

Does anybody knows a good way to integrate amavisd-new into
hula?

Bye

Am 02.08.2006 um 11:43 schrieb Stefan Walther:

> Hi,
>
> I personally _hate_ greylisting. It creates admin
overhead without  
> real gain. With RBL you can
> force people to secure their systems, with greylisting
you create  
> calls from users to the admin
> since they get an error message from the mailer. In
most  
> configurations I know the user is informed
> that his mail could not be delivered and that the
mailer will  
> continue to try deliver the message. The
> problem I see is that as soon as enough people use
greylisting it  
> will be without any gain since the
> spammers will implement resending the mail in their
bots. They want  
> you to get their spam, right?
> I agree on the different opinions about security. And I
don't  
> really see a problem with RBLs since
> all other effective means against spam also require
outside trust  
> and/or produce false positives and
> false negatives. Just use one that is not overly
aggressive.
> BTW is there a way in hula to immediately drop
connections if the  
> sender tries something that is
> not conform to the protocol-standards? That blocks many
spammers at  
> our gateway atm.
>
> Greetings,
> Stefan
>
> Sebastian Döll wrote:
>
>> Hi,
>>
>> everbody has different opinions about security.
>>
>> I think RBLs are a good way to prevent spam
>> from even reaching the smtp agent.
>> another way would be greylisting.
>>
>> I think security and stability are the most
>> important topics for a mail server.
>> Also a good interaction with other tools
>> like amavisd-new, clamav....
>>
>> Bye
>> Sebastian
>>
>> Am 01.08.2006 um 22:18 schrieb Paul Gear:
>>
>>> Sebastian Döll wrote:
>>>
>>>> Hallo,
>>>>
>>>> I've wondered where the RBL in the SMTP
Agent has gone?
>>>
>>>
>>> RBLs are a bad idea anyway.  
>>>
>>> --  Paul
>>> <http://paulgear.webhop
.net>
>>> -- 
>>> Tired of paying for Microsoft Office?  Running
an illegal copy  
>>> and  want
>>> to make it legal?  Try OpenOffice.org!  It's
free and does most  
>>> of the
>>> things Microsoft Office does.  <http://www.openoffice.o
rg>
>>>
>>> _______________________________________________
>>> Hula-general mailing list
>>> Hula-generalforge.novell.com
>>> http://forge.novell.com/mailman/listinfo/hula-general
>>
>>
>> _______________________________________________
>> Hula-general mailing list
>> Hula-generalforge.novell.com
>> http://forge.novell.com/mailman/listinfo/hula-general
>>
>
>

_______________________________________________
Hula-general mailing list
Hula-generalforge.novell.com
http://forge.novell.com/mailman/listinfo/hula-general

Hi,

thats not the problem I meant. For each greylisted message
the sender (= 
the user) gets a message
from the sending mailer that his message could not be
immediatlely 
delivered but that his message
will be sent later. The average user now phones his admin
since he 
doesn't know what went wrong,
perhaps thinking the adress he used was not correct. The
admin now has 
to lookup the logs and explains
the situation to the user. Now the average user is confused
and asks the 
admin to make sure the message
gets delivered. Just remember that the average mail user
nowadays is not 
necessarily computer savvy.
I just love those implementations which do the greylisting
for each and 
every mail they get and don't do
at least a whitelisting for servers that have sent
successfully in the 
past...

Greetings
Stefan

Sebastian Döll wrote:

> Hi,
>
> at the moment we use a combination of postfix +
openldap + amavisd- 
> new + clamav
> on three produtive servers. Greylisting is no problem
with postfix,  
> because you can
> exactly specify the return message/code for the client.
When the  
> client uses the
> protocoll specifications it should try it again. But
that's only our  
> solution.
>
> Does anybody knows a good way to integrate amavisd-new
into
> hula?
>
> Bye
>
> Am 02.08.2006 um 11:43 schrieb Stefan Walther:
>
>> Hi,
>>
>> I personally _hate_ greylisting. It creates admin
overhead without  
>> real gain. With RBL you can
>> force people to secure their systems, with
greylisting you create  
>> calls from users to the admin
>> since they get an error message from the mailer. In
most  
>> configurations I know the user is informed
>> that his mail could not be delivered and that the
mailer will  
>> continue to try deliver the message. The
>> problem I see is that as soon as enough people use
greylisting it  
>> will be without any gain since the
>> spammers will implement resending the mail in their
bots. They want  
>> you to get their spam, right?
>> I agree on the different opinions about security.
And I don't  really 
>> see a problem with RBLs since
>> all other effective means against spam also require
outside trust  
>> and/or produce false positives and
>> false negatives. Just use one that is not overly
aggressive.
>> BTW is there a way in hula to immediately drop
connections if the  
>> sender tries something that is
>> not conform to the protocol-standards? That blocks
many spammers at  
>> our gateway atm.
>>
>> Greetings,
>> Stefan
>>
>> Sebastian Döll wrote:
>>
>>> Hi,
>>>
>>> everbody has different opinions about security.
>>>
>>> I think RBLs are a good way to prevent spam
>>> from even reaching the smtp agent.
>>> another way would be greylisting.
>>>
>>> I think security and stability are the most
>>> important topics for a mail server.
>>> Also a good interaction with other tools
>>> like amavisd-new, clamav....
>>>
>>> Bye
>>> Sebastian
>>>
>>> Am 01.08.2006 um 22:18 schrieb Paul Gear:
>>>
>>>> Sebastian Döll wrote:
>>>>
>>>>> Hallo,
>>>>>
>>>>> I've wondered where the RBL in the
SMTP Agent has gone?
>>>>
>>>>
>>>>
>>>> RBLs are a bad idea anyway.  
>>>>
>>>> --  Paul
>>>> <http://paulgear.webhop
.net>
>>>> -- 
>>>> Tired of paying for Microsoft Office? 
Running an illegal copy  
>>>> and  want
>>>> to make it legal?  Try OpenOffice.org! 
It's free and does most  of 
>>>> the
>>>> things Microsoft Office does.  <http://www.openoffice.o
rg>
>>>>
>>>>
_______________________________________________
>>>> Hula-general mailing list
>>>> Hula-generalforge.novell.com
>>>> http://forge.novell.com/mailman/listinfo/hula-general
>>>
>>>
>>>
>>> _______________________________________________
>>> Hula-general mailing list
>>> Hula-generalforge.novell.com
>>> http://forge.novell.com/mailman/listinfo/hula-general
>>>
>>
>>
>
> _______________________________________________
> Hula-general mailing list
> Hula-generalforge.novell.com
> http://forge.novell.com/mailman/listinfo/hula-general
>

_______________________________________________
Hula-general mailing list
Hula-generalforge.novell.com
http://forge.novell.com/mailman/listinfo/hula-general

Hi Sebastian,

Hula already has support for using amavisd and it works
quiet well.
We are using Hula r1438.


> Hi,
> 
> at the moment we use a combination of postfix +
openldap + amavisd- 
> new + clamav
> on three produtive servers. Greylisting is no problem
with postfix,  
> because you can
> exactly specify the return message/code for the client.
When the  
> client uses the
> protocoll specifications it should try it again. But
that's only our  
> solution.
> 
> Does anybody knows a good way to integrate amavisd-new
into
> hula?
> 
> Bye
> 
> Am 02.08.2006 um 11:43 schrieb Stefan Walther:
> 
> > Hi,
> >
> > I personally _hate_ greylisting. It creates admin
overhead without  
> > real gain. With RBL you can
> > force people to secure their systems, with
greylisting you create  
> > calls from users to the admin
> > since they get an error message from the mailer.
In most  
> > configurations I know the user is informed
> > that his mail could not be delivered and that the
mailer will  
> > continue to try deliver the message. The
> > problem I see is that as soon as enough people use
greylisting it  
> > will be without any gain since the
> > spammers will implement resending the mail in
their bots. They want  
> > you to get their spam, right?
> > I agree on the different opinions about security.
And I don't  
> > really see a problem with RBLs since
> > all other effective means against spam also
require outside trust  
> > and/or produce false positives and
> > false negatives. Just use one that is not overly
aggressive.
> > BTW is there a way in hula to immediately drop
connections if the  
> > sender tries something that is
> > not conform to the protocol-standards? That blocks
many spammers at  
> > our gateway atm.
> >
> > Greetings,
> > Stefan
> >
> > Sebastian Döll wrote:
> >
> >> Hi,
> >>
> >> everbody has different opinions about
security.
> >>
> >> I think RBLs are a good way to prevent spam
> >> from even reaching the smtp agent.
> >> another way would be greylisting.
> >>
> >> I think security and stability are the most
> >> important topics for a mail server.
> >> Also a good interaction with other tools
> >> like amavisd-new, clamav....
> >>
> >> Bye
> >> Sebastian
> >>
> >> Am 01.08.2006 um 22:18 schrieb Paul Gear:
> >>
> >>> Sebastian Döll wrote:
> >>>
> >>>> Hallo,
> >>>>
> >>>> I've wondered where the RBL in the
SMTP Agent has gone?
> >>>
> >>>
> >>> RBLs are a bad idea anyway.  
> >>>
> >>> --  Paul
> >>> <http://paulgear.webhop
.net>
> >>> -- 
> >>> Tired of paying for Microsoft Office? 
Running an illegal copy  
> >>> and  want
> >>> to make it legal?  Try OpenOffice.org! 
It's free and does most  
> >>> of the
> >>> things Microsoft Office does.  <http://www.openoffice.o
rg>
> >>>
> >>>
_______________________________________________
> >>> Hula-general mailing list
> >>> Hula-generalforge.novell.com
> >>> http://forge.novell.com/mailman/listinfo/hula-general
> >>
> >>
> >>
_______________________________________________
> >> Hula-general mailing list
> >> Hula-generalforge.novell.com
> >> http://forge.novell.com/mailman/listinfo/hula-general
> >>
> >
> >
> 
> _______________________________________________
> Hula-general mailing list
> Hula-generalforge.novell.com
> http://forge.novell.com/mailman/listinfo/hula-general
> 
-- 
Best regards Johannes Gubo
Reisinger GmbH [Germany]
- Development -
D - 90562 Kalchreuth
www: http://www.reisinger.de
email: j.guboreisinger.de
_______________________________________________
Hula-general mailing list
Hula-generalforge.novell.com
http://forge.novell.com/mailman/listinfo/hula-general

Hi,

in which way are you doing it?
I don't know the architecture of Hula quite good
at that moment. What's also interessting for
me is, how www.myrealbox.com is setup with hula
and especially the singup process?

bye
Sebastian


Am 02.08.2006 um 13:49 schrieb Johannes Gubo:

> Hi Sebastian,
>
> Hula already has support for using amavisd and it works
quiet well.
> We are using Hula r1438.
>
>
>> Hi,
>>
>> at the moment we use a combination of postfix +
openldap + amavisd-
>> new + clamav
>> on three produtive servers. Greylisting is no
problem with postfix,
>> because you can
>> exactly specify the return message/code for the
client. When the
>> client uses the
>> protocoll specifications it should try it again.
But that's only our
>> solution.
>>
>> Does anybody knows a good way to integrate
amavisd-new into
>> hula?
>>
>> Bye
>>
>> Am 02.08.2006 um 11:43 schrieb Stefan Walther:
>>
>>> Hi,
>>>
>>> I personally _hate_ greylisting. It creates
admin overhead without
>>> real gain. With RBL you can
>>> force people to secure their systems, with
greylisting you create
>>> calls from users to the admin
>>> since they get an error message from the
mailer. In most
>>> configurations I know the user is informed
>>> that his mail could not be delivered and that
the mailer will
>>> continue to try deliver the message. The
>>> problem I see is that as soon as enough people
use greylisting it
>>> will be without any gain since the
>>> spammers will implement resending the mail in
their bots. They want
>>> you to get their spam, right?
>>> I agree on the different opinions about
security. And I don't
>>> really see a problem with RBLs since
>>> all other effective means against spam also
require outside trust
>>> and/or produce false positives and
>>> false negatives. Just use one that is not
overly aggressive.
>>> BTW is there a way in hula to immediately drop
connections if the
>>> sender tries something that is
>>> not conform to the protocol-standards? That
blocks many spammers at
>>> our gateway atm.
>>>
>>> Greetings,
>>> Stefan
>>>
>>> Sebastian Döll wrote:
>>>
>>>> Hi,
>>>>
>>>> everbody has different opinions about
security.
>>>>
>>>> I think RBLs are a good way to prevent spam
>>>> from even reaching the smtp agent.
>>>> another way would be greylisting.
>>>>
>>>> I think security and stability are the most
>>>> important topics for a mail server.
>>>> Also a good interaction with other tools
>>>> like amavisd-new, clamav....
>>>>
>>>> Bye
>>>> Sebastian
>>>>
>>>> Am 01.08.2006 um 22:18 schrieb Paul Gear:
>>>>
>>>>> Sebastian Döll wrote:
>>>>>
>>>>>> Hallo,
>>>>>>
>>>>>> I've wondered where the RBL in the
SMTP Agent has gone?
>>>>>
>>>>>
>>>>> RBLs are a bad idea anyway.  
>>>>>
>>>>> --  Paul
>>>>> <http://paulgear.webhop
.net>
>>>>> -- 
>>>>> Tired of paying for Microsoft Office? 
Running an illegal copy
>>>>> and  want
>>>>> to make it legal?  Try OpenOffice.org! 
It's free and does most
>>>>> of the
>>>>> things Microsoft Office does.  <http://www.openoffice.o
rg>
>>>>>
>>>>>
_______________________________________________
>>>>> Hula-general mailing list
>>>>> Hula-generalforge.novell.com
>>>>> http://forge.novell.com/mailman/listinfo/hula-general
>>>>
>>>>
>>>>
_______________________________________________
>>>> Hula-general mailing list
>>>> Hula-generalforge.novell.com
>>>> http://forge.novell.com/mailman/listinfo/hula-general
>>>>
>>>
>>>
>>
>> _______________________________________________
>> Hula-general mailing list
>> Hula-generalforge.novell.com
>> http://forge.novell.com/mailman/listinfo/hula-general
>>
> -- 
> Best regards Johannes Gubo
> Reisinger GmbH [Germany]
> - Development -
> D - 90562 Kalchreuth
> www: http://www.reisinger.de
> email: j.guboreisinger.de

_______________________________________________
Hula-general mailing list
Hula-generalforge.novell.com
http://forge.novell.com/mailman/listinfo/hula-general

Stefan Walther wrote:

> For each greylisted message the sender (= the user)
gets a message
> from the sending mailer that his message could not be
immediatlely 
> delivered but that his message will be sent later.  

This depends on your mail-server configuration - we never
send anyone a 
message just because of a greylisting.

> I just love those implementations which do the
greylisting for each and 
> every mail they get and don't do at least a
whitelisting for servers 
 > that have sent successfully in the past...

That is the default postgrey behaviour.


/Per Jessen, Zurich
_______________________________________________
Hula-general mailing list
Hula-generalforge.novell.com
http://forge.novell.com/mailman/listinfo/hula-general

Hi,

what would be a good way to integrate greylisting into hula?

btw. can some please discribe, how amavisd-new could
be used with hula? i only know it for postfix or sendmail.

bye
sebastian

Am 02.08.2006 um 20:50 schrieb Per Jessen:

> Stefan Walther wrote:
>
>> For each greylisted message the sender (= the user)
gets a message
>> from the sending mailer that his message could not
be immediatlely  
>> delivered but that his message will be sent later.
>
> This depends on your mail-server configuration - we
never send  
> anyone a message just because of a greylisting.
>
>> I just love those implementations which do the
greylisting for  
>> each and every mail they get and don't do at least
a whitelisting  
>> for servers
> > that have sent successfully in the past...
>
> That is the default postgrey behaviour.
>
>
> /Per Jessen, Zurich
> _______________________________________________
> Hula-general mailing list
> Hula-generalforge.novell.com
> http://forge.novell.com/mailman/listinfo/hula-general
>

_______________________________________________
Hula-general mailing list
Hula-generalforge.novell.com
http://forge.novell.com/mailman/listinfo/hula-general

Sebastian Döll wrote:
> Hi,
> 
> what would be a good way to integrate greylisting into
hula?

As a complete newbie to Hula, I would say don't - just do
greylisting in 
postfix.


/Per Jessen, Zurich
_______________________________________________
Hula-general mailing list
Hula-generalforge.novell.com
http://forge.novell.com/mailman/listinfo/hula-general

Hi,

what do you do if your message gets greylisted a second time
due to some 
error? Those error
messages are created for a cause. If you suppress error
messages due to 
greylisting you could
miss not having successfully sent an email. Just imagine the
receiving 
mailserver has a problem
and repeatedly greylists your message, perhaps he can't
store the 
greylisting event for some reason.
How do you make sure your user doesn't think his email
arrived? Besides 
that, is it even allowed
in the specs to supress error notifications to the user?
Additionally I don't think every mailer supports the
suppresson of 
notifications.

Greetings
Stefan

Sebastian Döll wrote:

> Hi,
>
> the mail server must not send this message,
> that belongs to your configuration and also belongs to
> the greylisting. Because normaly the mail server
> sends only a 450 temporary error code, with text
"Service temporarily 
> unavailable".
> That's the way we do it and it works
> quite well. But it's up to the admin 
>
> bye
>
> Am 02.08.2006 um 13:40 schrieb Stefan Walther:
>
>> Hi,
>>
>> thats not the problem I meant. For each greylisted
message the sender 
>> (= the user) gets a message
>> from the sending mailer that his message could not
be immediatlely 
>> delivered but that his message
>> will be sent later. The average user now phones his
admin since he 
>> doesn't know what went wrong,
>> perhaps thinking the adress he used was not
correct. The admin now 
>> has to lookup the logs and explains
>> the situation to the user. Now the average user is
confused and asks 
>> the admin to make sure the message
>> gets delivered. Just remember that the average mail
user nowadays is 
>> not necessarily computer savvy.
>> I just love those implementations which do the
greylisting for each 
>> and every mail they get and don't do
>> at least a whitelisting for servers that have sent
successfully in 
>> the past...
>>
>> Greetings
>> Stefan
>>
>> Sebastian Döll wrote:
>>
>>> Hi,
>>>
>>> at the moment we use a combination of postfix +
openldap + amavisd- 
>>> new + clamav
>>> on three produtive servers. Greylisting is no
problem with postfix,  
>>> because you can
>>> exactly specify the return message/code for the
client. When the  
>>> client uses the
>>> protocoll specifications it should try it
again. But that's only 
>>> our  solution.
>>>
>>> Does anybody knows a good way to integrate
amavisd-new into
>>> hula?
>>>
>>> Bye
>>>
>>> Am 02.08.2006 um 11:43 schrieb Stefan Walther:
>>>
>>>> Hi,
>>>>
>>>> I personally _hate_ greylisting. It creates
admin overhead without  
>>>> real gain. With RBL you can
>>>> force people to secure their systems, with
greylisting you create  
>>>> calls from users to the admin
>>>> since they get an error message from the
mailer. In most  
>>>> configurations I know the user is informed
>>>> that his mail could not be delivered and
that the mailer will  
>>>> continue to try deliver the message. The
>>>> problem I see is that as soon as enough
people use greylisting it  
>>>> will be without any gain since the
>>>> spammers will implement resending the mail
in their bots. They 
>>>> want  you to get their spam, right?
>>>> I agree on the different opinions about
security. And I don't  
>>>> really see a problem with RBLs since
>>>> all other effective means against spam also
require outside trust  
>>>> and/or produce false positives and
>>>> false negatives. Just use one that is not
overly aggressive.
>>>> BTW is there a way in hula to immediately
drop connections if the  
>>>> sender tries something that is
>>>> not conform to the protocol-standards? That
blocks many spammers 
>>>> at  our gateway atm.
>>>>
>>>> Greetings,
>>>> Stefan
>>>>
>>>> Sebastian Döll wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> everbody has different opinions about
security.
>>>>>
>>>>> I think RBLs are a good way to prevent
spam
>>>>> from even reaching the smtp agent.
>>>>> another way would be greylisting.
>>>>>
>>>>> I think security and stability are the
most
>>>>> important topics for a mail server.
>>>>> Also a good interaction with other
tools
>>>>> like amavisd-new, clamav....
>>>>>
>>>>> Bye
>>>>> Sebastian
>>>>>
>>>>> Am 01.08.2006 um 22:18 schrieb Paul
Gear:
>>>>>
>>>>>> Sebastian Döll wrote:
>>>>>>
>>>>>>> Hallo,
>>>>>>>
>>>>>>> I've wondered where the RBL in
the SMTP Agent has gone?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> RBLs are a bad idea anyway.  
>>>>>>
>>>>>> --  Paul
>>>>>> <http://paulgear.webhop
.net>
>>>>>> -- 
>>>>>> Tired of paying for Microsoft
Office?  Running an illegal copy  
>>>>>> and  want
>>>>>> to make it legal?  Try
OpenOffice.org!  It's free and does most  
>>>>>> of the
>>>>>> things Microsoft Office does. 
<http://www.openoffice.o
rg>
>>>>>>
>>>>>>
_______________________________________________
>>>>>> Hula-general mailing list
>>>>>> Hula-generalforge.novell.com
<mailto:Hula-generalforge.novell.com>
>>>>>> http://forge.novell.com/mailman/listinfo/hula-general
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
_______________________________________________
>>>>> Hula-general mailing list
>>>>> Hula-generalforge.novell.com
<mailto:Hula-generalforge.novell.com>
>>>>> http://forge.novell.com/mailman/listinfo/hula-general
>>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Hula-general mailing list
>>> Hula-generalforge.novell.com
<mailto:Hula-generalforge.novell.com>
>>> http://forge.novell.com/mailman/listinfo/hula-general
>>>
>>
>>
>
>--------------------------------------------------------
----------------
>
>_______________________________________________
>Hula-general mailing list
>Hula-generalforge.novell.com
>http://forge.novell.com/mailman/listinfo/hula-general
>  
>

_______________________________________________
Hula-general mailing list
Hula-generalforge.novell.com
http://forge.novell.com/mailman/listinfo/hula-general

On Thu, 2006-08-03 at 08:31 +0200, Stefan Walther wrote:
> what do you do if your message gets greylisted a second
time due to some 
> error? Those error messages are created for a cause. If
you suppress error messages due to 
> greylisting you could miss not having successfully sent
an email.

Greylisting doesn't invoke an error on the receiving SMTP
server; it
simulates a temporary problem. The person who sent the
e-mail should be
none the wiser - they should only find out when a permanent
problem is
found. A correct SMTP server will handle temporary problems
itself.

By default with exim, I think it's something like you get a
warning
after one and four days of temporary errors, and then it
permanently
fails after a week - so, if there was a persistent error in
the
greylisting, you'd find out about it anyway.

None of this is to say I particularly like RBLs or
greylisting. RBLs
strike me as a particularly effective way of pissing people
off, and I
would never run them on a business server, and greylisting
infuriates
those people who run their own SMTP servers on their laptops
(which a
surprisingly high number of geeks-who-should-know-better
do).

People will probably want both these options in Hula. The
simplest
method though, at least for Hula 1.0, might well be to hide
Hula behind
a postfix or something.

Cheers,

Alex.

_______________________________________________
Hula-general mailing list
Hula-generalforge.novell.com
http://forge.novell.com/mailman/listinfo/hula-general

Stefan Walther wrote:
> Hi,
> 
> I personally _hate_ greylisting. It creates admin
overhead without
> real gain. With RBL you can force people to secure
their systems,
> with greylisting you create calls from users to the
admin since they
> get an error message from the mailer.

I wonder whether we're talking about the same technique?!? 
The
greylisting *i* know knocks back 90-95% of all spam without
any
administration effort.  See this graph for details of our
legitimate vs.
illegitimate mail volumes since we implemented it at work:
	http://
paulgear.webhop.net/stats-20060803.png

On the other hand, whenever i email someone who uses RBLs,
since i'm on
a dynamic IP, i have to manually edit the mail server config
on my
machine.  It creates hard failures rather than soft ones,
which require
intervention every time.  Greylisting will just work if you
leave it for
a bit (unless the mail is being sent by a badly-behaved mail
server).

I did an experiment with greylisting at home: on 6 May this
year, i put
some dummy email addresses on my (infrequently visited) home
page.  I
then added one account that these dummy addresses were
aliased to.
Between 6 May & 19 July, the mail account received *no
email*.  On 19
July, i exempted this account from greylisting.  Since that
time, i've
received 67 emails to these accounts.  They have never been
used
anywhere and have never appeared on any web page until 6
May.  My
conclusion: spammers have efficient web crawlers, but rather
ineffective
mail retry code.

For me, the effectiveness of greylisting speaks for itself. 
It slows
spam from a flood to a trickle.  I wouldn't consider
implementing a new
mail server without it!

-- 
Paul
<http://paulgear.webhop
.net>
--
Did you know?  Sending and receiving Microsoft Office
documents via
email can put your computer and others' at risk.  Always
scan
attachments for viruses before you open them, and export
your documents
to a portable format such as PDF or HTML before sending
them.

_______________________________________________
Hula-general mailing list
Hula-generalforge.novell.com
http://forge.novell.com/mailman/listinfo/hula-general

Hi,

The default of exim seems to make sense. Unfortunately you
can't set 
this on all mailers.
There are mailers which will bother the sending user after
the first 
temporary error. Are
those mailers breaking specs? If no then this would be a
problem of 
greylisting, not the mailer.

Greetings,

Stefan

Alex Hudson wrote:

>On Thu, 2006-08-03 at 08:31 +0200, Stefan Walther wrote:
>  
>
>>what do you do if your message gets greylisted a
second time due to some 
>>error? Those error messages are created for a cause.
If you suppress error messages due to 
>>greylisting you could miss not having successfully
sent an email.
>>    
>>
>
>Greylisting doesn't invoke an error on the receiving
SMTP server; it
>simulates a temporary problem. The person who sent the
e-mail should be
>none the wiser - they should only find out when a
permanent problem is
>found. A correct SMTP server will handle temporary
problems itself.
>
>By default with exim, I think it's something like you
get a warning
>after one and four days of temporary errors, and then it
permanently
>fails after a week - so, if there was a persistent error
in the
>greylisting, you'd find out about it anyway.
>
>None of this is to say I particularly like RBLs or
greylisting. RBLs
>strike me as a particularly effective way of pissing
people off, and I
>would never run them on a business server, and
greylisting infuriates
>those people who run their own SMTP servers on their
laptops (which a
>surprisingly high number of geeks-who-should-know-better
do).
>
>People will probably want both these options in Hula.
The simplest
>method though, at least for Hula 1.0, might well be to
hide Hula behind
>a postfix or something.
>
>Cheers,
>
>Alex.
>
>_______________________________________________
>Hula-general mailing list
>Hula-generalforge.novell.com
>http://forge.novell.com/mailman/listinfo/hula-general
>
>  
>

_______________________________________________
Hula-general mailing list
Hula-generalforge.novell.com
http://forge.novell.com/mailman/listinfo/hula-general

On Thu, 2006-08-03 at 13:15 +0200, Stefan Walther wrote:
> The default of exim seems to make sense. Unfortunately
you can't set 
> this on all mailers.

This is true, but in practise the default settings
shouldn't cause a
problems with greylisting. Configuration of this is actually
a "must" in
the SMTP spec., too.

> There are mailers which will bother the sending user
after the first 
> temporary error. Are those mailers breaking specs? 

Well, 4.5.2 says vaguely:

   Any queuing strategy MUST include timeouts on all
activities on a
   per-command basis.  A queuing strategy MUST NOT send
error messages
   in response to error messages under any circumstances.

I think that's actually talking about the SMTP conversation
rather than
sending bounces, but the principle is pretty much there: if
you have a
retry strategy, it's pretty poor show to generate errors in
what are
considered "normal" (albeit unlikely)
conditions.

I would consider such a mailer broken, personally, and
don't know of any
that have that behaviour - which software are you thinking
of?

As I said, I don't particularly like greylisting. But, so
long as the
timeouts are relatively short (<30mn), they shouldn't be
noticeable to
SMTP users (unless you run a really flakey SMTP service
anyway, at which
point the anti-spam strategy of making your server
artificially even
more unreliable comes back to bite you in the bum).

Cheers,

Alex.

_______________________________________________
Hula-general mailing list
Hula-generalforge.novell.com
http://forge.novell.com/mailman/listinfo/hula-general

Alex Hudson wrote:
> None of this is to say I particularly like RBLs or
greylisting. RBLs
> strike me as a particularly effective way of pissing
people off, 

It depends on what you keep on your RBLs - refusing to
accept mail from 
servers on dial-up addresses is a particularly good use,
IMHO.

 > and I would never run them on a business server,

You don't even block open relays?

 >and greylisting infuriates those people who run their
own SMTP servers on
 > their laptops (which a surprisingly high number of
geeks-who-should-
 >know-better do).

In a business environment I wouldn't think twice about
pissing off a 
geek with a mail-server on a laptop.  They really don't
count and if my 
greylisting infuriates them, tough.


/Per Jessen, Zurich

_______________________________________________
Hula-general mailing list
Hula-generalforge.novell.com
http://forge.novell.com/mailman/listinfo/hula-general

Alex Hudson wrote:

>On Thu, 2006-08-03 at 13:15 +0200, Stefan Walther wrote:
>  
>
>>The default of exim seems to make sense.
Unfortunately you can't set 
>>this on all mailers.
>>    
>>
>
>This is true, but in practise the default settings
shouldn't cause a
>problems with greylisting. Configuration of this is
actually a "must" in
>the SMTP spec., too.
>
>  
>
sender side or receiver side?
Sorry if this is obvious. Unfortunately I can't dedicate
much of my time 
to mailers since other stuff needs
more time. So I am not fluent in the SMTP spec. Perhaps I
will be after 
I setup my first spamassassin 

>>There are mailers which will bother the sending user
after the first 
>>temporary error. Are those mailers breaking specs? 
>>    
>>
>
>Well, 4.5.2 says vaguely:
>
>   Any queuing strategy MUST include timeouts on all
activities on a
>   per-command basis.  A queuing strategy MUST NOT send
error messages
>   in response to error messages under any
circumstances.
>
>I think that's actually talking about the SMTP
conversation rather than
>sending bounces, but the principle is pretty much there:
if you have a
>retry strategy, it's pretty poor show to generate
errors in what are
>considered "normal" (albeit unlikely)
conditions.
>  
>
>I would consider such a mailer broken, personally, and
don't know of any
>that have that behaviour - which software are you
thinking of?
>  
>
Symantec SMTP Gateway for example.

>As I said, I don't particularly like greylisting. But,
so long as the
>timeouts are relatively short (<30mn), they
shouldn't be noticeable to
>SMTP users (unless you run a really flakey SMTP service
anyway, at which
>point the anti-spam strategy of making your server
artificially even
>more unreliable comes back to bite you in the bum).
>
>Cheers,
>
>Alex.
>
>_______________________________________________
>Hula-general mailing list
>Hula-generalforge.novell.com
>http://forge.novell.com/mailman/listinfo/hula-general
>
>  
>

_______________________________________________
Hula-general mailing list
Hula-generalforge.novell.com
http://forge.novell.com/mailman/listinfo/hula-general

On Fri, 2006-08-04 at 07:54 +0200, Stefan Walther wrote:
> Alex Hudson wrote:
> >This is true, but in practise the default settings
shouldn't cause a
> >problems with greylisting. Configuration of this is
actually a "must" in
> >the SMTP spec., too.
>
> sender side or receiver side?

Sender side. Well, both, technically, but it would only
matter on the
sender side. 

> >I would consider such a mailer broken, personally,
and don't know of any
> >that have that behaviour - which software are you
thinking of?
>
> Symantec SMTP Gateway for example.

Ouch. Is that a server product, rather than a desktop
anti-virus or
something?

To be honest, I think free software SMTP systems tend to be
a lot closer
to the spec. than proprietary ones, certainly in terms of
off-the-shelf
software.

Cheers,

Alex.

_______________________________________________
Hula-general mailing list
Hula-generalforge.novell.com
http://forge.novell.com/mailman/listinfo/hula-general

Hi,

I would say we should end this discussion 

More important for me and I hope for you too,
is the development of Hula. My first interests
are in security and anti-spam solutions,
because that's what a mail system needs most.
I like dragonfly much, but to be honest,
it's more important to get the administration
interface back. That was on of the greate advantages
over postfix or sendmail.

Questions:

1. How can you integrate amavisd-new into Hula?

2. Is there a development of a new administration interface
or would it help, if I develop a new?

3. Will there be a certification for some linux
distribution,
because of security?

Bye
Sebastian

Am 04.08.2006 um 07:54 schrieb Stefan Walther:

> Alex Hudson wrote:
>
>> On Thu, 2006-08-03 at 13:15 +0200, Stefan Walther
wrote:
>>
>>> The default of exim seems to make sense.
Unfortunately you can't  
>>> set this on all mailers.
>>>
>>
>> This is true, but in practise the default settings
shouldn't cause a
>> problems with greylisting. Configuration of this is
actually a  
>> "must" in
>> the SMTP spec., too.
>>
>>
> sender side or receiver side?
> Sorry if this is obvious. Unfortunately I can't
dedicate much of my  
> time to mailers since other stuff needs
> more time. So I am not fluent in the SMTP spec. Perhaps
I will be  
> after I setup my first spamassassin 
>
>>> There are mailers which will bother the sending
user after the  
>>> first temporary error. Are those mailers
breaking specs?
>>
>> Well, 4.5.2 says vaguely:
>>
>>   Any queuing strategy MUST include timeouts on all
activities on a
>>   per-command basis.  A queuing strategy MUST NOT
send error messages
>>   in response to error messages under any
circumstances.
>>
>> I think that's actually talking about the SMTP
conversation rather  
>> than
>> sending bounces, but the principle is pretty much
there: if you  
>> have a
>> retry strategy, it's pretty poor show to generate
errors in what are
>> considered "normal" (albeit unlikely)
conditions.
>>
>> I would consider such a mailer broken, personally,
and don't know  
>> of any
>> that have that behaviour - which software are you
thinking of?
>>
> Symantec SMTP Gateway for example.
>
>> As I said, I don't particularly like greylisting.
But, so long as the
>> timeouts are relatively short (<30mn), they
shouldn't be  
>> noticeable to
>> SMTP users (unless you run a really flakey SMTP
service anyway, at  
>> which
>> point the anti-spam strategy of making your server
artificially even
>> more unreliable comes back to bite you in the bum).
>>
>> Cheers,
>>
>> Alex.
>>
>> _______________________________________________
>> Hula-general mailing list
>> Hula-generalforge.novell.com
>> http://forge.novell.com/mailman/listinfo/hula-general
>>
>>
>
> _______________________________________________
> Hula-general mailing list
> Hula-generalforge.novell.com
> http://forge.novell.com/mailman/listinfo/hula-general
>

_______________________________________________
Hula-general mailing list
Hula-generalforge.novell.com
http://forge.novell.com/mailman/listinfo/hula-general