Talk:Greylisting (email)

Why triplets?

Article doesn't mention why triplets are needed. Really, greylisting only weeds out servers that aren't running RFC-compliant mail servers. Therefore, the IP address would be the most important factor to store in a DB. Once the server A has proven that it is capable of resending greylisted email from user1 to user10 on server B, why continue punishing it when user2 wants to send mail through server A to user11 on serverB? —Preceding unsigned comment added by 99.190.134.148 (talk) 05:35, 12 March 2010 (UTC)[reply]

I added to the paragraph describing the process and explained why the triplet is necessary. My examples timings come from OpenBSD's spamd. This is the greylister implemented as part of the OpenBSD firewall: pf.--Ecksii (talk) 16:42, 13 July 2012 (UTC)[reply]

Defition of triplets

The article mentions storing triplets but doesn't say what this data is used for. Could someone add this? Nate 19:25, 12 Jan 2005 (UTC)

It was added since. -79.180.25.233 (talk) 13:00, 2 September 2009 (UTC)[reply]

North American spelling

The article says "the word is spelled 'graylisting' in North America", but I'm not sure this is true. Most of the U.S. sources I've seen use "greylisting", as the article does. Google reports 234,000 hits for "greylisting" vs. 9,340 for "graylisting" -- compare this to 56 million for "grey" vs. 114 million for "gray".

Do we have a source for the "North American spelling" claim? If not, I'd like to remove it.

--67.188.121.29 09:37, 29 September 2005 (UTC)[reply]

I concur, I'm active on several mailing lists frequented by Americans and have never seen it called "graylisting" (except maybe by novice admins who don't know any better). Zerbey 17:56, 14 November 2005 (UTC)[reply]

A few suggestions...

The comments about losing legitimate mail should really be changed to stress how rare losing legitimate mail is and how it is incorrect (according to the RFCs) for a mailer to fail to retry. I'm afraid some people may be scared off from trying this wonderful anti-spam technique for fear of losing mail, when losing legitimate mail really should not be a concern.

To respond to the earlier comment, the triplet stored is used to make the decision to allow the mail when the retry happens.

In response to the "arms race" disadvantage, there are others who would argue that spammer tools changing to circumvent greylisting is unlikely for several reasons. One is that spam tools have to frequently change the addresses used in their mails to avoid more basic blocking. The other is that spammers deal with such a high volume of mail, retrying messages isn't feasible.

In the Advantages section, it may be be wise to emphasize that the delay only applies the first time a new sender appears. Some greylist software times out entries after a specified period of time, to keep the database size from growing too large, so for example of if the timeout is set to 1 week and you have mail that regularly arrives once a month, it will be delayed every time. In that case, the delay shouldn't be too important. Local customization and white-listing is common.

As far as spelling, at least on implementation is called "Graymilter".

24.163.80.4 23:07, 22 January 2006 (UTC) Steve[reply]

While you are absolutely correct in saying that "losing legitimate mail should not be a concern", the fact is that it is a concern and does happen. I ran greylisting for many months and became frustrated when a discovered I was losing legitimate mail. One case I remember was mail from a web site with home-grown order form software that did not follow standards. It never retried; I never got my mail. Another case was a web site where signup involved sending a confirmation code via email with instructions to click on the included link within five minutes. I had to make a specific exception to receive that mail within the time alloted. Users without control over their site's greylisting filter would have had much more difficulty. --Ghewgill 01:05, 23 January 2006 (UTC)[reply]

hhhobbit (talk) 14:46, 30 August 2012 (UTC)[reply]

I don't understand. —Preceding unsigned comment added by 65.27.132.51 (talk • contribs) 23:13, 12 April 2007

It should be noted greylisting is incompatible with sender verification which is standard on many mailservers now. A greylisted server will not be able to send mail to any recipient that has sender verification enabled. The sender verification will send a 450 response (as the sending server has refused to verify that it is a legitimate address) and the many (most? all?) greylisting systems just drop that response on the floor and never try again. 146.87.6.75 —Preceding comment was added at 14:18, 23 October 2007 (UTC)[reply]

