Qmail and Greylisting - RFC-2821

[kram@]

Hello All,

I have recently found a problem sending mail to a particular "Service Provider" in South Africa using Greylisting. Every time a user sends mail to one of the domains used by this provider, the following code is dissplayed in the mail log.

server qmail: 1204454094.066448 delivery 7: deferral: 196.2.42.3_does_not_like_recipient./Remote_host_said:_450_4.7.1_<[email protected]>:
_Recipient_address_rejected:_Policy_Rejection-_Abuse./Giving_up_on_196.2.42.3./

This is the response from the service provider regarding the issue.

I understand your concern. I can request the mail administrators to consider exempting mail from your domain from the Greylisting filters, This is however a decision that will have to be taken at a much higher level than the Abuse and Security Team or mail server engineer team. Essentially it is a policy which will have to be discussed, considered and reviewed before any decision would be taken. This will take time.

They will probably require an explanation as to why it is not possible to configure your servers to comply with the retry recommendation in RFC 2821.

This is in compliance with RFC 2821 - "The current SMTP specification (RFC 2821 - http://tools.ietf.org/html/rfc2821) clearly states that "the SMTP client retains responsibility for delivery of that message" (section 4.2.5) and "the SMTP client is encouraged to try again", and "mail that cannot be transmitted immediately MUST be queued and periodically retried by the sender." (section 4.5.4.1)"

Please also understand that while many networks use Greylisting, the parameters are usually tweaked for each network's requirements. MWEB's filters are tweaked to the most efficient level for our clients and mail filtering scenario. Greylisting saves bandwidth loads on our servers, processing time of incoming mail, stops any virus before processing, etc. It is unlikely that a network would be granted exemption from this filtering, but if it is granted we will require the IP range of your domain mail servers as well as the hostnames.

I have spent ages trying to find out how to:
How does Qmail handle the 45x SMTP error codes?

How often does qmail retry to send email?

Each message has its own retry schedule. The longer a message remains undeliverable, the less frequently qmail tries to send it. The retry schedule is not configurable. The following table shows the retry schedule for a message that's undeliverable to a remote recipient until it bounces. Local messages use a similar, but more frequent, schedule.

Based on the schedule found here http://www.cyber-sentry.com/index.php?id=34 I am a little confused as delivery retires are not been atemted as stated. In fact email is delayed in the que for these doamins for 1hour - 3 days?

A fair bit of reading has suggested patching qmail with patch-qmail-1.03-rfc2821.diff
Found here http://www-dt.e-technik.uni-dortmund.de/~ma/qmail/patch-qmail-1.03-rfc2821.diff
Sadly I am not sure how to patch qmail, anybody have a suggestion or some insight?

when I run killall -ALRM qmail-send
The mail server tries to flush the que and resend the email however the same error is thrown out by the remote host even if i do this at delayed intervils of 10 - 30 min.

server qmail: 1204455869.893223 delivery 7: deferral: 196.2.42.1_does_not_like_recipient./Remote_host_said:_450_4.7.1_<[email protected]>:_Recipient_address_rejected:_Policy_Rejection-_Abuse./Giving_up_on_196.2.42.1./

This particular is presenting me with massive problems, and a number of my more serious clients are now threating to leave, and move the service provider mentioned above in order to not have this problem.

Please could anybody that has some information or a solution to this problem lend a hand!!!

Regards,

 

[j_kev@]

I had the same problem earlier

Please take a look et here
http://kb.swsoft.com/en/942

 

[kram@]

Not Mailman

Hello J_kev

Thanks fro the reply, but I do not use mailman, this simply seems to be a greylisting issue from the remote provider.

Further reading on the this topic has lead me to

451 4.7.1 Please try again later

follows RFC 2034 (http://www.ietf.org/rfc/rfc2034), The 451 code is from
RFC 2821, and the 4.7.1 is from RFC 3463
(http://www.ietf.org/rfc/rfc3463.txt), which tries to clean up the SMTP
status code mess. Mind you, the use of 4.7.1 seems wrong, although common
to both qmail and sendmail. The RFC says (in two parts):

4.XXX.XXX Persistent Transient Failure

A persistent transient failure is one in which the message as
sent is valid, but persistence of some temporary condition has
caused abandonment or delay of attempts to send the message.
If this code accompanies a delivery failure report, sending in
the future may be successful.

X.7.1 Delivery not authorized, message refused

The sender is not authorized to send to the destination. This
can be the result of per-host or per-recipient filtering. This
memo does not discuss the merits of any such filtering, but
provides a mechanism to report such. This is useful only as a
permanent error.

 

[infogalera]

Hi,

Also we are suffering from graylisting and Qmail. We have problems sending messages to our local university. It rejects all our messages with a "deferral: Connected_to_xxx.88.25.14_but_connection_died._(#4.4.2)/". They stand in the queue for 7 days and later they are finally bounced.
We have contact the university postmaster and they have implmented a graylisting anti-spam system. By default they reject all atempts to MX 5 so Qmail should try again with MX 10 but it never does it, but tries to contact MX 5 again and again...

Any solution?

Alex

 

[kram@]

rfc2821 Patch for qmail

After much reading, and intense searching I have found this "patch"
http://www-dt.e-technik.uni-dortmund.de/~ma/qmail/patch-qmail-1.03-rfc2821.diff

patch-qmail-1.03-rfc2821.diff

What i understand is that if the primary MX does not respond, qmail will try the higher MX. If the primary MX responds but temp fails the message, qmail will try the same MX again later.

I dont know how to impliment this patch!!
If somebody could offer up some assistance, that would rock.