Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 676
  • Last Modified:

mail greylisting and SMTP status codes

Hi Experts
I have a forwarding mailserver inside my office (sendmail) which does some virus check on outgoing mail.
All goes fine except with a particular domain, which always rejects my mails. I spoke with the maintainer of that domain and he says his mailserver is rejecting mails because it is doing greylisting.
But mails are rejected with errors like 5xx which I know are permanent failures.
I assert that his mailserver should return an error like 4xx for greylisting.
He replies that my mailserver is misconfigured and should keep retrying after the first 5xx error.
Who's right and who's wrong?
And, if I'm wrong, can someone point me out on how to configure sendmail to retry sending after the first 5xx error?
0
lomo74
Asked:
lomo74
  • 2
  • 2
2 Solutions
 
nociSoftware EngineerCommented:
According to this source:
http://www.ietf.org/rfc/rfc0821.txt
Chapter 4.4.2:
2xx is OK
3xx is INFO
4xx is Temporary problems (ie retry later)
5xx is Final status (dont try again).

So a 4xx status (452 is a primary candidate, insufficient disk space...) is a definite status that needs to be used.
If a 5xx message is returned it really means no retry SHOULD EVER be attempted... (It sure is a way to loose mail..., but it's more blacklisting than greylisting though_.

Also this is a reference:
http://en.wikipedia.org/wiki/Callback_verification (search for geylisting somewhere halfway).
0
 
lomo74Author Commented:
Ok noci thank you.
I had a look at the various RFCs and that shed some light on the problem.
Now, one more little question before closing this Q.
The receiver is, obviously, badly configured. But if I use e.g. gmail SMTP server, emails are delivered.
Does this mean, in your opinion, that gmail itself is violating RFC, in an effort to deliver mail to buggy SMTP servers?
0
 
nociSoftware EngineerCommented:
If google still retries after a 5xx status then it's their design decision. It does fit in a filisophy that follows: Be strict in what you send/respond but be liberal in what you expect.... I for one do like to be more strict w.r.t. RFC's If I get an advise to stop bothering (like 5xx) i will adhere.

Ofcourse you are free to interpret return codes differently, but the RFC implied action is what you need to expect from other implementations.
So expecting a retry after a 5xx does violate the earlier filosofy but still retrying after proper timeout more or less does.
That certainly doesn't mean that google should be taken as the reference of how it SHOULD be done...

There are more corner cases w.r.t. RFC's and Microsoft, amongst others, is famous for exploiting such interpretation gaps (embrace & extend) effectively blocking proper interoperation.

Also various outfits disregard the timeouts associated with SMTP. The first retry should be after 1 hour, but many sites do retry after a few minutes...
Also a clear violation and greylisting really does expect that timeouts should be observed. (Too early retransmit should be penalised in greylisting with a newly set timeout).
0
 
lomo74Author Commented:
Oh thank you noci. I much appreciate your opinion. Unfortunately there is plenty of buggy and badly configured software out there.
So now I must convince this person that he is wrong and that he'd better review his config --
No more opinions needed, RFC says it all - closing Q.
0

Featured Post

Important Lessons on Recovering from Petya

In their most recent webinar, Skyport Systems explores ways to isolate and protect critical databases to keep the core of your company safe from harm.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now