The whole subject has been altered by a bot-net of compromised Windows PCs that have custom crafted email SMTP engineered for spamming that is being used to attack my securemecca.com domain. It started with me getting just the bounces:

http://securemecca.com/public/PeskySpammer/Bounces.jpg

and now they are doing hash-name-from send to hash-name-to (I am the postmaster for the domain):

http://securemecca.com/public/PeskySpammer/DirectSends.jpg

I will be writing a blog entry on the subject that will be entitled "Vote Against Spam" that shows that Greylisting was a technigue that may have been suitable when what we had to worry about were open SMTP relays running primarily on Linux. I have never heard of Microsoft Exchange being in that fray since Microsoft sends Microsoft Exchange out the door buttoned down. The PCs that I am talking about never had Microsoft Exchange on them. What I am talking about is special purpose, custom crafted email sending software that is dropped on compromised machines running Microsoft Windows. It is not helped by Russia, Ukraine, and China giving the hackers safe haven. It also is not helped by the US government sacntioning the writing of Stuxnet, Duqu, Flame, and Gauss. I am opposed to state sanctioned malware. My blog's name is:

http://securemecca.blogspot.com

What I am arguing for is a rethinking of the SMTP protocol that makes it very difficult for something like this to happen any more. It may take the form of certificates being issued for each SMTP server and without it you just won't be able to send email. hhhobbit (talk) 14:46, 30 August 2012 (UTC)[reply]

Retry timing per RFC

The article mentions an RFC which "requires" 4 hour retries. What RFC is that? —Preceding unsigned comment added by 198.145.222.48 (talk • contribs) 19:57, 3 May 2006

This is an excellent point. While many MTAs employ a strategy that attempts to re-transmit every 4 hours (as I recall), that is usually after the initial attempts to re-transmit at a higher frequency as laid out in RFC 2821:

Experience suggests that failures are typically transient (the target system or its connection has crashed), favoring a policy of two connection attempts in the first hour the message is in the queue, and then backing off to one every two or three hours. [1]

Of course, this is only an advisory, and not a requirement of the RFC, but unless someone can demonstrate an RFC that says otherwise, I think this article needs to be altered to reflect what the RFCs actually say. -Harmil 01:32, 4 May 2006 (UTC)[reply]

The 4 hour thing comes from the default configuration for some of the major unix mail servers and is a norm but not a standard

Initial 220 Message: 5 minutes - Many SMTP servers accept a TCP connection but delay delivery of the 220 message until their system load permits more mail to be processed.
— 4.5.3.2 Timeouts

[2]

Every greylist server I have will wait for 5mins before permitting valid retry. ViktorVaughn 15:50, 26 July 2006 (UTC)[reply]

RFCs

The article refers to several RFCs and treats them as standards. This is very incorrect. An RFC is a Request For Comment and is nothing more than a precurser to a proposal for a standard. Standards may be identified by the prefix STD. The treatment of RFCs as standards results in misinformation that only muddies an already confused subject. This is clearly indicated in the discussion regarding delivery retries. Such retries are completely optional, with no RFC or STD making them compulsory. —Preceding unsigned comment added by 58.104.25.152 (talk) 21:05, 20 March 2009 (UTC)[reply]

Fixed the first occurrence of the word "standard", not sure about the second. -79.180.25.233 (talk) 13:06, 2 September 2009 (UTC)[reply]

It is not "very incorrect" to treat RFCs as standards. It is, however, unhelpful to suggest that that something that is not an IETF STD is somehow not standardized. On those rare occasions where RFCs are actually elevated to the status of IETF STD, there is no change to the RFC - and (this is the important part for the purpose of this discussion) the RFC is not supplanted, it merely obtains an additional label. On the whole, RFCs are extremely precisely written, reflecting current practice and theory in sufficient detail to allow accurate implementation. This has been known to hold true even for RFCs explicitly written for comedic value.

