inet_protocols

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

inet_protocols

Michael Grimm-2
Hi,

is inet_protocols 'order sensitive'?

What I mean is, does postfix follow the order of the following settings:

        inet_protocols = ipv4, ipv6
        inet_protocols = ipv6, ipv4

Would the latter definition tell postfix to try ipv6 first and ipv4 second?

Thanks and regards,
Michael
Reply | Threaded
Open this post in threaded view
|

Re: inet_protocols

Viktor Dukhovni
> On Apr 1, 2021, at 8:40 AM, Michael Grimm <[hidden email]> wrote:
>
> Is inet_protocols 'order sensitive'?

No.

> What I mean is, does postfix follow the order of the following settings:
>
> inet_protocols = ipv4, ipv6
> inet_protocols = ipv6, ipv4

No.

> Would the latter definition tell postfix to try ipv6 first and ipv4 second?

No.  See: http://www.postfix.org/postconf.5.html#smtp_balance_inet_protocols

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: inet_protocols

Michael Grimm-2
On 1. Apr 2021, at 14:45, Viktor Dukhovni <[hidden email]> wrote:
>> On Apr 1, 2021, at 8:40 AM, Michael Grimm <[hidden email]> wrote:

>> Is inet_protocols 'order sensitive'?
>
> No.
[..]
> No.  See: http://www.postfix.org/postconf.5.html#smtp_balance_inet_protocols

Thanks for your clarification and regards,
Michael
Reply | Threaded
Open this post in threaded view
|

Re: inet_protocols

Wietse Venema
Michael Grimm:

> On 1. Apr 2021, at 14:45, Viktor Dukhovni <[hidden email]> wrote:
> >> On Apr 1, 2021, at 8:40 AM, Michael Grimm <[hidden email]> wrote:
>
> >> Is inet_protocols 'order sensitive'?
> >
> > No.
> [..]
> > No.  See: http://www.postfix.org/postconf.5.html#smtp_balance_inet_protocols
>
> Thanks for your clarification and regards,
> Michael

You can specity a preference with:

http://www.postfix.org/postconf.5.html#smtp_address_preference

However, if you don't support IPv4 or IPv6, then the way to go is
to remove the unsupported protocol from inet_protools.

        Wuetse
Reply | Threaded
Open this post in threaded view
|

Re: inet_protocols

Michael Grimm-2
Wietse Venema <[hidden email]> wrote:
> Michael Grimm:
>> On 1. Apr 2021, at 14:45, Viktor Dukhovni <[hidden email]> wrote:
>>>> On Apr 1, 2021, at 8:40 AM, Michael Grimm <[hidden email]> wrote:

>>>> Is inet_protocols 'order sensitive'?
>>>
>>> No.

> You can specity a preference with:
>
> http://www.postfix.org/postconf.5.html#smtp_address_preference

Great, that's what I was looking for (and didn't find, sorry).

> However, if you don't support IPv4 or IPv6, then the way to go is
> to remove the unsupported protocol from inet_protools.

My mailserver supports IPv4 and IPv6.

Background of my question:

