Jump to content
Sign in to follow this  
dzekas

mailhost with greylisting enabled

Recommended Posts

If mail server uses greylisting, it reject first connection attempt with 450 error. Second connection attempt with same address should work.

Is it possible to provide "retry" button, that does not change

# The IP address of the host attempting the delivery

# The envelope sender address

# The envelope recipient address

Share this post


Link to post
Share on other sites

can you explain what this has to do with the SpamCop Mail-Host configuration? I can't even figure out if this is something that should be moved to "Help" ...????

Share this post


Link to post
Share on other sites

It is impossible to add mailhost, if mailhost uses greylisting. spamcop's cgi gets 450 error and does not allow resending confirmation email. Error is temporally. Error message says "retry in n seconds".

I can hit Back and retry posting later, but it would be nicer to have button that does same thing.

This is just feature suggestion.

Share this post


Link to post
Share on other sites

OK, thanks. I guess I understand .. though it sounds like a challenge/response system, which basically sucks for many reasons. I'd ask if you can whitelist the SPamCop stuff prior to trying to do the mailhost registration, but as you say that you aren't allowed to re-send the data, then I believe you are at the point of following the procedures listed in at least two of Ellen's Pinned posts .... but am also guessing that this will be a bounce up to Julian for a look. I can't see him re-coding for this bounce "problem" .. but I don't think Ellen has the power/access to force your data into inclusion either .... ???

Share this post


Link to post
Share on other sites
It is impossible to add mailhost, if mailhost uses greylisting. spamcop's cgi gets 450 error and does not allow resending confirmation email. Error is temporally. Error message says "retry in n seconds".

I can hit Back and retry posting later, but it would be nicer to have button that does same thing.

This is just feature suggestion.

TTBMK there is no provision for retrying. Either the mailserver accepts the email probe or it doesn't. Perhaps you can jury rig this by trying to immediately re-add the mailhost and forcing new probes to be sent ....

Share this post


Link to post
Share on other sites

Some people using mailhosts that permit "greylisting" may be able to turn the greylisting off temporarily. This is true for example of http://www.sneakemail.com/ (which also provides an explanation of what "greylisting" means).

Share this post


Link to post
Share on other sites
TTBMK there is no provision for retrying. Either the mailserver accepts the email probe or it doesn't. Perhaps you can jury rig this by trying to immediately re-add the mailhost and forcing new probes to be sent ....

11889[/snapback]

If SpamCop is not retrying sending of email after receiving an SMTP 450 response code, then it is ignoring RFC 2821 section 4.2.1. A 450 response means "try later" and can be issued by a mailserver for a variety of reasons (e.g. overload).

In the mentioned case it is used for greylisting, which means issuing a 450 response the first time a message is sent (with some characteristics) and accepting it the second time. It is used to distinguish between some bulk mailers and real email servers. Real email servers would retry sending email for a few days unless they get a permanent error code. It is not "challenge/response" as it is not trying to confirm that the sender is human, just that the sending server complies with one sentence in RFC 2821. The human sender would be bothered by this only if her system doesn't properly handle the SMTP transient error codes.

Share this post


Link to post
Share on other sites
If SpamCop is not retrying sending of email after receiving an SMTP 450 response code, then it is ignoring RFC 2821 section 4.2.1. A 450 response means "try later" and can be issued by a mailserver for a variety of reasons (e.g. overload).

In the mentioned case it is used for greylisting, which means issuing a 450 response the first time a message is sent (with some characteristics) and accepting it the second time. It is used to distinguish between some bulk mailers and real email servers. Real email servers would retry sending email for a few days unless they get a permanent error code. It is not "challenge/response" as it is not trying to confirm that the sender is human, just that the sending server complies with one sentence in RFC 2821. The human sender would be bothered by this only if her system doesn't properly handle the SMTP transient error codes.

13815[/snapback]

Correct -- the reject code 450 mean the sending server may try again later, it does not require that it try again later nor that it retry for x number of days. The logic for the mailhosts is such that it simply does not try again.

Share this post


Link to post
Share on other sites
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-SMTP agents) must agree on the interpretation.  Each reply

      in this category might have a different time value, but the SMTP

      client is encouraged to try again.

(My emphasis.)

x5z Mail system: These replies indicate the status of the receiver

      mail system vis-a-vis the requested transfer or other mail system

      action.

450 Requested mail action not taken: mailbox unavailable

      (e.g., mailbox busy)

