[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1106460: marked as done (unblock: sauce/0.9.3)



Your message dated Mon, 26 May 2025 20:44:32 +0000
with message-id <E1uJegS-002zBB-0H@respighi.debian.org>
and subject line unblock sauce
has caused the Debian Bug report #1106460,
regarding unblock: sauce/0.9.3
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1106460: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1106460
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: sauce@packages.debian.org
Control: affects -1 + src:sauce
User: release.debian.org@packages.debian.org
Usertags: unblock

Please unblock package sauce


[ Reason ]

SAUCE mishandled this situation (sketching)
   mail-domain MX 0 relay0
   relay0 IN AAAA aa::bb
   mail-domain MX 1 relay1
   relay1 IN A 1.2.3.4

It would do a query for A RRs for MX relay0, find none, and declare
the mail domain broken.  It ought to tolerate this situation.


[ Impact ]

Users of SAUCE will reject mail unjustifiably.


[ Tests ]

I have tested these changes on my own mail server.  I did a number of
ad-hoc tests against the running instance.

I have also now successfully exchanged email with the affected user,
via the affected mail domain.

I think that almost all of the paths in the new/affected code have
been tested, but I haven't done a coverage check of any kind.

Unfortunately this package has no automated tests.


[ Risks ]

It is possible that I messed something up.  There is very little
syntax checking and no type checking of un-executed code.

If that were the case, it might be necessary to do a further update.

No-one other than users of this package, SAUCE, itself, and their
correspondents, would be affected.

In summary, I'm reasonably confident that this version is an
improvement, but there does remain some risk.


[ Checklist ]
  [y] all changes are documented in the d/changelog
  [y] I reviewed all changes and I approve them
  [y] attach debdiff against the package in testing

[ Other info ]

To be effective, this fix also requires the installation of an
updated version of chiark-tcl.  I have uploaded that already.

chiark-tcl has automated tests and a generally higher level of
maturity.  I believe chiark-utils will migrate in due course according
to the current freeze policy.  If it doesn't I will file an unblock,
as needed.

(This bugfix does not imply an actual *dependency* between the two
packages.  The new version of SAUCE will function with the old version
of adns, albeit with the bug unfixed.)


unblock sauce/0.9.3
diff --git a/avf.tcl b/avf.tcl
index 3f41f31..0603edf 100644
--- a/avf.tcl
+++ b/avf.tcl
@@ -156,9 +156,9 @@ thread_subproc avf tryaddrs {} {
 	    }
 	} elseif {[llength $state(mxhosts)]} {
 	    set state(dnsid) [thread_start dns $state(desc) \
-		    [lindex [lindex $state(mxhosts) 0] 1] A 0]
+		    [lindex [lindex $state(mxhosts) 0] 1] addr 0]
 	    set state(mxhosts) [lreplace $state(mxhosts) 0 0]
-	    thread_join avf $id dns $state(dnsid) a_ok a_err
+	    thread_join avf $id dns $state(dnsid) addr_ok addr_err
 	    return
 	} else {
 	    thread_error avf $id $state(tempfail) {}
@@ -167,15 +167,33 @@ thread_subproc avf tryaddrs {} {
     }
 }
 
-thread_chainproc avf a_ok {answers emsgstr how} {
+thread_chainproc avf addr_ok {answers_all emsgstr how} {
     unset state(dnsid)
-    set state(mxaddrs) $answers
-    if {![llength $answers]} { thread_finish avf $id 0 $emsgstr; return }
+    set state(mxaddrs) {}
+    foreach answer $answers_all {
+	manyset $answer atype avalue
+	switch -exact $atype {
+	    INET {
+		# append, see below
+	    }
+	    INET6 {
+		# Ideally we would support this, but we would want to
+		# have a way to bind to a separate outgoing address.
+		continue
+	    }
+	    default {
+		# Some AF we don't support.
+		continue
+	    }
+	}
+	lappend state(mxaddrs) $avalue
+    }
+
     avf_tempfail 30 "unable to contact any mail exchanger for $state(dm)"
     avf_tryaddrs
 }    
 
-thread_chainproc avf a_err {emsg} {
+thread_chainproc avf addr_err {emsg} {
     unset state(dnsid)
     avf_tryaddrs
 }
diff --git a/debian/changelog b/debian/changelog
index e770fce..1f1e1df 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+sauce (0.9.3) unstable; urgency=medium
+
+  * When verifying email addresses, tolerate MX's that have only AAAA
+    RRs and no A RRs.  (We still don't properly support IPv6, sadly.)
+    [Report from Simon Iremonger]  Closes: #1106228.
+
+ -- Ian Jackson <ijackson@chiark.greenend.org.uk>  Sat, 24 May 2025 19:57:55 +0100
+
 sauce (0.9.2+nmu1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git a/dns.tcl b/dns.tcl
index 21a2252..14fc50c 100644
--- a/dns.tcl
+++ b/dns.tcl
@@ -46,6 +46,7 @@ load chiark_tcl_adns-1.so
 
 set rrdata_adnstype(MX) mx
 set rrdata_adnstype(A) a
+set rrdata_adnstype(addr) addr
 set rrdata_adnstype(TXT) txt
 set rrdata_adnstype(PTR) ptr-
 

--- End Message ---
--- Begin Message ---
Unblocked.

--- End Message ---

Reply to: