FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora User

 
 
LinkBack Thread Tools
 
Old 03-28-2008, 03:43 AM
Craig White
 
Default **** **** HELP!!! mail attack

On Fri, 2008-03-28 at 12:45 +0900, John Summerfield wrote:
> Craig White wrote:
> >
>
> >
> > You are correct of course, that nowhere does it state that sender MUST attempt to re-deliver. I do wonder if you would find an SMTP server that by default didn't attempt re-delivery on temporary failures to be acceptable. It MUST be configurable - that's it.
>
>
> Okay, so Tim wasn't sure, but now we agree retrying, while it might be
> good practice isn't essential.
----
not essential in that the RFC does not say MUST

essential only if the intent was to surely deliver e-mail
----
>
> I've just done a "host -t mx" for several companies. Most have four mail
> exchangers, one had a dozen. While those are for incoming email, it's
> likely that they generally have a similar number for outgoing email.
> Without information, I assume that to be so. In many cases they will be
> the same machine.
>
> I don't know what their retrying policies are, but I can imagine that
> retrying might involve an attempt by each of several machines, each
> getting a 4XY response.
>
> It might be a lengthy delay, it might result in email getting returned
> to sender.
>
> Tim is right in his belief that greylisting can cause delivery problems.
> You don't have to think it's as big a problem as he does, but I don't
> criticise him for seeing it as a risk he doesn't want to take.
>
>
> Here is one list of recommended delays between retries:
> http://www.mailenable.com/Help/Files/smtpdelivery.htm
>
>
> The use of fake mx records suggested here looks enticing:
> http://wiki.apache.org/spamassassin/OtherTricks
>
> I discontinued using a second mx because it seemed only to receive spam,
> and senders _should_ retry if I'm not listening.
----
the 'fake mx records' suggests the use of Temp Fail codes on the highest
fake MX

*** sigh ***

