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, 02:02 AM
Craig White
 
Default **** HELP!!! mail attack

On Fri, 2008-03-28 at 11:15 +0900, John Summerfield wrote:
> Craig White wrote:
>
> > You're 'not sure that a server really *has* to resend' ?
>
> You are implying it must. What text of rfc 2821 does it violate ifit
> doesn't?
----
A temporary fail code of 450 occurs at the RCPT stage as you know and
there is no way that the sending server can mistake this to be a
successful delivery.

A permanent fail code like 55X renders redelivery pointless and the
original sender should be notified.

As for handling re-delivery, this section covers it...

4.5.4.1 Sending Strategy

The general model for an SMTP client is one or more processes that
periodically attempt to transmit outgoing mail. In a typical system,
the program that composes a message has some method for requesting
immediate attention for a new piece of outgoing mail, while mail that
cannot be transmitted immediately MUST be queued and periodically
retried by the sender. A mail queue entry will include not only the
message itself but also the envelope information.

The sender MUST delay retrying a particular destination after one
attempt has failed. In general, the retry interval SHOULD be at
least 30 minutes; however, more sophisticated and variable strategies
will be beneficial when the SMTP client can determine the reason for
non-delivery.

Retries continue until the message is transmitted or the sender gives
up; the give-up time generally needs to be at least 4-5 days. The
parameters to the retry algorithm MUST be configurable.

As to the notions of 'has to' or 'violated' sections...there is only that which is reasonable and prudent and by all custom (and the language above), it's obvious that re-delivery is expected, customary, and standard practice for all SMTP servers I have dealt with.

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.

Craig

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

On Fri, 2008-03-28 at 11:19 +0900, John Summerfield wrote:
> Craig White wrote:
>
> >
> > Alternative theory here...you suffer from an over inflated value of your
> > own opinions...nothing new there.
> >
> > Craig
> >
>
> Take a look in the mirror, Craig. I think you're being unnecessarily
> unpleasant.
>
> I don't always agree with Tim, and a while back we had a fairly long
> disagreement, but I favour the conservative approach.
----
ignoring that it was response to this...

> It's clear that you're one of those admins who doesn't see a problem
> with throwing out the real mail, so long as you get rid of all the
spam
> at the same time. I wouldn't hire anyone with that attitude, it's
> wilful sabotage.

your assessment makes sense. I'm quite certain that my customers don't
feel 'sabotaged' and I won't be seeking a job with him any time soon but
the notion that he wouldn't hire me is beyond arrogance.

I recognize that there are many different theories on running mail
servers and those that are ISP's and handle e-mail for various customers
are in a much different position than those that handle e-mail for a
specific business.

The problem with Tim is that he doesn't see anyone else's point of
view...ever. He doesn't even bother with the notion of trying.

I can assure you that for small-medium company, they are far better off
with an aggressive, server based handling system so that each user
doesn't have to deal with their own Junk mail filters - less phone calls
for support because they can't find e-mails diverted to their Junk
folder, slow computer response while retrieving e-mail and scanning
content, etc. End user mail filtering is a complete waste of time,
energy and computing power. That of course is not the Tim point of view.

Craig

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

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.



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.




--

Cheers
John

-- spambait
1aaaaaaa@coco.merseine.nu Z1aaaaaaa@coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)

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

On Thu, 2008-03-27 at 20:21 -0700, Craig White wrote:
> The problem with Tim is that he doesn't see anyone else's point of
> view...ever. He doesn't even bother with the notion of trying.

Pot, kettle, black...
--
(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 03-30-2008, 01:14 PM
Craig White
 
Default **** HELP!!! mail attack

On Sun, 2008-03-30 at 20:17 +1030, Tim wrote:

> > Alternative theory here...you suffer from an over inflated value of
> > your own opinions...nothing new there.
>
> Pot, kettle, black. You're the one promulgating an "opinion" (that
> greylisting is brilliant), I'm the one bringing up a "fact" that it
> causes problems.
----
nice of you to crawl out from behind a rock and resurrect the 3 day old
thread.

since this is more generally a users list and less a system
administrators list, I'll let this pass except to say that there are
various strategies/theories and you and I differ on e-mail handling
strategies. I am very comfortable with that.

Craig

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

On Sun, 2008-03-30 at 08:49 -0430, Patrick O'Callaghan wrote:
> On Sun, 2008-03-30 at 20:16 +1030, Tim wrote:
> > Anyone who argues that email shouldn't be a reliable mechanism is
> > skirting the issue. It should be. There's no excuse it not to be.
>
> AFAIK no-one is arguing that it *shouldn't* be (in the sense that in
> some ideal alternate universe we wouldn't want it to be), but that it
> *isn't*.
>
> And to say "there's no excuse for it not to be" is either a misstatement
> of what you mean or evidence of a jaw-dropping misunderstanding of how
> the Internet works. As I can't believe you really mean the latter, I
> guess it must be the former. Or maybe we have different conceptions of
> what "reliable" means.
>
> As I pointed out in an earlier message, there are situations in which
> not using greylisting leads to a measurably less reliable mail service.
> Not all situations, maybe not your situation, but I know they exist
> because I've seen them.
----
Since Tim has already stated that this technology (greylisting) is
intentional sabotage and he would never hire someone who would implement
the technology, there is no way that he will agree with you.

Considering that there are multiple greylisting mechanisms for each smtp
package and there are a large amount of implementations of greylisting,
there clearly are a lot of system administrators that concur that the
technology is worthwhile if not essential.

Tim is utterly incapable of seeing someone else's point of view, clearly
on this issue and I would submit, this is not a unique observation.

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 01:38 PM.

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