Claus Aßmann <ca+sendmail(-no-copies-please)@mine.informatik.uni-kiel.de> wrote:

> Tim Mooney wrote:
>> xdelay=00:00:01, mailer=esmtp, pri=44502294, relay=example-com.mai...ction.outlook.com.
>> [IPv6:their-address-withheld], dsn=4.0.0, stat=Deferred: 450 4.7.26 Service does not accept messages sent over
>> IPv6 [our-smtp-server-ipv6-address] unless they pass either SPF or DKIM validation (message not signed)
>
> Wow, really? I didn't see that requirement in any RFC.
> But hey, "We are M$, we don't care about ..."

Unfortunately also Google seems to these days be doing this, except they
give a dsn=5.0.0 answer.

It seems that the thinking is that if you are able to set up IPv6 on
your host, you must be super-good at Teh Internet and you'll also very
easily produce a fully functional SPF+DKIM setup.

Has any progress been made on the "prefer IPv4 connections" option over
these 5 years?

--
/* * * Otto J. Makela <om@iki.fi> * * * * * * * * * */
/* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
/* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */
/* * * Computers Rule 01001111 01001011 * * * * * * */

Am 27.10.2022 um 15:46:14 Uhr schrieb Otto J. Makela:

> Unfortunately also Google seems to these days be doing this, except
> they give a dsn=5.0.0 answer.
>
> It seems that the thinking is that if you are able to set up IPv6 on
> your host, you must be super-good at Teh Internet and you'll also very
> easily produce a fully functional SPF+DKIM setup.

The problem with IPv6 is the amount of addresses. Operating IP
blocklists for IPv4 is rather easy compared to IPv6. Setting up SPF
should be rather easy, DKIM is much more complicated.

Do you have SPF set up correctly?

Marco Moock <mo01@posteo.de> wrote:

> Am 27.10.2022 um 15:46:14 Uhr schrieb Otto J. Makela:
>> It seems that the thinking is that if you are able to set up IPv6 on
>> your host, you must be super-good at Teh Internet and you'll also
>> very easily produce a fully functional SPF+DKIM setup.
>
> The problem with IPv6 is the amount of addresses. Operating IP
> blocklists for IPv4 is rather easy compared to IPv6. Setting up SPF
> should be rather easy, DKIM is much more complicated.

Blocklists were a thing of the 2010's anyway, spammers these days seem
to be fully functioning criminals who steal all resources they need.
The amount of spam originating from outlook.com/gmail.com is suprising.

> Do you have SPF set up correctly?

Yes, SPF is correctly set up. Although with some of our clients we're
getting problematically close to the "max 10 lookups" limitation,
these solutions are really not designed for large-scale outsourcing.

We're working on DKIM with the dozen or so clients who haven't needed it
up till now, until they suddenly do now.

--
/* * * Otto J. Makela <om@iki.fi> * * * * * * * * * */
/* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
/* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */
/* * * Computers Rule 01001111 01001011 * * * * * * */

Am 27.10.2022 um 16:18:10 Uhr schrieb Otto J. Makela:

> Blocklists were a thing of the 2010's anyway, spammers these days seem
> to be fully functioning criminals who steal all resources they need.

Mostly they use hacked machines.

> The amount of spam originating from outlook.com/gmail.com is
> suprising.

Because Google doesn't care about this, same on Google Groups.

Otto J. Makela <om@iki.fi> wrote:
> Claus Aßmann <ca+sendmail(-no-copies-please)@mine.informatik.uni-kiel.de> wrote:
>
>> Tim Mooney wrote:
>>> xdelay=00:00:01, mailer=esmtp, pri=44502294, relay=example-com.mai...ction.outlook.com.
>>> [IPv6:their-address-withheld], dsn=4.0.0, stat=Deferred: 450 4.7.26 Service does not accept messages sent over
>>> IPv6 [our-smtp-server-ipv6-address] unless they pass either SPF or DKIM validation (message not signed)
>>
>> Wow, really? I didn't see that requirement in any RFC.
>> But hey, "We are M$, we don't care about ..."
>
> Unfortunately also Google seems to these days be doing this, except they
> give a dsn=5.0.0 answer.

Which prooves that some silly people are also working for google.

> It seems that the thinking is that if you are able to set up IPv6 on
> your host, you must be super-good at Teh Internet and you'll also very
> easily produce a fully functional SPF+DKIM setup.

The message states SPF (logical) /or/ DKIM! And neither SPF nor DKIM are
books with seven seals. DKIM is a little bit tricky for a comany which
sends diverse flavours of mails but its not a trick...

> Has any progress been made on the "prefer IPv4 connections" option over
> these 5 years?

This is IMHO no sendmail issue! Simply make your DNS sort the results of
a query so that A RRs are "listed" before AAAA RRs. Possibly this can
also be done locally by using the DNS resolver directive of sendmail
together with an appropriate resolver option - for example "sortlist" -
with a "pattern" which matches IPv4 addresses first ("0/0"?) and IPv6
addresses second ("::/0"?).

Regards
Henning
--
Hacking's just another word for nothing left to kludge.