Go read RFC 2821. Section 4.5.4.1, if you please. Retries are explicitly mentioned there and other places in the document. — Preceding unsigned comment added by Dns-bind (talk • contribs) 04:44, 8 February 2013 (UTC)[reply]

greylisting can get your mail server blacklisted

just a note about this. i wonder if others feel the info that "greylisting might result in your mail server being blacklisted by some spam-control services" might belong in the article's disadvantages section. [I can only relate my own anecdotal experience and do not have the technical knowledge to participate on this article as an author.]

i have a very low-traffic domain and host a very small discussion list (mailman) and several mail accounts on the mail server. because I need to receive mail from legitimate unknown parties without forcing them through any kind of validation procedure, i cannot rely solely on whitelisting so i use greylisting to eliminate 99% of all spam successfully.

however -- one of my discussion list subscribers forwarded a note from his ISP that he can no longer send to or receive mail from my server. his ISP uses "backscatterer.org" (see Backscatter) as one RBL source and a test on my mail server's IP address on backscatterer.org says: "This IP IS CURRENTLY LISTED in our Database. Please note that this listing does not mean you are a spammer, it means your mailsystem is either poorly configured or it is using abusive techniques.If you don't know what BACKSCATTER or Sender Callouts are, click the links above to get clue how to stop that kind of abuse."

This org considers sender callouts to be "abuse". They keep one's server on the blacklist for four weeks and if one is still employing greylisting they just re-list you. The only way to get delisted quickly is to first kill your sender callouts and to PAY backscatterer.org 50 euros (!!!). This is after they first punish you for doing something that is fairly standard, blaming you for the way spammers operate, and even insulting folks who employ greylisting on their mail server. (Their Contact Us page reads: "There should be no need to contact us: We have heard all possible excusions why people think they can not stop their systems backscatter or doing sender callouts. If you have chosen to be a lazy or selfish netcitizen letting your system backscatter or doing sender callouts you perfectly match listing criterias. Your recipients and we are tired of all the fake bounces, misdirected autoresponders and verify calls wasting our resources, and therfore you got blocked." Personally, I think they are lazy and selfish netizens for putting up such a poorly written page [if you want to write in English, spend the time or money to make it literate!] and for blacklisting folks for having a perfectly legal setup and then CHARGING to be removed only if you set up your mail server the way THEY want.

Back to the Wikipedia article, I would not ask that backscatterer.org be trashed for the horrible organization it is, but I do think that in the Disadvantages section some note should be made of the disadvantage to the mail host who becomes blacklisted because of sendouts, and also the potential for DdOS attacks against the owner of an email address that was used in forged spam, such as backscatterer.org claims can happen on their page at http://www.backscatterer.org/index.php?target=sendercallouts

Ilyse Kazar (talk) 05:32, 30 January 2010 (UTC)[reply]

Sounds like it was callouts that got you blacklisted, not greylisting. 23:28, 11 March 2010

Duplication

This section near the end is partially duplicating earlier information. Needs some editing.

"Greylisting will cause longer delivery delays if the sender has a large infrastructure and is sending from a different IP when it retries. However this technically breaks SMTP protocol rules, since delivery is the responsibility of the sending server and its associated IP address, ..."

-- Dougher (talk) 02:56, 16 December 2010 (UTC)[reply]

Pools of sending machines

On 8 August 2012, User:Bwrs requested quotation and full citation on the alleged breakage that using pools of sending server would cause (Do the RFCs expressly state this, and if not, then how clearly do the RFCs imply it?). Those paragraphs were added on 14 December 2010 and 1st November 2010‎ in two different subsections, by "212.21.120.10" (an address of a large ISP in Berkshire, UK). That author argues that using a pool of servers would break some unspecified RFC. Besides being redundant, those paragraphs are false. I'll remove both.

ale (talk) 11:12, 1 November 2012 (UTC)[reply]