[lug] Meeting tonight?

[Daniel Webb]

On Sat, Dec 16, 2006 at 10:28:56AM -0700, Chris Riddoch wrote:

> On the other hand, the Cc: to the announce list I sent (obviously at
> the same time) didn't get past the greylisting for another six hours.
> By the time I was able to approve or cancel the post, it certainly
> wouldn't have been of much use to anyone, so I canceled it.
> 
> Perhaps gmail doesn't always play nice with greylisting.  Or something.


I guess that's the risk with greylisting, since (to my knowledge) the RFCs
don't specify that a sender must reply or what that retry schedule should be.
Greylisting people often assert this: 

-----------
http://email.calpoly.edu/spam/GreylistingAnnouncement.html

"Every Request for Comment (RFC) 821- compliant email server is designed to
retry sending mail when an email server is unavailable. The retry time depends
on the sending email server's software, administrator settings, and other
network-related issues. Most servers retry within 30 minutes. However, there
are sites that do not retry-they are running a non-RFC compliant email
server-and some sites that take up to 24 hours to retry."
-----------

but the primary RFC for email reference in the above does not even include the
word "retry" in the document.  The relevant part seems to be:

-----------
4yz   Transient Negative Completion reply

               The command was not accepted and the requested action did
               not occur.  However, the error condition is temporary and
               the action may be requested again.  The sender should
               return to the beginning of the command sequence (if any).
               It is difficult to assign a meaning to "transient" when
               two different sites (receiver- and sender- SMTPs) must
               agree on the interpretation.  Each reply in this category
               might have a different time value, but the sender-SMTP is
               encouraged to try again.  A rule of thumb to determine if
               a reply fits into the 4yz or the 5yz category (see below)
               is that replies are 4yz if they can be repeated without
               any change in command form or in properties of the sender
               or receiver.  (E.g., the command is repeated identically
               and the receiver does not put up a new implementation.)
-----------

If I had written that, I would have been more specific, but it's already a big
document and it's hard to think of everything.  I do use greylisting; although
its effectiveness seems to be decreasing it still works.  Whether or not it's
specified in the RFCs, not retrying on a 4xx code is idiotic (Yahoo groups,
are you listening?)