Ellen is obvously correct, in that the RFC doesn't require the sender to retry. However, if a "sender" (in which term I lump both the user and the software) of real mail didn't retry in these cases, the real mail could be dropped simply because the receiving mailbox is temporarily unavailable. If Spamcop would automatically retry a few times, or supply the suggested "retry" button, that change would enlarge the class of mail hosts that Spamcop mail users could use successfully and could have probed successfully without involving the staff. There would be a cost and a benefit. The only question is whether the benefit is worth the cost.

Respectfully submitted,

Share this post


Link to post
Share on other sites

The point is that the mail-host probe isn't what one would normally call your "standard" e-mail. This particular e-mail (probe) is a one-time thing .. failure could be due to many other reasons, such as the user screwing up the address while typing it in .... the anticipation is that the user supplies the data, probe goes out, everything works, and the user follows through on the mail-host registration .... failure at any point says that human intervention is required. Again, this is not your normal e-mail process / situation.

Share this post


Link to post
Share on other sites
(My emphasis.)

Ellen is obvously correct, in that the RFC doesn't require the sender to retry.  However, if a "sender" (in which term I lump both the user and the software) of real mail didn't retry in these cases, the real mail could be dropped simply because the receiving mailbox is temporarily unavailable.  If Spamcop would automatically retry a few times, or supply the suggested "retry" button, that change would enlarge the class of mail hosts that Spamcop mail users could use successfully and could have probed successfully without involving the staff.  There would be a cost and a benefit.  The only question is whether the benefit is worth the cost.

Respectfully submitted,

13909[/snapback]

Yes for "real" email not retrying would be problematic certainly. However for the mailhost probe mail Julian made the decision that there would be no retries.

Share this post


Link to post
Share on other sites
Correct -- the reject code 450 mean the sending server may try again later, it does not require that it try again later nor that it retry for x number of days. The logic for the mailhosts is such that it simply does not try again.

13876[/snapback]

Yeah, and it also says that the sender is encouraged to retry. But it's not the point. The RFC was written with a real mail sender in mind, and the mail sender has an interest in the message getting through. So there was no need to say in the standard that the sender must retry, or even that the sender should retry, as this is what is expected that a normal sender would do. But the 450 codes were designed to support low reliabilty of mail servers. Many small email providers like university departments that run their own mailservers sometimes take the mailservers offline for hours. And another sad fact of life is that spam and viruses can sometimes overload small servers, so a 450 response on account of an overloaded server might not be that rare an ocassion, so perhaps retrying once or twice would give a much more reliable result to the mailhost probe.

Anyway, greylisting was designed to take advantage of spambot behaviour, and in this case the mailhosts probe behaves exactly as a spambot does, so it is treated as a spambot.

Edited by hadaso

Share this post


Link to post
Share on other sites

Can you guys clarify when greylisting is a problem.

Is it:

a. when the mailhost is registered, or...

b. whenever spam is reported on mail through that mailhost.

If a. only, then for sneakemail users they could just register through a non-greylisted account!

Many thanks

-Rob.

Share this post


Link to post
Share on other sites

The problem is only while registering an account that uses greylisting. Those should be able to be over-ridden by manually resubmitting within the greylist time period.

Once it is registered, the only problem I can think of (which I can not remember having been mentioned elsewhere in these types of problems) is in sending the automated replies to sumbissions. If a resend facility is not employed by Julian in the mailhost confirmation system, I would be surprised if it were employed elsewhere within the systems developed by Julian.

Share this post


Link to post
Share on other sites

Hi,

My ISP uses greylisting. So when i tried to configure the Mailhost system it resulted in an error, i don't know if i will recieve the test mail any way. It has been about 2 hours know (grey listing is configured for a half hour delay) and i haven' t recieve the mail.

Another issue is the verification mail of this forum. I had to re-ask for the validation mail. This happens normaly when the php mail service is usses insted a a MTA. The mail gets delays by greylisting and it is never resend by the server.

cheers

Share this post


Link to post
Share on other sites

This post was Moved/Merged into this exiting Topic.

My ISP uses greylisting. So when i tried to configure the Mailhost system it resulted in an error, i don't know if i will recieve the test mail any way. It has been about 2 hours know (grey listing is configured for a half hour delay) and i haven' t recieve the mail.

Not likely .. as in the above, the 'probe' is a onr-shot deal. But, as also suggested above, retrying to 'add' that host would hopefully get that seconf probe sent.

Another issue is the verification mail of this forum. I had to re-ask for the validation mail. This happens normaly when the php mail service is usses insted a a MTA. The mail gets delays by greylisting and it is never resend by the server.

33954[/snapback]

See, you already knew how to get around the issue.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×