info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
prefer IPv4 when connecting to external dual-stack MTAs
410 views
Skip to first unread message
Tim Mooney
May 16, 2017, 3:08:42 PM5/16/17
to
Hi all-
I'm looking for a way to make sendmail prefer to use IPv4 when connecting to a remote MTA that is dual-stack (has both IPv4 and IPv6 addresses published in the DNS).
We recently updated the outgoing email relay used by many of our servers. It's now running RHEL 7, which means sendmail 8.14.7 + whatever "vendor sauce" Red Hat adds when they package sendmail.
We also added an IPv6 address to the server, so it's now dual-stack.
The problem we're running into is that we've found a few remote MTAs that are also dual-stack that reject email from us now because they have more strict acceptance requirements when the mail is relayed over IPv6 than they do when it is relayed over IPv4:
May 7 13:46:03 smtp queue[47341]: v42IwfjL080025: to=<address....@example.com>, delay=4+23:47:19, 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) [BN1BFFO11FD005.protection.gbl]
We're not yet doing SPF or DKIM (I know, I'm a terrible person and this is my punishment). Because of the complexity of email in a campus environment, especially when you consider external vendors that may send email with our domain, we're probably months away from getting SPF deployed.
The general way one can make a Linux system prefer IPv4 for the source address when it's dual-stack is via settings in /etc/gai.conf, as described in gai.conf(5), getaddrinfo(3), and RFC6724 and RFC 3484.
The problem is that sendmail doesn't use getaddrinfo(); it still uses the older methods, so it ignores /etc/gai.conf
I know it's possible to use a mailertable entry to force certain addresses to be delivered via the specified IP address, and that we can even specify multiple IP addresses, as described here:
https://drjohnstechtalk.com/blog/2011/09/obscure-tips-for-sendmail-admins/
Unfortunately, the receiving end of at least some of these problems is Office365, and the MXes returned by Microsoft's DNS are frequently changing, such that I would need to be frequently updating the mailertable entry for the domains in question.
With all that said, is there some setting I've missed that will tell sendmail
to prefer to connect over IPv4, and only use IPv6 when it's the only option?
Thanks,
Tim
I'm looking for a way to make sendmail prefer to use IPv4 when connecting to a remote MTA that is dual-stack (has both IPv4 and IPv6 addresses published in the DNS).
We recently updated the outgoing email relay used by many of our servers. It's now running RHEL 7, which means sendmail 8.14.7 + whatever "vendor sauce" Red Hat adds when they package sendmail.
We also added an IPv6 address to the server, so it's now dual-stack.
The problem we're running into is that we've found a few remote MTAs that are also dual-stack that reject email from us now because they have more strict acceptance requirements when the mail is relayed over IPv6 than they do when it is relayed over IPv4:
May 7 13:46:03 smtp queue[47341]: v42IwfjL080025: to=<address....@example.com>, delay=4+23:47:19, 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) [BN1BFFO11FD005.protection.gbl]
We're not yet doing SPF or DKIM (I know, I'm a terrible person and this is my punishment). Because of the complexity of email in a campus environment, especially when you consider external vendors that may send email with our domain, we're probably months away from getting SPF deployed.
The general way one can make a Linux system prefer IPv4 for the source address when it's dual-stack is via settings in /etc/gai.conf, as described in gai.conf(5), getaddrinfo(3), and RFC6724 and RFC 3484.
The problem is that sendmail doesn't use getaddrinfo(); it still uses the older methods, so it ignores /etc/gai.conf
I know it's possible to use a mailertable entry to force certain addresses to be delivered via the specified IP address, and that we can even specify multiple IP addresses, as described here:
https://drjohnstechtalk.com/blog/2011/09/obscure-tips-for-sendmail-admins/
Unfortunately, the receiving end of at least some of these problems is Office365, and the MXes returned by Microsoft's DNS are frequently changing, such that I would need to be frequently updating the mailertable entry for the domains in question.
With all that said, is there some setting I've missed that will tell sendmail
to prefer to connect over IPv4, and only use IPv6 when it's the only option?
Thanks,
Tim
Claus Aßmann
May 17, 2017, 7:45:38 AM5/17/17
to
Tim Mooney wrote:
> I'm looking for a way to make sendmail prefer to use IPv4 when connecting to a remote MTA that is dual-stack
The source code has a comment about this:
> I'm looking for a way to make sendmail prefer to use IPv4 when connecting to a remote MTA that is dual-stack
** Try v6 first, then fall back to v4.
and there doesn't seem to be an option to change that
in sendmail.
> 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)
But hey, "We are M$, we don't care about ..."
> We're not yet doing SPF or DKIM (I know, I'm a terrible person and this is my punishment). Because of the
and DKIM is broken by certain MTAs and other things...
> The problem is that sendmail doesn't use getaddrinfo(); it still uses the older methods, so it ignores /etc/gai.conf
add a new compile time flag HASGETADDRINFO.
> With all that said, is there some setting I've missed that will tell sendmail
> to prefer to connect over IPv4, and only use IPv6 when it's the only option?
--
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.
Tim Mooney
May 17, 2017, 4:53:27 PM5/17/17
to
On Wednesday, May 17, 2017 at 6:45:38 AM UTC-5, Claus Aßmann wrote:
> Tim Mooney wrote:
>
> > I'm looking for a way to make sendmail prefer to use IPv4 when connecting to a remote MTA that is dual-stack
>
> 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.
Thanks Claus. I was afraid that might be the case.
> Tim Mooney wrote:
>
> > I'm looking for a way to make sendmail prefer to use IPv4 when connecting to a remote MTA that is dual-stack
>
> 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.
> > 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 ..."
> > The problem is that sendmail doesn't use getaddrinfo(); it still uses the older methods, so it ignores /etc/gai.conf
>
> Someone could submit a patch ...
> add a new compile time flag HASGETADDRINFO.
could get pretty complicated.
> > With all that said, is there some setting I've missed that will tell sendmail
> > to prefer to connect over IPv4, and only use IPv6 when it's the only option?
>
> Doesn't seem like it: another patch?
However, that option is probably also more complicated to implement than another sendmail-specific option.
Either way, thanks for the info Claus. It's appreciated.
Tim
G.W. Haywood
May 18, 2017, 2:01:01 PM5/18/17
to
Hi there,
On Wed, 17 May 2017, Claus Assmann wrote:
>> ... stat=Deferred: 450 4.7.26 Service does not accept messages sent
We're all going to be learning about IPv6 for a while.
One of the (new) problems is that you don't just get an IPv6 address,
you get at a _minimum_ a block of 2^64 addresses. We've had ONE IPv4
address for more than two decades. We managed. Imagine our surprise
when we applied to Hurricane Electric for a block of IPv6 addresses.
We got one block of 2^64 addresses (of which we are expected to use
exactly two, for the link to the HeNet servers) and one block of 2^80
addresses (of which we are currently using exactly three).
Now if we were spammers, and we only wanted to send say 2^32 messages
per day, we could send every one of those messages, every day, from a
different IPv6 address, for the next 771 billion years.
We do something similar to the redacted 'our-smtp-server' here too. :/
--
73,
Ged.
On Wed, 17 May 2017, Claus Assmann wrote:
>> ... 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.
> ...
>> SPF or DKIM validation (message not signed)
>
> Wow, really? I didn't see that requirement in any RFC.
We're all going to be learning about IPv6 for a while.
One of the (new) problems is that you don't just get an IPv6 address,
you get at a _minimum_ a block of 2^64 addresses. We've had ONE IPv4
address for more than two decades. We managed. Imagine our surprise
when we applied to Hurricane Electric for a block of IPv6 addresses.
We got one block of 2^64 addresses (of which we are expected to use
exactly two, for the link to the HeNet servers) and one block of 2^80
addresses (of which we are currently using exactly three).
Now if we were spammers, and we only wanted to send say 2^32 messages
per day, we could send every one of those messages, every day, from a
different IPv6 address, for the next 771 billion years.
We do something similar to the redacted 'our-smtp-server' here too. :/
--
73,
Ged.
Otto J. Makela
Oct 27, 2022, 8:46:17 AM10/27/22
to
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 <o...@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 * * * * * * */
> 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 ..."
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 <o...@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 * * * * * * */
Marco Moock
Oct 27, 2022, 8:54:14 AM10/27/22
to
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
> 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.
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?
Otto J. Makela
Oct 27, 2022, 9:18:12 AM10/27/22
to
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?
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.
Marco Moock
Oct 27, 2022, 9:37:22 AM10/27/22
to
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.
> Blocklists were a thing of the 2010's anyway, spammers these days seem
> to be fully functioning criminals who steal all resources they need.
Because Google doesn't care about this, same on Google Groups.
Henning Hucke
Oct 28, 2022, 2:37:43 AM10/28/22
to
Otto J. Makela <o...@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.
> 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.
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?
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.
Otto J. Makela
Oct 28, 2022, 3:15:34 AM10/28/22
to
Henning Hucke <h_hucke+...@newsmail.aeon.icebear.org> wrote:
> Otto J. Makela <o...@iki.fi> wrote:
>> Claus Aßmann
>> <ca+sendmail(-no-copies-please)@mine.informatik.uni-kiel.de> wrote:
> Otto J. Makela <o...@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.
>>
>>> ** 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
>> 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"?).
the sendmail code is built, I doubt trying to mess around with the
resolver will help in this case.
Claus Aßmann
Oct 28, 2022, 3:58:44 AM10/28/22
to
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
> Has any progress been made on the "prefer IPv4 connections" option over
> these 5 years?
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).
Marco Moock
Oct 28, 2022, 4:25:24 AM10/28/22
to
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.
<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).
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.
Andreas S. Kerber
Oct 28, 2022, 7:36:18 AM10/28/22
to
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
> 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).
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.
Claus Aßmann
Oct 28, 2022, 12:35:00 PM10/28/22
to
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 */
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 */
0 new messages