Henning Hucke <h_hucke+spam.news@newsmail.aeon.icebear.org> wrote:

> Otto J. Makela <om@iki.fi> wrote:
>> Claus Aßmann
>> <ca+sendmail(-no-copies-please)@mine.informatik.uni-kiel.de> wrote:
>>> The source code has a comment about this:
>>> ** Try v6 first, then fall back to v4.
>>> and there doesn't seem to be an option to change that
>>> in sendmail.
>>
>> Has any progress been made on the "prefer IPv4 connections" option
>> over these 5 years?
>
> This is IMHO no sendmail issue! Simply make your DNS sort the results
> of a query so that A RRs are "listed" before AAAA RRs. Possibly this
> can also be done locally by using the DNS resolver directive of
> sendmail together with an appropriate resolver option - for example
> "sortlist" - with a "pattern" which matches IPv4 addresses first
> ("0/0"?) and IPv6 addresses second ("::/0"?).

Considering Claus's comment from 2017 (I've copied it above) about how
the sendmail code is built, I doubt trying to mess around with the
resolver will help in this case.

--
/* * * Otto J. Makela <om@iki.fi> * * * * * * * * * */
/* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
/* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */
/* * * Computers Rule 01001111 01001011 * * * * * * */

Otto J. Makela wrote:

> Has any progress been made on the "prefer IPv4 connections" option over
> these 5 years?

There were no requests in those 5 years, hence we didn't work on
it (and nobdoy sent a patch).

Now we will be looking into it because M$ is breaking things
again (there are already many workarounds in the code because M$
is too $#%^@ to set up their IPv6, esp. DNS).

--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.

Am 28.10.2022 schrieb Claus Aßmann
<INVALID_NO_CC_REMOVE_IF_YOU_DO_NOT_POST_ml+sendmail(-no-copies-please)@esmtp.org>:

> Now we will be looking into it because M$ is breaking things
> again (there are already many workarounds in the code because M$
> is too $#%^@ to set up their IPv6, esp. DNS).

Thanks for doing that, Claus.

Will that option be a general "prefer IPv4" or one that can be
specified for certain recipient domains?

The later one would be very helpful to address problems with IPv6 and
Google/MS.

Claus Aßmann <INVALID_NO_CC_REMOVE_IF_YOU_DO_NOT_POST_ml+sendmail(-no-copies-please)@esmtp.org> wrote:
> Now we will be looking into it because M$ is breaking things
> again (there are already many workarounds in the code because M$
> is too $#%^@ to set up their IPv6, esp. DNS).

BTW
MS fixed their bad MX entries a short while ago.
falling back to IPv4 is currently no longer necessary to
deliver mail to them.

I don't really see a need to fiddle with the sendmail code
in to order to fallback to IPv4 in such cases.

We've deployed a temporary sendmail instance without "-DNETINET6"
during the days MS had fcked up their MX and routed their domains
via mailertable to that instance. Was a bit of a hazzle at first
but easy enough. IMHO.

Completely untested patch, used at your own risk etc...
Please report back; any problem description should include enough
information to reproduce it.

To use:
copy the esmtp mailer definition to esmtp4,
add the flag '4' to F=,
and select the esmtp4 mailer for any domain that should
use only IPv4 addresses, maybe something like:
gmail.com esmtp4:gmail.com

As I wrote: it's untested!

diff --git a/sendmail/daemon.c b/sendmail/daemon.c
index c782a50..eafd6f6 100644
--- a/sendmail/daemon.c
+++ b/sendmail/daemon.c
@@ -2160,7 +2160,7 @@ makeconnection(host, port, mci, e, enough
#if NETINET6
volatile bool v6found = false;
#endif
- volatile int family = InetMode;
+ volatile int family;
SOCKADDR_LEN_T len;
volatile SOCKADDR_LEN_T socksize = 0;
volatile bool clt_bind;
@@ -2181,6 +2181,10 @@ makeconnection(host, port, mci, e, enough
tlsa_flags = *ptlsa_flags;
*ptlsa_flags &= ~(TLSAFLALWAYS|TLSAFLSECURE);
#endif
+ if (bitnset(M_IPV4, mci->mci_mailer->m_flags))
+ family = AF_INET;
+ else
+ family = InetMode;
/* retranslate {daemon_flags} into bitmap */
clrbitmap(d_flags);
diff --git a/sendmail/sendmail.h b/sendmail/sendmail.h
index e4e790b..4c90286 100644
--- a/sendmail/sendmail.h
+++ b/sendmail/sendmail.h
@@ -630,8 +630,8 @@ struct mailer
#define M_NOMX '0' /* turn off MX lookups */
#define M_NONULLS '1' /* don't send null bytes */
#define M_FSMTP '2' /* force SMTP (no ESMTP even if offered) */
- /* '4' free? */
#define M_EBCDIC '3' /* extend Q-P encoding for EBCDIC */
+#define M_IPV4 '4' /* Use only IPv4 */
#define M_TRYRULESET5 '5' /* use ruleset 5 after local aliasing */
#define M_7BITHDRS '6' /* strip headers to 7 bits even in 8 bit path */
#define M_7BITS '7' /* use 7-bit path */