One of the bigger email providers in Germany (t-online.de = TOL) started to block my IPv4 address. I do assume that this has to do with being blocklisted (see  http://www.uceprotect.net/en/rblcheck.php?ipr=135.125.211.209), although my IP address isn't blacklisted but the subnet it is member of.

I checked for my IPv6 address, and it isn't blacklisted. Thus I tried to bypass TOL's blocking by using IPv6 until I will have been whitelisted by them (what happened in the meantime). FTR: It wouldn't have worked because TOL's mailservers are IPv4 only.

But it is good to know that smtp_address_preference might help me with other ISP blocking my IPv4.

Thank you very much and with kind regards,
Michael

Reply | Threaded
Open this post in threaded view
|

Re: inet_protocols

Viktor Dukhovni
> On Apr 1, 2021, at 12:02 PM, Michael Grimm <[hidden email]> wrote:
>
>
> But it is good to know that smtp_address_preference might help me with other ISP blocking my IPv4.

For such cases I use the transport table:

  master.cf:
    smtp unix ... smtp
    smtp4 unix ... smtp -o inet_protocols=ipv4
    smtp6 unix ... smtp -o inet_protocols=ipv6

  transport:
    # IPv6 slow or rejected by exampl4.net
    example4.net smtp4
    # IPv4 slow or rejected by example6.net
    example6.net smtp6

This does not require any changes in global defaults.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: inet_protocols

Jaroslaw Rafa
In reply to this post by Michael Grimm-2
Dnia  1.04.2021 o godz. 18:02:19 Michael Grimm pisze:
>
> One of the bigger email providers in Germany (t-online.de = TOL) started
> to block my IPv4 address. I do assume that this has to do with being
> blocklisted (see
> http://www.uceprotect.net/en/rblcheck.php?ipr=135.125.211.209), although
> my IP address isn't blacklisted but the subnet it is member of.

Nobody should use UCEPROTECT blacklist to block mail. They recently started
to blacklist a lot of huge networks and request a fee for delisting. There
has been recent discussion on "mailop" mailing list regarding UCEPROTECT
practices and basically everybody agreed that it isn't a reliable blacklist
and they can't be trusted.
--
Regards,
   Jaroslaw Rafa
   [hidden email]
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
Reply | Threaded
Open this post in threaded view
|

Re: inet_protocols

Phil Stracchino
On 4/1/21 12:38 PM, Jaroslaw Rafa wrote:

> Dnia  1.04.2021 o godz. 18:02:19 Michael Grimm pisze:
>>
>> One of the bigger email providers in Germany (t-online.de = TOL) started
>> to block my IPv4 address. I do assume that this has to do with being
>> blocklisted (see
>> http://www.uceprotect.net/en/rblcheck.php?ipr=135.125.211.209), although
>> my IP address isn't blacklisted but the subnet it is member of.
>
> Nobody should use UCEPROTECT blacklist to block mail. They recently started
> to blacklist a lot of huge networks and request a fee for delisting. There
> has been recent discussion on "mailop" mailing list regarding UCEPROTECT
> practices and basically everybody agreed that it isn't a reliable blacklist
> and they can't be trusted.

Time was SORBS filled that role.  They were completely out of control
and once on their blacklists, you couldn't get off.


--
  Phil Stracchino
  Babylon Communications
  [hidden email]
  [hidden email]
  Landline: +1.603.293.8485
  Mobile:   +1.603.998.6958
Reply | Threaded
Open this post in threaded view
|

Re: inet_protocols

Matus UHLAR - fantomas
In reply to this post by Jaroslaw Rafa
>Dnia  1.04.2021 o godz. 18:02:19 Michael Grimm pisze:
>> One of the bigger email providers in Germany (t-online.de = TOL) started
>> to block my IPv4 address. I do assume that this has to do with being
>> blocklisted (see
>> http://www.uceprotect.net/en/rblcheck.php?ipr=135.125.211.209), although
>> my IP address isn't blacklisted but the subnet it is member of.

On 01.04.21 18:38, Jaroslaw Rafa wrote:
>Nobody should use UCEPROTECT blacklist to block mail. They recently started
>to blacklist a lot of huge networks and request a fee for delisting. There
>has been recent discussion on "mailop" mailing list regarding UCEPROTECT
>practices and basically everybody agreed that it isn't a reliable blacklist
>and they can't be trusted.

using their L2 and L3 lists shouldn't be used as exclusive spam signs, but
their L1 list should be quite reliable.

Their L2 and L3 are just indicators that IP comes from problematic source
(e.g. spam-friendly company/ISP or company/isp who doesn't care).

postscreen is here to handle multiple listings.

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I feel like I'm diagonally parked in a parallel universe.
Reply | Threaded
Open this post in threaded view
|

Re: inet_protocols

Jaroslaw Rafa
Dnia  2.04.2021 o godz. 13:41:40 Matus UHLAR - fantomas pisze:
>
> using their L2 and L3 lists shouldn't be used as exclusive spam signs, but
> their L1 list should be quite reliable.
>
> Their L2 and L3 are just indicators that IP comes from problematic source
> (e.g. spam-friendly company/ISP or company/isp who doesn't care).

L2 and L3 lists are exactly the problem. They recently changed rules for
these and now list almost everyone there ;)
--
Regards,
   Jaroslaw Rafa
   [hidden email]
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
Reply | Threaded
Open this post in threaded view
|

Re: inet_protocols

Rob McGee
In reply to this post by Michael Grimm-2
On 2021-04-01 11:02, Michael Grimm wrote:
> Background of my question:
>
> One of the bigger email providers in Germany (t-online.de = TOL)
> started to block my IPv4 address. I do assume that this has to do with
> being blocklisted (see
> http://www.uceprotect.net/en/rblcheck.php?ipr=135.125.211.209),
> although my IP address isn't blacklisted but the subnet it is member
> of.

You do wrongly assume this.  T-online.de is not using UCEProtect
for blocking mail.  Hardly anyone in the world is doing so, save
some over-eager hobbyists who learn how to use a DNSBL and think
they need to add as many DNSBLs as possible.

> I checked for my IPv6 address, and it isn't blacklisted. Thus I tried
> to bypass TOL's blocking by using IPv6 until I will have been
> whitelisted by them (what happened in the meantime). FTR: It wouldn't
> have worked because TOL's mailservers are IPv4 only.
>
> But it is good to know that smtp_address_preference might help me with
> other ISP blocking my IPv4.

You're much more likely to encounter delivery problems on v6 than
on v4.
--
   http://rob0.nodns4.us/
Reply | Threaded
Open this post in threaded view
|

Re: inet_protocols

Benny Pedersen-2
In reply to this post by Viktor Dukhovni
On 2021-04-01 18:17, Viktor Dukhovni wrote:

>  master.cf:
>     smtp unix ... smtp
>     smtp4 unix ... smtp -o inet_protocols=ipv4
>     smtp6 unix ... smtp -o inet_protocols=ipv6
>
>   transport:
>     # IPv6 slow or rejected by exampl4.net
>     example4.net smtp4
>     # IPv4 slow or rejected by example6.net
>     example6.net smtp6
>
> This does not require any changes in global defaults.


is it not

example6.net smtp6:
example4.net smtp4:

is : optional ?

or is both working, i use the later
Reply | Threaded
Open this post in threaded view
|

Re: inet_protocols

Benny Pedersen-2
In reply to this post by Rob McGee
On 2021-04-02 21:52, Rob McGee wrote:

> On 2021-04-01 11:02, Michael Grimm wrote:
>> Background of my question:
>>
>> One of the bigger email providers in Germany (t-online.de = TOL)
>> started to block my IPv4 address. I do assume that this has to do with
>> being blocklisted (see
>> http://www.uceprotect.net/en/rblcheck.php?ipr=135.125.211.209),
>> although my IP address isn't blacklisted but the subnet it is member
>> of.
>
> You do wrongly assume this.  T-online.de is not using UCEProtect
> for blocking mail.  Hardly anyone in the world is doing so, save
> some over-eager hobbyists who learn how to use a DNSBL and think
> they need to add as many DNSBLs as possible.

t-online blocks #metoo

i have just added t-online.de to rpz, no more problem

>> I checked for my IPv6 address, and it isn't blacklisted. Thus I tried
>> to bypass TOL's blocking by using IPv6 until I will have been
>> whitelisted by them (what happened in the meantime). FTR: It wouldn't
>> have worked because TOL's mailservers are IPv4 only.
>>
>> But it is good to know that smtp_address_preference might help me with
>> other ISP blocking my IPv4.
>
> You're much more likely to encounter delivery problems on v6 than
> on v4.

freebsd have an ipv6 only kernel, big problems :=)
Reply | Threaded
Open this post in threaded view
|

Re: inet_protocols

Jaroslaw Rafa
Dnia 11.04.2021 o godz. 14:43:27 Benny Pedersen pisze:
>
> t-online blocks #metoo

FYI, t-online is often discussed on "mailop" mailing list as their criteria
for rejecting e-mails are sometimes unusual.

For example they may block IP addresses that didn't successfully send mail
to them previously, and you may need to request to manually unblock the
address via their contact form.

Besides requirement on matching FcrDNS, which is quite common, they also
require that WHOIS for the IP address must contain an abuse e-mail address.

They also recommend in their sender guidelines (although it is not said that
they require that, but in fact it is possible that they do) that "the host's
domain leads to a website providing full contact details".

They also warn against using sender address verification on messages that
come *to you from their domain* - using that probably may get you blocked by
them. Sending bounces to them (eg. in case of non-existing address), or too
large number of their SMTP rejections on messages you send to them may also
get you blocked.

Their full sender guidelines can be found at
https://postmaster.t-online.de/index.en.html#t4

Plus they announced recently on the "mailop" list that they will start to
check DKIM on incoming e-mails (not DMARC, only DKIM, and they will of
course do it in a non-standard way), and will reject all e-mails that:
a) are NOT DKIM signed and come freom senders that they "do not have
established contacts with" (read: you can send a non-DKIM signed mail if you
are eg. Google or Microsoft :))
b) the envelope From domain, the header From domain and the DKIM From domain
do not match (all three must match, which will probably reject mails from
most mailing lists)

They are... well, just strange, doing everything differently.
--
Regards,
   Jaroslaw Rafa
   [hidden email]
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
Reply | Threaded
Open this post in threaded view
|

Re: inet_protocols

Benny Pedersen-2
In reply to this post by Jaroslaw Rafa
On 2021-04-02 13:44, Jaroslaw Rafa wrote:

> Dnia  2.04.2021 o godz. 13:41:40 Matus UHLAR - fantomas pisze:
>>
>> using their L2 and L3 lists shouldn't be used as exclusive spam signs,
>> but
>> their L1 list should be quite reliable.
>>
>> Their L2 and L3 are just indicators that IP comes from problematic
>> source
>> (e.g. spam-friendly company/ISP or company/isp who doesn't care).
>
> L2 and L3 lists are exactly the problem. They recently changed rules
> for
> these and now list almost everyone there ;)

paid delist is imho not acceptable

sorbs also imho had this before

sorry if it was another blocklist
Reply | Threaded
Open this post in threaded view
|

Re: inet_protocols

Matus UHLAR - fantomas
In reply to this post by Jaroslaw Rafa
On 11.04.21 18:18, Jaroslaw Rafa wrote:
>FYI, t-online is often discussed on "mailop" mailing list as their criteria
>for rejecting e-mails are sometimes unusual.
>
>For example they may block IP addresses that didn't successfully send mail
>to them previously, and you may need to request to manually unblock the
>address via their contact form.
>
>Besides requirement on matching FcrDNS, which is quite common, they also
>require that WHOIS for the IP address must contain an abuse e-mail address.

the old rfc-ignorant.org dnsbl did have ipwhois list that contained those
blocks.

>They also recommend in their sender guidelines (although it is not said that
>they require that, but in fact it is possible that they do) that "the host's
>domain leads to a website providing full contact details".
>
>They also warn against using sender address verification on messages that
>come *to you from their domain* - using that probably may get you blocked by
>them. Sending bounces to them (eg. in case of non-existing address), or too
>large number of their SMTP rejections on messages you send to them may also
>get you blocked.

the old rfc-ignorant org contained "dsn" blocklist containing those servers.
now, rfc-clueless does that job now afaik.

>Their full sender guidelines can be found at
>https://postmaster.t-online.de/index.en.html#t4
>
>Plus they announced recently on the "mailop" list that they will start to
>check DKIM on incoming e-mails (not DMARC, only DKIM, and they will of
>course do it in a non-standard way), and will reject all e-mails that:
>a) are NOT DKIM signed and come freom senders that they "do not have
>established contacts with" (read: you can send a non-DKIM signed mail if you
>are eg. Google or Microsoft :))
>b) the envelope From domain, the header From domain and the DKIM From domain
>do not match (all three must match, which will probably reject mails from
>most mailing lists)

some mailing lists fix these, but only if the original domain is DKIM-signed.

yes, seems like they are going to miss mail from parts of the world.

>They are... well, just strange, doing everything differently.

looks like they are going to stop communicating with part of the world.


--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
- Have you got anything without Spam in it?
- Well, there's Spam egg sausage and Spam, that's not got much Spam in it.