different setup for different ports

[Helmut K. C. Tessarek]

I'd like to use a dnsbl list, but when setting the following in my
sendmail.mc

FEATURE(`dnsbl',`zen.spamhaus.org')dnl

the dnsbl is used for incoming mails on port 25 *AND* also on port 465
(which only allows relaying/sending when authenticated anyway) when
sending mails.

In my opinion there's a huge difference between receiving mails on port
25 and relaying/submitting mails on port 465. However, sendmail does not
seem to make a distinction.

The same is true for something like:

INPUT_MAIL_FILTER(`spamassassin', ......)

Yea, of course I want spamassassin to run when a mail arrives at port
25, but I don't really want it to run when sending an email.
sendmail still runs the filter though (I know there are options in the
milter to not scan when sending a mail, but I'm talking about sendmail
here).

Anyway, is there any chance that I can use the dnsbl list for arriving
mails, but not for people who authenticate on port 465 to send mails?

Cheers,
K. C.

--
regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/

[Grant Taylor]

On 02/04/2018 01:39 PM, Helmut K. C. Tessarek wrote:
> In my opinion there's a huge difference between receiving mails on port
> 25 and relaying/submitting mails on port 465. However, sendmail does
> not seem to make a distinction.

Yes there is a distinction and I believe that it is possible to get
Sendmail to act like there is one too.

> INPUT_MAIL_FILTER(`spamassassin', ......)

Use MAIL_FILTER and then define the InputMailFilters option in the
DAEMON_OPTIONS statement.

Include your spamassassin filter in your port 25 MTA daemon and don't
include it in your port 465 SMTPS daemon.

> Anyway, is there any chance that I can use the dnsbl list for arriving
> mails, but not for people who authenticate on port 465 to send mails?

I think there is a way to get Sendmail to not apply RBLs to
authenticated connections. It may be related to the delay_checks FEATURE.

I'm sure that Claus will reply with more details.



--
Grant. . . .
unix || die

[Helmut K. C. Tessarek]

Thanks for the reply.

On 2018-02-04 17:34, Grant Taylor wrote:
> Use MAIL_FILTER and then define the InputMailFilters option in the
> DAEMON_OPTIONS statement.

How would I do that? (Sorry, I setup my sendmail years ago - at which
point I bought a sendmail book that I read - but I don't speak sendmail
these days.)

> Include your spamassassin filter in your port 25 MTA daemon and don't
> include it in your port 465 SMTPS daemon.

Same as above. How? (This is exactly what I'm looking for. Adding a
feature/filter/whatnot to a certain daemon, thus port.)

Well, the spamassassin part is not that important to me, since I can
configure the milter.

The part I really need is how to apply a feature to a certain port.
I used dnsbl as an example, because I actually use it, so solving this
would help me greatly.

However, generally speaking there must be a way so that a
feature/filter/whatnot only applies to a certain port or daemon.

How does someone configure sendmail, so that certain things are only run
for incoming mail, but not for mail that is sent?

> I think there is a way to get Sendmail to not apply RBLs to
> authenticated connections.  It may be related to the delay_checks FEATURE.

I think I've looked into delay_checks a while back but it doesn't apply
to the issue I'm trying to solve. Or maybe I misunderstood delay_checks.

[Andrzej Adam Filip]

"Helmut K. C. Tessarek" <tess...@evermeet.cx> wrote:
> I'd like to use a dnsbl list, but when setting the following in my
> sendmail.mc
>
> FEATURE(`dnsbl',`zen.spamhaus.org')dnl
>
> the dnsbl is used for incoming mails on port 25 *AND* also on port 465
> (which only allows relaying/sending when authenticated anyway) when
> sending mails.
>
> In my opinion there's a huge difference between receiving mails on port
> 25 and relaying/submitting mails on port 465. However, sendmail does not
> seem to make a distinction.
>
> The same is true for something like:
>
> INPUT_MAIL_FILTER(`spamassassin', ......)
>
> Yea, of course I want spamassassin to run when a mail arrives at port
> 25, but I don't really want it to run when sending an email.
> sendmail still runs the filter though (I know there are options in the
> milter to not scan when sending a mail, but I'm talking about sendmail
> here).
>
> Anyway, is there any chance that I can use the dnsbl list for arriving
> mails, but not for people who authenticate on port 465 to send mails?

AFAIR The classic suggestion is to use FEATURE(`delay_checks').
It moves DNSBL checks from "MAIL FROM:" reply to "RCPT TO:" reply.
As a side effects it turns off the checks for authenticated users.

You can do a lot more if you are ready to "program in sendmail.cf".

--
[Andrew] Andrzej A. Filip - https://www.linkedin.com/in/andfil

[Helmut K. C. Tessarek]

On 2018-02-05 01:21, Andrzej Adam Filip wrote:
> It moves DNSBL checks from "MAIL FROM:" reply to "RCPT TO:" reply.

This is not what I want.

There must be a way so that a feature/filter/whatnot only applies to a

certain port or daemon.

How does someone configure sendmail, so that certain things are only run
for incoming mail, but not for mail that is sent?

> As a side effects it turns off the checks for authenticated users.

This seems like yet another workaround. I'm looking for a real solution
to a real use case: configure sendmail to run a feature/filter for a
certain daemon only.

[Claus Aßmann]

Helmut K. C. Tessarek wrote:

> There must be a way so that a feature/filter/whatnot only applies to a
> certain port or daemon.

It's called "rules". You can write them -- check the docs.

> How does someone configure sendmail, so that certain things are only run
> for incoming mail, but not for mail that is sent?

See above.

> This seems like yet another workaround. I'm looking for a real solution
> to a real use case: configure sendmail to run a feature/filter for a
> certain daemon only.

"filter":
Did you check the fine documentation?

DaemonPortOptions=options
....
InputMailFilters List of input mail filters for the daemon


Or here is a really simple solution:
use different daemons for each port with their own configuration.



--
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.

[Helmut K. C. Tessarek]

Thanks for the reply.

On 2018-02-05 20:06, Claus Aßmann wrote:
> It's called "rules". You can write them -- check the docs.

Awesome, good to know. I will check my sendmail book for the topic "rules".

However, isn't there a simple example somewhere? ;-)

> Or here is a really simple solution:
> use different daemons for each port with their own configuration.

Hmm, I thought about that, but I don't think it's very simple.

First I thought of just creating 2 /etc/mail directories and 2 sendmail
systemd services. But I wouldn't know what to remove from one and add to
the other, so that one is only for port 25 and the other is only for
port 465.

[Grant Taylor]

On 02/04/2018 08:57 PM, Helmut K. C. Tessarek wrote:
> Thanks for the reply.

You're welcome.

> How would I do that? (Sorry, I setup my sendmail years ago - at which
> point I bought a sendmail book that I read - but I don't speak sendmail
> these days.)

I have my SpamAssassin milter defined with the following in the
sendmail.mc file:

MAIL_FILTER(`SpamAssassin', `S=unix:/var/run/spamass/spamass.sock')dnl

I then have my SpamAssassin milter included on my MTA DAEMON_OPTIONS line:

DAEMON_OPTIONS(`Family=inet, Address=192.0.2.1, Name=PublicMTA4,
Port=smtp, InputMailFilters=SpamAssassin, M=A')dnl

> Same as above. How? (This is exactly what I'm looking for. Adding a
> feature/filter/whatnot to a certain daemon, thus port.)

See above.

> Well, the spamassassin part is not that important to me, since I can
> configure the milter.

I'm not quite sure what you mean by "not important … configure the
milter". You still have to have Sendmail use the milter.

I'm saying include the SpamAssassin milter in the InputMailFilters on
the MTA, and don't put it on your SMTPS port.

> The part I really need is how to apply a feature to a certain port.

You use different DAEMON_OPTIONS to specify how each port behaves and
what filters are applied to it.

> I used dnsbl as an example, because I actually use it, so solving this
> would help me greatly.
>
> However, generally speaking there must be a way so that a
> feature/filter/whatnot only applies to a certain port or daemon.

Yes, DAEMON_OPTIONS is the Sendmail way of doing it.

> How does someone configure sendmail, so that certain things are only
> run for incoming mail, but not for mail that is sent?

Incoming implies the public MTA port. Mail that is sent can be a few
different things, but usually originates from localhost or authenticated
clients. Both of the later tend to use a different port. Thus you can
apply different settings based on the DAEMON_OPTION configuration for
said ports.

> I think I've looked into delay_checks a while back but it doesn't apply
> to the issue I'm trying to solve. Or maybe I misunderstood delay_checks.

Why do you think delay_checks feature does not apply?

My understanding of the delay_checks feature is that it allows you to
insert different parameters to influence how various filtering is done.
I.e. don't apply some filters to authenticated users, and apply them to
incoming SMTP (TCP port 25).

I'm going to defer to Claus for more details.

[Grant Taylor]

On 02/05/2018 08:15 PM, Helmut K. C. Tessarek wrote:
> However, isn't there a simple example somewhere?

I've often found that to be somewhat of a problem with Sendmail. Many
pages tell you how to do something without really telling you what the
various things do.

Check the reply I just sent for some examples.

> First I thought of just creating 2 /etc/mail directories and 2 sendmail
> systemd services. But I wouldn't know what to remove from one and add
> to the other, so that one is only for port 25 and the other is only for
> port 465.

I think running two instances of Sendmail is non-trivial. You will also
need separate /var/spool/mqueue and /var/spool/mqueue-client directories
too.

I'm not convinced that you actually need two separate daemons to do what
I think you're trying to do. - I think that proper DAEMON_OPTIONS will
cover most of what you want. You /may/ need to throw AccessDB in to
tweak some things.

[Helmut K. C. Tessarek]

On 2018-02-06 00:00, Grant Taylor wrote:
> I've often found that to be somewhat of a problem with Sendmail.  Many
> pages tell you how to do something without really telling you what the
> various things do.

Yep, that's why RTFM doesn't really work with sendmail - at least most
of the time.

[Claus Aßmann]

Grant Taylor wrote:

> I think running two instances of Sendmail is non-trivial. You will also
> need separate /var/spool/mqueue and /var/spool/mqueue-client directories
> too.

That depends on how you want to treat the queues. If you have one
"MTA" and one "MSA" then you need only one queue for each.

[Claus Aßmann]

Helmut K. C. Tessarek wrote:

> First I thought of just creating 2 /etc/mail directories and 2 sendmail
> systemd services. But I wouldn't know what to remove from one and add to
> the other, so that one is only for port 25 and the other is only for
> port 465.

The fine instructions explain the two DaemonPortOptions fairly well...

For example:
no_default_msa Don't generate the default MSA daemon, i.e.,
DAEMON_OPTIONS(`Port=587,Name=MSA,M=E')
To define a MSA daemon with other parameters, use this
FEATURE and introduce new settings via DAEMON_OPTIONS().

[Helmut K. C. Tessarek]

On 2018-02-06 14:14, Claus Aßmann wrote:
> The fine instructions explain the two DaemonPortOptions fairly well...

Unfortunately the fine documentation does not tell me how to add a
feature as a daemon option. Nor does it tell me how to reference
features with the same name (e.g. 2 dnsbl lists).

Please, I asked a pretty specific question.

How to add this:

FEATURE(`dnsbl',`zen.spamhaus.org')dnl

to the daemon on port 25, but not to the daemon on port 465.

The answer is probably 2 simple/short lines in sendmail.mc, if you know
how to do it. I've alrady explained that I do not know how to make it
work and that's why I posted in comp.mail.sendmail in the first place.

(If I knew how to do it, it would take me 45 seconds to find the stuff
in my sendmail.mc and copy'n paste it here.)

Referring to documentation which does not tell me what I want, does not
help me. If the documentation told me what I wanted, do you think I'd be
asking in a newsgroup?

Cheers,
K. C.

P.S.: I'm sorry, if my words sounded harsh or unfriendly (which was not
my intention), but I don't understand why people can't just answer a
question without deflecting.

[Claus Aßmann]

Helmut K. C. Tessarek wrote:

> On 2018-02-06 14:14, Claus Aßmann wrote:
> > The fine instructions explain the two DaemonPortOptions fairly well...

> Unfortunately the fine documentation does not tell me how to add a
> feature as a daemon option. Nor does it tell me how to reference

If it's not documented, then it's not supported.

> How to add this:

> FEATURE(`dnsbl',`zen.spamhaus.org')dnl

> to the daemon on port 25, but not to the daemon on port 465.

You can't do this with the standard features.

[Grant Taylor]

On 02/05/2018 10:30 PM, Helmut K. C. Tessarek wrote:
> Yep, that's why RTFM doesn't really work with sendmail - at least most
> of the time.

I've found that RTFM (as in man pages) doesn't really work well for a
lot of things.

Rather the FM (et al) are very good references after you have learned
things and need to look something up for a syntax check.

If you have a vague idea of what you're wanting and need to (re)read a
section to find specifics, FMs are usually okay.

I also find that many How-Tos are too heavy on wrote process and too
light on what they are doing.

If I need to learn something cold, I am usually in for a long slog
through lots of documentation until things finally start to click.

The other option that I've found effective is haunting mailing lists and
newsgroups.

[Helmut K. C. Tessarek]

On 2018-02-05 23:56, Grant Taylor wrote:
> I have my SpamAssassin milter defined with the following in the
> sendmail.mc file:
>
> MAIL_FILTER(`SpamAssassin', `S=unix:/var/run/spamass/spamass.sock')dnl
>
> I then have my SpamAssassin milter included on my MTA DAEMON_OPTIONS line:
>
> DAEMON_OPTIONS(`Family=inet, Address=192.0.2.1, Name=PublicMTA4,
> Port=smtp, InputMailFilters=SpamAssassin, M=A')dnl

Ah, I see. My setup looks like this:

INPUT_MAIL_FILTER(`spamassassin',
`S=unix:/var/run/spamass-milter/spamass-milter.sock, F=,
T=C:15m;S:4m;R:4m;E:10m')dnl

DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl
DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s')dnl

Therefore spamassassin is used for both.

I like your solution much better. Thanks for the tip.

>> Same as above. How? (This is exactly what I'm looking for. Adding a
>> feature/filter/whatnot to a certain daemon, thus port.)
>
> See above.

Hmm, unfortunately I don't see how this works for a feature, like dnsbl.
DAEMON_OPTIONS only seems to support the MAIL_FILTER directive.

>> Well, the spamassassin part is not that important to me, since I can
>> configure the milter.
>
> I'm not quite sure what you mean by "not important … configure the
> milter".  You still have to have Sendmail use the milter.

See above. The INPUT_MAIL_FILTER is used for both daemons and I'm using
-I in /etc/sysconfig/spamass-milter to not scan outgoing mail.

As mentioned before - your solution is much nicer.

> I'm saying include the SpamAssassin milter in the InputMailFilters on
> the MTA, and don't put it on your SMTPS port.

Yep, very elegant solution. Thanks !!!

>> The part I really need is how to apply a feature to a certain port.
>
> You use different DAEMON_OPTIONS to specify how each port behaves and
> what filters are applied to it.

It looks like this only works for filters not for features. :-(

[Helmut K. C. Tessarek]

On 2018-02-06 19:39, Claus Aßmann wrote:
>> How to add this:
>> FEATURE(`dnsbl',`zen.spamhaus.org')dnl
>> to the daemon on port 25, but not to the daemon on port 465.
> You can't do this with the standard features.
>

Wow, ok, now I'm truly astounded. Any technically inclined person would
agree that receiving mails and sending mails (after authentication) are
2 distinct things. Yet, sendmail does not make this distinction - at
least not when it comes to features it seems.

So basically I have to use something other than sendmail to achieve such
a simple thing as to apply a feature to a single daemon (or a
combination of features mapped to receiving and sending). I'm speechless.

I can't be the only person in the world who ever wanted to do this or
thought that this was a valid use case.

Ah, well. I guess I shouldn't try so hard to keep sendmail on my server.

[Claus Aßmann]

Helmut K. C. Tessarek wrote:

> Wow, ok, now I'm truly astounded. Any technically inclined person would
> agree that receiving mails and sending mails (after authentication) are
> 2 distinct things. Yet, sendmail does not make this distinction - at
> least not when it comes to features it seems.

"Any technically inclined person would" know that every mail is
first received and then send out.
Doing one without the other is not really possible...
(yes, there are corner cases, but that's not what an MTA is about).
So your only difference is "authentication".

> So basically I have to use something other than sendmail to achieve such
> a simple thing as to apply a feature to a single daemon (or a
> combination of features mapped to receiving and sending). I'm speechless.

I'm sure you will find an MTA that magically matches your needs.

> I can't be the only person in the world who ever wanted to do this or
> thought that this was a valid use case.

Geez, I'm wondering how all the other people using sendmail
handle this... Maybe by one of the many suggested ways?


Good Bye.

[Helmut K. C. Tessarek]

On 2018-02-07 14:49, Claus Aßmann wrote:
> "Any technically inclined person would" know that every mail is
> first received and then send out.
> Doing one without the other is not really possible...
> (yes, there are corner cases, but that's not what an MTA is about).
> So your only difference is "authentication".

I beg to differ. The receiving part is done by 2 different daemons (in
my case). So is the sending part (well, ok, that also depends).

If a mail arrives from the outside, it is received by port 25 and then
sent by the LDA (I don't even use sendmail's LDA, but dovecot's`).
If a mail is sent via port 465, it is first received by the daemon on
port 465 and then sent.

While all mails are technically received and sent, they are not handled
by the same processes, thus there should be a way to configure features
for a daemon.

>> So basically I have to use something other than sendmail to achieve such
>> a simple thing as to apply a feature to a single daemon (or a
>> combination of features mapped to receiving and sending). I'm speechless.
> I'm sure you will find an MTA that magically matches your needs.

Well, after a bit of googling it seems that postfix handles this better.

After hours and hours of searching the Internet, I hadn't found a single
article on how to apply a feature to smtp, but not to smtps.
Thus my post to this newsgroup.

>> I can't be the only person in the world who ever wanted to do this or
>> thought that this was a valid use case.
> Geez, I'm wondering how all the other people using sendmail
> handle this... Maybe by one of the many suggested ways?

According to you it is not even possible.

Currently the only "way" to do this seems to be to run 2 sendmail
configurations in parallel (as you suggested).
This is not a solution, but a workaround for a lack of functionality.
Or am I wrong (about the lack of functionality)? Are there other solutions?

I also read up on rules, but I couldn't find a way to use rules to do
what I want.

I've been using sendmail for more than 20 years and there was a time,
when I was not bad in configuring this thing. sendmail was and might
still be very powerful.

However, applying one or more dnsbls (or any other thing that is
implemented as a feature), should be as easy as:

FEATURE(`Port=smtp', `dnsbl',`zen.spamhaus.org')dnl

or

FEATURE(`Port=smtps', `accept_unresolvable_domains')dnl

But it isn't. Nor does it seem to be possible. Which I call a lack of
functionality. End of story.

[Claus Aßmann]

Helmut K. C. Tessarek wrote:

> According to you it is not even possible.

Wrong.
It is not possible with the standard features.
It is trivial when you follow the fine instructions
and use the Local_check_* extensions.

and maybe even this might be sufficient for your specific (DNSBL) request:

By using FEATURE(`delay_checks') the rulesets check_mail and check_relay
will not be called when a client connects or issues a MAIL command,
respectively. Instead, those rulesets will be called by the check_rcpt
ruleset; they will be skipped if a sender has been authenticated using
a "trusted" mechanism, i.e., one that is defined via TRUST_AUTH_MECH().

(check the rules to see how it's done...)

> However, applying one or more dnsbls (or any other thing that is
> implemented as a feature), should be as easy as:

> FEATURE(`Port=smtp', `dnsbl',`zen.spamhaus.org')dnl

So why don't you write this functionality and make it available?
Just like someone donated the enhdnsbl feature.
It's open source after all.


BTW: why should a feature be "per port"? Why not per authentication
mechanism, strength of the encryption layer, client name, or some
combination of those?

[Helmut K. C. Tessarek]

On 2018-02-07 21:15, Claus Aßmann wrote:
> It is trivial when you follow the fine instructions
> and use the Local_check_* extensions.

If it is so trivial, why don't you give me an example how to use feature
`blabla' on port `portX'?

> and maybe even this might be sufficient for your specific (DNSBL) request:
>
> By using FEATURE(`delay_checks') the rulesets check_mail and check_relay
> will not be called when a client connects or issues a MAIL command,
> respectively. Instead, those rulesets will be called by the check_rcpt
> ruleset; they will be skipped if a sender has been authenticated using
> a "trusted" mechanism, i.e., one that is defined via TRUST_AUTH_MECH().
>
> (check the rules to see how it's done...)

Yes, I will look into this as well and I agree it might solve my DNSBL
list issue.

But I was more interested in a general solution to use feature `blabla'
on port `portX'. The DNSBL feature was only an example.

>> However, applying one or more dnsbls (or any other thing that is
>> implemented as a feature), should be as easy as:
>> FEATURE(`Port=smtp', `dnsbl',`zen.spamhaus.org')dnl
> So why don't you write this functionality and make it available?
> Just like someone donated the enhdnsbl feature.
> It's open source after all.

This is not a bad idea. Unfortunately I'm not a sendmail expert and I
assume that it would be some macro template for the "real" cf stuff.

Before I have to write and/or extend the cf file manually, I'd rather
flogg myself using a whip with barbed wire as tails while hanging upside
down from my testicles.

> BTW: why should a feature be "per port"? Why not per authentication
> mechanism, strength of the encryption layer, client name, or some
> combination of those?

No reason, mainly because for DNSBL it made sense to use port. I used a
general example to show how the FEATURE macro (or however you call the
construct) _could_ and _should_ work.

FEATURE(`Client=x, Auth=B, Port=smtps', `blabla', `parameter1', ...)dnl

I'd be all for a FEATURE construct capable of doing this.