Bug 88746 – qmail-1.03-r16.ebuild patches break compatibility with greylisting on remote servers

• Product: Gentoo Linux
• Status: VERIFIED TEST-REQUEST

[Description Torsten Kurbad 2005-04-11 09:35:41 UTC]

I figured out that one of the patches that go into qmail-1.03-r16 by default breaks compatibility with greylisting on remote servers.

An excerpt from the logfile to illustrate what I mean:

@40000000425a822234ba8af4 new msg 16802535
@40000000425a822234bb4e44 info msg 16802535: bytes 2390 from <[e-mail]> qp 25273 uid 210
@40000000425a822234cae28c starting delivery 12: msg 16802535 to remote [e-mail]
@40000000425a822234cafde4 status: local 0/10 remote 8/20
@40000000425a8223294a4254 delivery 12: success: user_and_password_not_set,_continuing_without_authentication./r<[e-mail]>_141.48.3.51_failed_after_I_se
nt_the_message./Remote_host_said:_451_You_are_greylisted._We_will_accept_this_mail_from_you_in_5_minutes./
@40000000425a8223294d4bac status: local 0/10 remote 7/20
@40000000425a8223294e842c end msg 16802535

As you can see, qmail doesn't even take notice of the 451 error message that should lead to deferral instead of success. This happens all the same with all combinations of recognized USE-flags (e.g. -ssl doesn't make a difference)

I customized the ebuild and removed several patches. Leftovers are:
- errno-patch
- qmailqueue-patch
- link-sync-patch
- 0.0.0.0-patch
- sendmail-flagf-patch
- date-localtime-patch
- sendmail-ignore-N-patch
- mfcheck-patch (original version, not the customized one for -r16)
- double-bounce-trim-patch

Since I left out the big-concurrency/big-todo patches, I changed
 echo -n "500" > ${S}/conf-spawn
to
 echo -n "255" > ${S}/conf-spawn

Now I get the correct behavior:
@40000000425a9c541c07be3c new msg 17337872
@40000000425a9c541c08a89c info msg 17337872: bytes 2329 from <[e-mail]> qp 21068 uid 210
@40000000425a9c541c16837c starting delivery 11: msg 17337872 to remote [e-mail]
@40000000425a9c541c16aa8c status: local 0/10 remote 2/20
@40000000425a9c5502ff43ec delivery 11: deferral: 141.48.3.51_failed_after_I_sent_the_message./Remote_host_said:_451_You_are_greylisted._We_will_accept_this_mail
_from_you_in_5_minutes./
@40000000425a9c5502ff7e84 status: local 0/10 remote 1/20

and some minutes later:

@40000000425a9de52eaba3b4 starting delivery 35: msg 17337872 to remote [e-mail]
@40000000425a9de52eabcac4 status: local 0/10 remote 1/20
@40000000425a9de60a4b8d2c delivery 35: success: 141.48.3.51_accepted_message./Remote_host_said:_250_OK_id=1DL1Fk-0004pf-Gr/
@40000000425a9de60a4eaa0c status: local 0/10 remote 0/20
@40000000425a9de60a4f946c end msg 17337872

Thus, one of the usually applied patches not listed above breaks the correct handling of greylisted mails.

Can someone please further investigate this?

Thanks in advance!
Best regards,
Torsten

[Comment 1 Anders Hellgren 2005-06-03 01:10:04 UTC]

This is due to qregex-starttls-2way-auth-20041230.patch. If authentication isn't
used qmail-remote logs

void auth_user_not_set() {
  out("Kuser and password not set, continuing without authentication.\n");

where the K tells qmail-send the delivery was a success even if it later gets a
45x. This appears to be fixed in newer versions of the patch. The latest version
is dated 20050523.

[Comment 2 Michael Hanselmann (hansmi) (RETIRED) 2005-06-03 01:14:27 UTC]

Yes, this patch has to be updated. I'm currently learning for my exams and hope
to be able to work on qmail again after that.

[Comment 3 Michael Hanselmann (hansmi) (RETIRED) 2005-06-05 08:21:40 UTC]

Got bored at learning and updated the patch. Please test again.

[Comment 4 Michael Hanselmann (hansmi) (RETIRED) 2005-06-12 12:43:51 UTC]

Tested myself. Closing. (don't hesitate to comment again on it, tough)