I guess that if you think that NOT running greylisting means you get
delivery 100% of the time and running greylisting means that you only
get delivery 99.99% of the time (referring of course only to legitimate,
non-UBE e-mail) then you must be be indulging in willful sabotage and
not worthy of hire (Tim's words).

Temp Fail codes exist, are stipulated and understood by RFC and by ALL
SMTP servers.

The alternative is to run user level spam filtering. I submit that it is
for most businesses, a stupid, wasteful, inefficient plan but I
acknowledge that ISP servers cannot necessarily adopt these aggressive
tactics.

Craig

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 03-28-2008, 02:29 PM
Les
 
Default **** **** HELP!!! mail attack

On Thu, 2008-03-27 at 21:43 -0700, Craig White wrote:
> On Fri, 2008-03-28 at 12:45 +0900, John Summerfield wrote:
> > Craig White wrote:
> > >
> >
> > >
> > > You are correct of course, that nowhere does it state that sender MUST attempt to re-deliver. I do wonder if you would find an SMTP server that by default didn't attempt re-delivery on temporary failures to be acceptable. It MUST be configurable - that's it.
> >
> >
> > Okay, so Tim wasn't sure, but now we agree retrying, while it might be
> > good practice isn't essential.
> ----
> not essential in that the RFC does not say MUST
>
> essential only if the intent was to surely deliver e-mail
> ----
> >
> > I've just done a "host -t mx" for several companies. Most have four mail
> > exchangers, one had a dozen. While those are for incoming email, it's
> > likely that they generally have a similar number for outgoing email.
> > Without information, I assume that to be so. In many cases they will be
> > the same machine.
> >
> > I don't know what their retrying policies are, but I can imagine that
> > retrying might involve an attempt by each of several machines, each
> > getting a 4XY response.
> >
> > It might be a lengthy delay, it might result in email getting returned
> > to sender.
> >
> > Tim is right in his belief that greylisting can cause delivery problems.
> > You don't have to think it's as big a problem as he does, but I don't
> > criticise him for seeing it as a risk he doesn't want to take.
> >
> >
> > Here is one list of recommended delays between retries:
> > http://www.mailenable.com/Help/Files/smtpdelivery.htm
> >
> >
> > The use of fake mx records suggested here looks enticing:
> > http://wiki.apache.org/spamassassin/OtherTricks
> >
> > I discontinued using a second mx because it seemed only to receive spam,
> > and senders _should_ retry if I'm not listening.
> ----
> the 'fake mx records' suggests the use of Temp Fail codes on the highest
> fake MX
>
> *** sigh ***
>
> I guess that if you think that NOT running greylisting means you get
> delivery 100% of the time and running greylisting means that you only
> get delivery 99.99% of the time (referring of course only to legitimate,
> non-UBE e-mail) then you must be be indulging in willful sabotage and
> not worthy of hire (Tim's words).
>
> Temp Fail codes exist, are stipulated and understood by RFC and by ALL
> SMTP servers.
>
> The alternative is to run user level spam filtering. I submit that it is
> for most businesses, a stupid, wasteful, inefficient plan but I
> acknowledge that ISP servers cannot necessarily adopt these aggressive
> tactics.
>
> Craig
>
But is 99.99% delivery sufficient? I receive more than 150 emails per
day (ones that I am interested in), and every few days I need to receive
certain emails about customer relations and ongoing projects. 99.99
percent means I would miss one every 66 days. If the one that I miss
cost me a contract, it might not matter whether I received the rest or
not. Currently I have to parse through the junk mail locally and
remotely about once a week. the ISP junk folder often has more than
1200 emails in it. THe local one about 30. This adds about 1/2 day of
overhead every week to recapture what should have come through.
Personally I think the world needs to eliminate spam, or at least make
every effort to seriously reduce it.

Regards,
Les H

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 03-28-2008, 03:32 PM
"Patrick O'Callaghan"
 
Default **** **** HELP!!! mail attack

On Fri, 2008-03-28 at 08:29 -0700, Les wrote:
> On Thu, 2008-03-27 at 21:43 -0700, Craig White wrote:
> > On Fri, 2008-03-28 at 12:45 +0900, John Summerfield wrote:
> > > Craig White wrote:
> > > >
> > >
> > > >
> > > > You are correct of course, that nowhere does it state that sender MUST attempt to re-deliver. I do wonder if you would find an SMTP server that by default didn't attempt re-delivery on temporary failures to be acceptable. It MUST be configurable - that's it.
> > >
> > >
> > > Okay, so Tim wasn't sure, but now we agree retrying, while it might be
> > > good practice isn't essential.
> > ----
> > not essential in that the RFC does not say MUST
> >
> > essential only if the intent was to surely deliver e-mail
> > ----
> > >
> > > I've just done a "host -t mx" for several companies. Most have four mail
> > > exchangers, one had a dozen. While those are for incoming email, it's
> > > likely that they generally have a similar number for outgoing email.
> > > Without information, I assume that to be so. In many cases they will be
> > > the same machine.
> > >
> > > I don't know what their retrying policies are, but I can imagine that
> > > retrying might involve an attempt by each of several machines, each
> > > getting a 4XY response.
> > >
> > > It might be a lengthy delay, it might result in email getting returned
> > > to sender.
> > >
> > > Tim is right in his belief that greylisting can cause delivery problems.
> > > You don't have to think it's as big a problem as he does, but I don't
> > > criticise him for seeing it as a risk he doesn't want to take.
> > >
> > >
> > > Here is one list of recommended delays between retries:
> > > http://www.mailenable.com/Help/Files/smtpdelivery.htm
> > >
> > >
> > > The use of fake mx records suggested here looks enticing:
> > > http://wiki.apache.org/spamassassin/OtherTricks
> > >
> > > I discontinued using a second mx because it seemed only to receive spam,
> > > and senders _should_ retry if I'm not listening.
> > ----
> > the 'fake mx records' suggests the use of Temp Fail codes on the highest
> > fake MX
> >
> > *** sigh ***
> >
> > I guess that if you think that NOT running greylisting means you get
> > delivery 100% of the time and running greylisting means that you only
> > get delivery 99.99% of the time (referring of course only to legitimate,
> > non-UBE e-mail) then you must be be indulging in willful sabotage and
> > not worthy of hire (Tim's words).
> >
> > Temp Fail codes exist, are stipulated and understood by RFC and by ALL
> > SMTP servers.
> >
> > The alternative is to run user level spam filtering. I submit that it is
> > for most businesses, a stupid, wasteful, inefficient plan but I
> > acknowledge that ISP servers cannot necessarily adopt these aggressive
> > tactics.
> >
> > Craig
> >
> But is 99.99% delivery sufficient? I receive more than 150 emails per
> day (ones that I am interested in), and every few days I need to receive
> certain emails about customer relations and ongoing projects. 99.99
> percent means I would miss one every 66 days. If the one that I miss
> cost me a contract, it might not matter whether I received the rest or
> not.

That's up to you, but if your business model is based on email never
being lost then I suggest you need to rethink it. Email is a best-effort
service. It works reasonably well precisely because it's not designed to
be ultra-reliable.

An example: on our site, a university with about 20000 user accounts,
eliminating greylisting would mean the collapse of our mail server (this
isn't just a guess, it's based on real measurements) and consequent loss
of many more emails than we might lose to false positives.

There are no hard and fast rules here. You need to understand your
specific needs and situation and act accordingly.

poc

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 03-28-2008, 03:35 PM
Craig White
 
Default **** **** HELP!!! mail attack

On Fri, 2008-03-28 at 08:29 -0700, Les wrote:
> On Thu, 2008-03-27 at 21:43 -0700, Craig White wrote:
> > On Fri, 2008-03-28 at 12:45 +0900, John Summerfield wrote:
> > > Craig White wrote:
> > > >
> > >
> > > >
> > > > You are correct of course, that nowhere does it state that sender MUST attempt to re-deliver. I do wonder if you would find an SMTP server that by default didn't attempt re-delivery on temporary failures to be acceptable. It MUST be configurable - that's it.
> > >
> > >
> > > Okay, so Tim wasn't sure, but now we agree retrying, while it might be
> > > good practice isn't essential.
> > ----
> > not essential in that the RFC does not say MUST
> >
> > essential only if the intent was to surely deliver e-mail
> > ----
> > >
> > > I've just done a "host -t mx" for several companies. Most have four mail
> > > exchangers, one had a dozen. While those are for incoming email, it's
> > > likely that they generally have a similar number for outgoing email.
> > > Without information, I assume that to be so. In many cases they will be
> > > the same machine.
> > >
> > > I don't know what their retrying policies are, but I can imagine that
> > > retrying might involve an attempt by each of several machines, each
> > > getting a 4XY response.
> > >
> > > It might be a lengthy delay, it might result in email getting returned
> > > to sender.
> > >
> > > Tim is right in his belief that greylisting can cause delivery problems.
> > > You don't have to think it's as big a problem as he does, but I don't
> > > criticise him for seeing it as a risk he doesn't want to take.
> > >
> > >
> > > Here is one list of recommended delays between retries:
> > > http://www.mailenable.com/Help/Files/smtpdelivery.htm
> > >
> > >
> > > The use of fake mx records suggested here looks enticing:
> > > http://wiki.apache.org/spamassassin/OtherTricks
> > >
> > > I discontinued using a second mx because it seemed only to receive spam,
> > > and senders _should_ retry if I'm not listening.
> > ----
> > the 'fake mx records' suggests the use of Temp Fail codes on the highest
> > fake MX
> >
> > *** sigh ***
> >
> > I guess that if you think that NOT running greylisting means you get
> > delivery 100% of the time and running greylisting means that you only
> > get delivery 99.99% of the time (referring of course only to legitimate,
> > non-UBE e-mail) then you must be be indulging in willful sabotage and
> > not worthy of hire (Tim's words).
> >
> > Temp Fail codes exist, are stipulated and understood by RFC and by ALL
> > SMTP servers.
> >
> > The alternative is to run user level spam filtering. I submit that it is
> > for most businesses, a stupid, wasteful, inefficient plan but I
> > acknowledge that ISP servers cannot necessarily adopt these aggressive
> > tactics.
> >
> > Craig
> >
> But is 99.99% delivery sufficient? I receive more than 150 emails per
> day (ones that I am interested in), and every few days I need to receive
> certain emails about customer relations and ongoing projects. 99.99
> percent means I would miss one every 66 days. If the one that I miss
> cost me a contract, it might not matter whether I received the rest or
> not. Currently I have to parse through the junk mail locally and
> remotely about once a week. the ISP junk folder often has more than
> 1200 emails in it. THe local one about 30. This adds about 1/2 day of
> overhead every week to recapture what should have come through.
> Personally I think the world needs to eliminate spam, or at least make
> every effort to seriously reduce it.
----
but your example completely misses the point.

the 'Junk' directory is a result of some type of agent parsing accepted
e-mail, scoring it and redirecting it based on a score.

The point of greylisting is always about (or virtually always...depends
upon various implementations anyway) sender/recipient/smtp server
'tuples' and 'Temporary Failure' /SMTP result codes 450 and whether the
sender attempts redelivery.

http://www.greylisting.org/

I would suggest that rather than prove the argument about the problems
with greylisting, you have proven the opposite because if you can lop
approximately 70% of that junk mail off the top via greylisting, you
wouldn't have to look through so much 'junk' to find the false positives
that inevitably occur with any type of spam scoring system.

Craig

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 03-28-2008, 03:37 PM
Craig White
 
Default **** **** HELP!!! mail attack

On Fri, 2008-03-28 at 12:02 -0430, Patrick O'Callaghan wrote:
> On Fri, 2008-03-28 at 08:29 -0700, Les wrote:
> > On Thu, 2008-03-27 at 21:43 -0700, Craig White wrote:
> > > On Fri, 2008-03-28 at 12:45 +0900, John Summerfield wrote:
> > > > Craig White wrote:
> > > > >
> > > >
> > > > >
> > > > > You are correct of course, that nowhere does it state that sender MUST attempt to re-deliver. I do wonder if you would find an SMTP server that by default didn't attempt re-delivery on temporary failures to be acceptable. It MUST be configurable - that's it.
> > > >
> > > >
> > > > Okay, so Tim wasn't sure, but now we agree retrying, while it might be
> > > > good practice isn't essential.
> > > ----
> > > not essential in that the RFC does not say MUST
> > >
> > > essential only if the intent was to surely deliver e-mail
> > > ----
> > > >
> > > > I've just done a "host -t mx" for several companies. Most have four mail
> > > > exchangers, one had a dozen. While those are for incoming email, it's
> > > > likely that they generally have a similar number for outgoing email.
> > > > Without information, I assume that to be so. In many cases they will be
> > > > the same machine.
> > > >
> > > > I don't know what their retrying policies are, but I can imagine that
> > > > retrying might involve an attempt by each of several machines, each
> > > > getting a 4XY response.
> > > >
> > > > It might be a lengthy delay, it might result in email getting returned
> > > > to sender.
> > > >
> > > > Tim is right in his belief that greylisting can cause delivery problems.
> > > > You don't have to think it's as big a problem as he does, but I don't
> > > > criticise him for seeing it as a risk he doesn't want to take.
> > > >
> > > >
> > > > Here is one list of recommended delays between retries:
> > > > http://www.mailenable.com/Help/Files/smtpdelivery.htm
> > > >
> > > >
> > > > The use of fake mx records suggested here looks enticing:
> > > > http://wiki.apache.org/spamassassin/OtherTricks
> > > >
> > > > I discontinued using a second mx because it seemed only to receive spam,
> > > > and senders _should_ retry if I'm not listening.
> > > ----
> > > the 'fake mx records' suggests the use of Temp Fail codes on the highest
> > > fake MX
> > >
> > > *** sigh ***
> > >
> > > I guess that if you think that NOT running greylisting means you get
> > > delivery 100% of the time and running greylisting means that you only
> > > get delivery 99.99% of the time (referring of course only to legitimate,
> > > non-UBE e-mail) then you must be be indulging in willful sabotage and
> > > not worthy of hire (Tim's words).
> > >
> > > Temp Fail codes exist, are stipulated and understood by RFC and by ALL
> > > SMTP servers.
> > >
> > > The alternative is to run user level spam filtering. I submit that it is
> > > for most businesses, a stupid, wasteful, inefficient plan but I
> > > acknowledge that ISP servers cannot necessarily adopt these aggressive
> > > tactics.
> > >
> > > Craig
> > >
> > But is 99.99% delivery sufficient? I receive more than 150 emails per
> > day (ones that I am interested in), and every few days I need to receive
> > certain emails about customer relations and ongoing projects. 99.99
> > percent means I would miss one every 66 days. If the one that I miss
> > cost me a contract, it might not matter whether I received the rest or
> > not.
>
> That's up to you, but if your business model is based on email never
> being lost then I suggest you need to rethink it. Email is a best-effort
> service. It works reasonably well precisely because it's not designed to
> be ultra-reliable.
>
> An example: on our site, a university with about 20000 user accounts,
> eliminating greylisting would mean the collapse of our mail server (this
> isn't just a guess, it's based on real measurements) and consequent loss
> of many more emails than we might lose to false positives.
>
> There are no hard and fast rules here. You need to understand your
> specific needs and situation and act accordingly.
----
Oh oh...Tim thinks you are sabotaging your mail system by implementing
greylisting and he would never hire you either.

Craig

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 03-28-2008, 05:06 PM
Craig White
 
Default **** **** HELP!!! mail attack

On Fri, 2008-03-28 at 10:17 -0700, Les wrote:
> On Fri, 2008-03-28 at 09:35 -0700, Craig White wrote:
> > On Fri, 2008-03-28 at 08:29 -0700, Les wrote:

> > > >
> > > But is 99.99% delivery sufficient? I receive more than 150 emails per
> > > day (ones that I am interested in), and every few days I need to receive
> > > certain emails about customer relations and ongoing projects. 99.99
> > > percent means I would miss one every 66 days. If the one that I miss
> > > cost me a contract, it might not matter whether I received the rest or
> > > not. Currently I have to parse through the junk mail locally and
> > > remotely about once a week. the ISP junk folder often has more than
> > > 1200 emails in it. THe local one about 30. This adds about 1/2 day of
> > > overhead every week to recapture what should have come through.
> > > Personally I think the world needs to eliminate spam, or at least make
> > > every effort to seriously reduce it.
> > ----
> > but your example completely misses the point.
> >
> > the 'Junk' directory is a result of some type of agent parsing accepted
> > e-mail, scoring it and redirecting it based on a score.
> >
> > The point of greylisting is always about (or virtually always...depends
> > upon various implementations anyway) sender/recipient/smtp server
> > 'tuples' and 'Temporary Failure' /SMTP result codes 450 and whether the
> > sender attempts redelivery.
> >
> > http://www.greylisting.org/
> >
> > I would suggest that rather than prove the argument about the problems
> > with greylisting, you have proven the opposite because if you can lop
> > approximately 70% of that junk mail off the top via greylisting, you
> > wouldn't have to look through so much 'junk' to find the false positives
> > that inevitably occur with any type of spam scoring system.
> >
> > Craig
>
> I cannot argue the value of greylisting. But efficiency is in the eye
> of the beholder. My time is limited. My work valuable, and my customer
> correspondence is dictated by my customer, not my email policy. I am at
> the mercy of the ISP here, and the customer. Yet I am the one who
> suffers loss, not the ISP, not the customer who will find someone to do
> his work. Yet you as the web person thinks this is effective. I cannot
> speak to school systems, only professional uses. Time is money and lost
> opportunity is even more valuable, resulting in loss that cannot be
> measured, yet ultimately may determine the success or failure of my
> business.
>
> I would like to take this thought "out of the box". The methods
> currently in place, grey listing, parsing for key words, and other
> simplistic means, while effective at reducing traffic are not really the
> desired solution by users, who would like 100% success in getting their
> desired email. And while I cannot spout statistics about loss, I know
> it happens from personal experience. The question at hand is how to
> avoid even more loss. It is a quality issue, and today the quality
> standard is not 99.99%, it is 99.9999% (six nines or six sigma) in most
> industries. To say that 99.99 is good enough is the path for GM and
> Ford, not Toyota and Nissan. Think of it that way. So how do we
> improve by two decades of quality in this "war" against spam?
----
greylisting is just one of a lot of tools available to the mail server
administrator - all of them are calibrated to minimize the junk mail
delivered to the end users and of course minimizing delivery failures
and false positive scoring by various mechanisms.

End users of course are the ones ultimately affected and you seemingly
want to open an end user discussion about a server level
technology...please don't as it won't provide clarity to anyone.

If you are losing e-mails, evaluate the filtering system that you use at
end user level and discuss the methodologies employed by your mail
provider with them.

Craig

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 03-28-2008, 10:00 PM
Da Rock
 
Default **** **** HELP!!! mail attack

On Fri, 2008-03-28 at 08:29 -0700, Les wrote:
> On Thu, 2008-03-27 at 21:43 -0700, Craig White wrote:
> > On Fri, 2008-03-28 at 12:45 +0900, John Summerfield wrote:
> > > Craig White wrote:
> > > >
> > >
> > > >
> > > > You are correct of course, that nowhere does it state that sender MUST attempt to re-deliver. I do wonder if you would find an SMTP server that by default didn't attempt re-delivery on temporary failures to be acceptable. It MUST be configurable - that's it.
> > >
> > >
> > > Okay, so Tim wasn't sure, but now we agree retrying, while it might be
> > > good practice isn't essential.
> > ----
> > not essential in that the RFC does not say MUST
> >
> > essential only if the intent was to surely deliver e-mail
> > ----
> > >
> > > I've just done a "host -t mx" for several companies. Most have four mail
> > > exchangers, one had a dozen. While those are for incoming email, it's
> > > likely that they generally have a similar number for outgoing email.
> > > Without information, I assume that to be so. In many cases they will be
> > > the same machine.
> > >
> > > I don't know what their retrying policies are, but I can imagine that
> > > retrying might involve an attempt by each of several machines, each
> > > getting a 4XY response.
> > >
> > > It might be a lengthy delay, it might result in email getting returned
> > > to sender.
> > >
> > > Tim is right in his belief that greylisting can cause delivery problems.
> > > You don't have to think it's as big a problem as he does, but I don't
> > > criticise him for seeing it as a risk he doesn't want to take.
> > >
> > >
> > > Here is one list of recommended delays between retries:
> > > http://www.mailenable.com/Help/Files/smtpdelivery.htm
> > >
> > >
> > > The use of fake mx records suggested here looks enticing:
> > > http://wiki.apache.org/spamassassin/OtherTricks
> > >
> > > I discontinued using a second mx because it seemed only to receive spam,
> > > and senders _should_ retry if I'm not listening.
> > ----
> > the 'fake mx records' suggests the use of Temp Fail codes on the highest
> > fake MX
> >
> > *** sigh ***
> >
> > I guess that if you think that NOT running greylisting means you get
> > delivery 100% of the time and running greylisting means that you only
> > get delivery 99.99% of the time (referring of course only to legitimate,
> > non-UBE e-mail) then you must be be indulging in willful sabotage and
> > not worthy of hire (Tim's words).
> >
> > Temp Fail codes exist, are stipulated and understood by RFC and by ALL
> > SMTP servers.
> >
> > The alternative is to run user level spam filtering. I submit that it is
> > for most businesses, a stupid, wasteful, inefficient plan but I
> > acknowledge that ISP servers cannot necessarily adopt these aggressive
> > tactics.
> >
> > Craig
> >
> But is 99.99% delivery sufficient? I receive more than 150 emails per
> day (ones that I am interested in), and every few days I need to receive
> certain emails about customer relations and ongoing projects. 99.99
> percent means I would miss one every 66 days. If the one that I miss
> cost me a contract, it might not matter whether I received the rest or
> not. Currently I have to parse through the junk mail locally and
> remotely about once a week. the ISP junk folder often has more than
> 1200 emails in it. THe local one about 30. This adds about 1/2 day of
> overhead every week to recapture what should have come through.
> Personally I think the world needs to eliminate spam, or at least make
> every effort to seriously reduce it.
>
> Regards,
> Les H
>

Maybe we should send them all an email asking them nicely to stop?

I understand your concern with the loss of important emails, but
consider this: Do you send and recieve faxes? If a fax cannot connect
with the recipient, it queues the call and tries again in a random time.

This is what happens with email. The server tries and if it can't
connect because of a specific error sent back, it'll queue the email and
try again later. Meanwhile, spam only gets attempted once and is
rejected.

So all your important emails WILL get through, because the service is
legitimate. Having seen this in my work in an ISP, as well as knowing
telecommunications technologies, lets me know that this does work. And
once your clients have sent you an email they get whitelisted, plus you
can add them manually as well. There are probably other methods as well
to filter clients through.

If you're concerned with efficiency, and valuable time, etc, then
something which is going to save you time IS going to save you money. If
you want better than 99.99% efficiency (with 6x 9s) then fiddle with
this technology to make it work better- filters are NOT going to be your
answer, just waste your time.

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 03-30-2008, 09:48 AM
Tim
 
Default **** **** HELP!!! mail attack

On Sat, 2008-03-29 at 09:00 +1000, Da Rock wrote:
> I understand your concern with the loss of important emails, but
> consider this: Do you send and recieve faxes? If a fax cannot connect
> with the recipient, it queues the call and tries again in a random
> time.

If the sending fax is set up to do so... It's by no means a certainty,
and analogies aren't a great way to argue a case about something else
that's specific.

> This is what happens with email. The server tries and if it can't
> connect because of a specific error sent back, it'll queue the email
> and try again later.

No, "should" happen, not "does" happen.

> Meanwhile, spam only gets attempted once and is rejected.

Perhaps, but that's by no means a given. Spammers can resend, if they
want to. They can, and usually do, exploit someone elses server, which
may resend.

> So all your important emails WILL get through, because the service is
> legitimate.

*May* get through.

> Having seen this in my work in an ISP, as well as knowing
> telecommunications technologies, lets me know that this does work.

Having seen the system fail to work in the manner some people believe it
works, I know that it's a false belief.

> And once your clients have sent you an email they get whitelisted,
> plus you can add them manually as well.

a. I've certainly seen cases where it's very obvious that you don't get
whitelisted. i.e. Weeks and weeks of messages that don't get through.

b. Most people will not be able to add things, because they make use of
someone else's server, that they can't configure. i.e. The senders and
recipients ISPs'.

--
(This computer runs FC7, my others run FC4, FC5 & FC6, in case that's
important to the thread.)

Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 04-11-2008, 11:16 PM
Les
 
Default **** **** HELP!!! mail attack

On Fri, 2008-03-28 at 11:06 -0700, Craig White wrote:
> On Fri, 2008-03-28 at 10:17 -0700, Les wrote:
> > On Fri, 2008-03-28 at 09:35 -0700, Craig White wrote:
> > > On Fri, 2008-03-28 at 08:29 -0700, Les wrote:
>
> > > > >
> > > > But is 99.99% delivery sufficient? I receive more than 150 emails per
> > > > day (ones that I am interested in), and every few days I need to receive
> > > > certain emails about customer relations and ongoing projects. 99.99
> > > > percent means I would miss one every 66 days. If the one that I miss
> > > > cost me a contract, it might not matter whether I received the rest or
> > > > not. Currently I have to parse through the junk mail locally and
> > > > remotely about once a week. the ISP junk folder often has more than
> > > > 1200 emails in it. THe local one about 30. This adds about 1/2 day of
> > > > overhead every week to recapture what should have come through.
> > > > Personally I think the world needs to eliminate spam, or at least make
> > > > every effort to seriously reduce it.
> > > ----
> > > but your example completely misses the point.
> > >
> > > the 'Junk' directory is a result of some type of agent parsing accepted
> > > e-mail, scoring it and redirecting it based on a score.
> > >
> > > The point of greylisting is always about (or virtually always...depends
> > > upon various implementations anyway) sender/recipient/smtp server
> > > 'tuples' and 'Temporary Failure' /SMTP result codes 450 and whether the
> > > sender attempts redelivery.
> > >
> > > http://www.greylisting.org/
> > >
> > > I would suggest that rather than prove the argument about the problems
> > > with greylisting, you have proven the opposite because if you can lop
> > > approximately 70% of that junk mail off the top via greylisting, you
> > > wouldn't have to look through so much 'junk' to find the false positives
> > > that inevitably occur with any type of spam scoring system.
> > >
> > > Craig
> >
> > I cannot argue the value of greylisting. But efficiency is in the eye
> > of the beholder. My time is limited. My work valuable, and my customer
> > correspondence is dictated by my customer, not my email policy. I am at
> > the mercy of the ISP here, and the customer. Yet I am the one who
> > suffers loss, not the ISP, not the customer who will find someone to do
> > his work. Yet you as the web person thinks this is effective. I cannot
> > speak to school systems, only professional uses. Time is money and lost
> > opportunity is even more valuable, resulting in loss that cannot be
> > measured, yet ultimately may determine the success or failure of my
> > business.
> >
> > I would like to take this thought "out of the box". The methods
> > currently in place, grey listing, parsing for key words, and other
> > simplistic means, while effective at reducing traffic are not really the
> > desired solution by users, who would like 100% success in getting their
> > desired email. And while I cannot spout statistics about loss, I know
> > it happens from personal experience. The question at hand is how to
> > avoid even more loss. It is a quality issue, and today the quality
> > standard is not 99.99%, it is 99.9999% (six nines or six sigma) in most
> > industries. To say that 99.99 is good enough is the path for GM and
> > Ford, not Toyota and Nissan. Think of it that way. So how do we
> > improve by two decades of quality in this "war" against spam?
> ----
> greylisting is just one of a lot of tools available to the mail server
> administrator - all of them are calibrated to minimize the junk mail
> delivered to the end users and of course minimizing delivery failures
> and false positive scoring by various mechanisms.
>
> End users of course are the ones ultimately affected and you seemingly
> want to open an end user discussion about a server level
> technology...please don't as it won't provide clarity to anyone.
>
> If you are losing e-mails, evaluate the filtering system that you use at
> end user level and discuss the methodologies employed by your mail
> provider with them.
>
This is the same sort of nonsense that the carmakers spouted about
quality in the 70's. See where it got them.
This is an end user product. Clarity is the way the user sees it, not
the way the provider sees it.

I know there is no sense arguing this, I have dealt with engineers and
quality issues for years. The only way that attention comes is when
someone provides the user with higher quality and the engineer is
provided with a pink slip when his job goes away.

It is coming. Wait for it... wait for it....

regards,
Les H

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 04-12-2008, 02:58 AM
Craig White
 
Default **** **** HELP!!! mail attack

On Fri, 2008-04-11 at 16:16 -0700, Les wrote:
> On Fri, 2008-03-28 at 11:06 -0700, Craig White wrote:
> > On Fri, 2008-03-28 at 10:17 -0700, Les wrote:
> > > On Fri, 2008-03-28 at 09:35 -0700, Craig White wrote:
> > > > On Fri, 2008-03-28 at 08:29 -0700, Les wrote:
> >
> > > > > >
> > > > > But is 99.99% delivery sufficient? I receive more than 150 emails per
> > > > > day (ones that I am interested in), and every few days I need to receive
> > > > > certain emails about customer relations and ongoing projects. 99.99
> > > > > percent means I would miss one every 66 days. If the one that I miss
> > > > > cost me a contract, it might not matter whether I received the rest or
> > > > > not. Currently I have to parse through the junk mail locally and
> > > > > remotely about once a week. the ISP junk folder often has more than
> > > > > 1200 emails in it. THe local one about 30. This adds about 1/2 day of
> > > > > overhead every week to recapture what should have come through.
> > > > > Personally I think the world needs to eliminate spam, or at least make
> > > > > every effort to seriously reduce it.
> > > > ----
> > > > but your example completely misses the point.
> > > >
> > > > the 'Junk' directory is a result of some type of agent parsing accepted
> > > > e-mail, scoring it and redirecting it based on a score.
> > > >
> > > > The point of greylisting is always about (or virtually always...depends
> > > > upon various implementations anyway) sender/recipient/smtp server
> > > > 'tuples' and 'Temporary Failure' /SMTP result codes 450 and whether the
> > > > sender attempts redelivery.
> > > >
> > > > http://www.greylisting.org/
> > > >
> > > > I would suggest that rather than prove the argument about the problems
> > > > with greylisting, you have proven the opposite because if you can lop
> > > > approximately 70% of that junk mail off the top via greylisting, you
> > > > wouldn't have to look through so much 'junk' to find the false positives
> > > > that inevitably occur with any type of spam scoring system.
> > > >
> > > > Craig
> > >
> > > I cannot argue the value of greylisting. But efficiency is in the eye
> > > of the beholder. My time is limited. My work valuable, and my customer
> > > correspondence is dictated by my customer, not my email policy. I am at
> > > the mercy of the ISP here, and the customer. Yet I am the one who
> > > suffers loss, not the ISP, not the customer who will find someone to do
> > > his work. Yet you as the web person thinks this is effective. I cannot
> > > speak to school systems, only professional uses. Time is money and lost
> > > opportunity is even more valuable, resulting in loss that cannot be
> > > measured, yet ultimately may determine the success or failure of my
> > > business.
> > >
> > > I would like to take this thought "out of the box". The methods
> > > currently in place, grey listing, parsing for key words, and other
> > > simplistic means, while effective at reducing traffic are not really the
> > > desired solution by users, who would like 100% success in getting their
> > > desired email. And while I cannot spout statistics about loss, I know
> > > it happens from personal experience. The question at hand is how to
> > > avoid even more loss. It is a quality issue, and today the quality
> > > standard is not 99.99%, it is 99.9999% (six nines or six sigma) in most
> > > industries. To say that 99.99 is good enough is the path for GM and
> > > Ford, not Toyota and Nissan. Think of it that way. So how do we
> > > improve by two decades of quality in this "war" against spam?
> > ----
> > greylisting is just one of a lot of tools available to the mail server
> > administrator - all of them are calibrated to minimize the junk mail
> > delivered to the end users and of course minimizing delivery failures
> > and false positive scoring by various mechanisms.
> >
> > End users of course are the ones ultimately affected and you seemingly
> > want to open an end user discussion about a server level
> > technology...please don't as it won't provide clarity to anyone.
> >
> > If you are losing e-mails, evaluate the filtering system that you use at
> > end user level and discuss the methodologies employed by your mail
> > provider with them.
> >
> This is the same sort of nonsense that the carmakers spouted about
> quality in the 70's. See where it got them.
> This is an end user product. Clarity is the way the user sees it, not
> the way the provider sees it.
>
> I know there is no sense arguing this, I have dealt with engineers and
> quality issues for years. The only way that attention comes is when
> someone provides the user with higher quality and the engineer is
> provided with a pink slip when his job goes away.
>
> It is coming. Wait for it... wait for it....
----
aside from your resurrecting a discussion that is 2 weeks old and
completely cold...

aside from your continued insistence to inject user level concerns on a
topic that was completely about SMTP/MTA administration...

aside from the fact that you have now tried to render a technical
discussion on strategic mail handling to a metaphor that has no
relevance...

I'd say you have contributed nothing to the discourse at all.

I will repeat...you are in control over your own e-mail.

If you don't like how your e-mail provider handles your e-mail, you can
change providers.

My comments on this topic were directly solely to a system administrator
handling a mail account that was job jobbed. How did this concern you? I
still have no idea.

Craig

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 

Thread Tools




All times are GMT. The time now is 07:23 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org