Re: issue warning for deferred emails

[Rob McGee]

On 2/20/2023 4:20 PM, Doug Denault wrote:

On Mon, 20 Feb 2023, Wietse Venema wrote:


Doug Denault:

The most current message (edited for privacy):

Feb 20 09:25:14 freeport postfix/qmgr[88969]: 7883F510EBC: 
from=, size=1943447, nrcpt=41 (queue active)
Feb 20 09:25:15 freeport postfix/smtp[67456]: 7883F510EBC: 
to=, relay=none, delay=329206,
  delays=329205/0.08/0.27/0, dsn=4.4.1, status=deferred (connect 
to mcahd.com[10.86.238.4]:25: Connection refused)


Where is the proof that the message actually had delay_warning_time on?

postcat -eq 7883F510EBC | grep warning_message_time


This was empty, because ...


lighthouse:/usr/local/etc/postfix> postconf -n


snip


delay_warning_time = 8h html_directory = /usr/local/share/doc/postfix


This indicates a typo in main.cf: no newline, or leading whitespace on 
the line for html_directory.  Prove it to yourself:


postconf delay_warning_time
--
   http://rob0.nodns4.us/

Re: issue warning for deferred emails

[Rob McGee]

On 2/20/2023 9:25 AM, Doug Denault wrote:

On Mon, 20 Feb 2023, Wietse Venema wrote:


Doug Denault:

On Sun, 19 Feb 2023, Viktor Dukhovni wrote:


On Sun, Feb 19, 2023 at 10:35:43PM -0500, Doug Denault wrote:


With my setup no warning is deferred errors such as 'time out' or
'Connection refused' until the message is delete from the queue.



snip


The most current message (edited for privacy):

Feb 20 09:25:14 freeport postfix/qmgr[88969]: 7883F510EBC: 
from=, size=1943447, nrcpt=41 (queue active)
Feb 20 09:25:15 freeport postfix/smtp[67456]: 7883F510EBC: 
to=, relay=none, delay=329206,
  delays=329205/0.08/0.27/0, dsn=4.4.1, status=deferred (connect to 
mcahd.com[10.86.238.4]:25: Connection refused)


The mailq output:

7883F510EBC 1943447 Thu Feb 16 13:58:29  i...@bcr-dc.com
    (connect to domain2.com[10.86.238.4]:25: Connection refused)
    some...@domain2.com


It appears that the real issue here may be a port 25 block placed by 
your provider. Postfix settings can't change that. You would have to 
contact your provider and ask to be unblocked.

--
   http://rob0.nodns4.us/

Re: Blocking TLDs

[Rob McGee]

On 2/8/2023 3:14 AM, Viktor Dukhovni wrote:

On Wed, Feb 08, 2023 at 10:00:14AM +0200, mailm...@ionos.gr wrote:


/\.top$/ REJECT
/\.xyz$/ REJECT
/\.cam$/ REJECT
/\.fun$/ REJECT
/\.buzz$/ REJECT
/\.club$/ REJECT
/\.link$/ REJECT
/\.hinet\.net$/ REJECT


Why everyone feels they need regular expressions for this is a mystery.

 /etc/postfix/sender-access:
 top REJECT I employ crude anti-spam measures
 .topREJECT I employ crude anti-spam measuressnip


Very good post as always, but there was a typo. Here's a regexp (!) to 
fix it:


s/crude/crude and ineffective/g

HTH :)

Those of you doing this should refer back to Viktor's previous post. 
This is a bad idea: it won't really do much against spam and could 
easily block non-spam. Again, none of these TLDs employ any tests to 
ensure that registrants are spammers.


Something I have noticed recently: many times the envelope and header 
sender addresses differ. It's an easy way for large-scale hosting 
operations to manage their own DKIM keys. I saw this with Amazon 
Workmail hosting.


Google Workspace hosting always uses the single account name as the 
envelope sender, so when multiple domains are configured in the same 
company account, each user always has the same envelope sender, 
regardless of the header sender.


Here's a rule of thumb: if you think you can do much about spam based on 
sender addresses, whether envelope or header: you're wrong.

--
   http://rob0.nodns4.us/

Re: Are non_smtpd_milters applied to mail delivered via smtpd?

[Rob McGee]

On 1/26/2023 1:44 AM, Matus UHLAR - fantomas wrote:


On 25.01.23 10:24, Matus UHLAR - fantomas wrote:

I forgot to mention I use amavisd-new because of these reasons.

To be more precise, when receiving mail from internet on port 25, I 
prefer amavisd-milter talking to amavisd so we can reject mail 
immediately, while clients from port 465/587 talk to amavisd-new using 
LMTP and amavisd-new injects mail back via LMTP on alternative port.


in some networks, even port 25 from LAN goes via LMTP to amavisd-new, 
and port 25 from the world is redirected onto other port with 
postscreen and milter.


I think it's best to wean users off the 20+year deprecated idea of using 
port 25 for submitting mail.


I should also add that if you want to avoid scanning of outgoing e-mail 
with spamass-milter, you can simply use its options "-I" that ignores 
all authenticated e-mail and "-i" that takes a list of networks from 
which mail is not scanned.


Also, I think it's a bad idea to give submitted mail a free pass. Very 
often this is what gets you listed on CBL / XBL, when MS Outlook malware 
is using valid credentials to spew.


But filtering needs differ for submission and MX mail. DNSBL checks on 
submission are useless. But URIBL content scanning is very effective.

--
   http://rob0.nodns4.us/

Re: Replacing initial "Received:" line on submission?

[Rob McGee]

On 1/13/2023 12:02 AM, Benny Pedersen wrote:

Jaroslaw Rafa skrev den 2023-01-12 21:52:

Dnia 12.01.2023 o godz. 13:49:33 post...@ptld.com pisze:

My solution...

main.cf:
    smtp_header_checks = pcre:/etc/postfix/header_checks_smtp


/etc/postfix/header_checks_smtp:
    /^Received:/   IGNORE
    /^X-Originating-Ip:/   IGNORE


If you do it in master.cf for submission services only, it my be OK. 


No, you can't set smtp_* options for smtpd(8) instances. You need 
another cleanup(8) instance and point to the cleanup_service_name in 
your options for submission.


https://www.postfix.org/postconf.5.html#cleanup_service_name


smtp_header_checks < is outbound
header_checks < is inbound


Yes, smtp_header_checks is for outbound only (controlling the behavior 
of the smtp(8) service.)


No, header_checks controls the cleanup service, and thus is applied 
globally, except where cleanup_service_name is pointing to a different 
cleanup instance.

--
   http://rob0.nodns4.us/

Re: parent_domain_matches_subdomains && smtpd_access_maps

[Rob McGee]

On 1/2/2023 1:38 PM, Laurent Frigault wrote:

Is there any way to have some smtpd_access_maps with
parent_domain_matches_subdomains and some other without it ?

I have :
smtpd_recipient_restrictions =
permit_mynetworks
 reject_non_fqdn_sender
 reject_unknown_sender_domain
 reject_unauth_destination
 check_sender_access hash:$config_directory/sender_access
 check_recipient_access hash:$config_directory/rcpt_recipient_access


I would like to have parent_domain_matches_subdomains in
rcpt_recipient_access and not in sender_access


The p_d_m_s setting is global per instance, but one thing you can do is 
unset it (remove smtpd_access_maps) and use the workaround to include 
subdomains of the parent as needed:


example.com target
.example.comtarget

Yes, it means using 2 entries for each domain where you want inclusion 
of subdomains, but it's not hard to automate adding all these to your 
existing map.

--
   http://rob0.nodns4.us/

Re: run script on new connection?

[Rob McGee]

On 12/26/2022 4:18 PM, mats wrote:

First statement: I'm new to Postfix
Second statement: I'm old enough that a 30mb harddrive was big then I started 
working with computers ..

The Challenge
I want to be able to run my own "idp" type script when someone tries to connect 
to my mailserver. Basically I want to refuse them even a tcp connection to smtpd if the 
connecting ip is in our internal blacklist.

I'm doing it today with an old HMailserver and it's very effective so I would 
like to port that functionality

Before someone says fail2ban so no, fail2ban is way to late since it requires 
log entries from smtpd. I want to kill them before they even get a chance to 
try and log on


There are numerous ways in addition to the ipset suggestions through 
which you could do this better than running a script at connect time. 
I'd simply publish my internal blocklist in DNS, using a DNSBL record 
format. To list IP address 192.0.2.1, your records would look like this:


1.2.0.192.blocklist.internal.   60  IN  A   127.0.0.1
60  IN  TXT "Reject message"

You'd query your local DNSBL with a reject_rbl_client smtpd(8) 
restriction, or better yet, in postscreen(8).


If you don't want to run/maintain your own DNSBL, publish your list in 
cidr_table(5) format and use a check_client_access restriction.


For sane ways to do what you want, see these:
http://www.postfix.org/SMTPD_ACCESS_README.html
http://www.postfix.org/POSTSCREEN_README.html

There's no sane way to have smtpd run a command on connection, nor 
should there be.

--
   http://rob0.nodns4.us/

Re: How to run a script on postfix authentication failure

[Rob McGee]

On 12/5/2022 10:03 AM, post...@ptld.com wrote:
Is there a way, in postfix, to run a script when the authentication 
fails, please ?
I would like to use nftables sets, with the timeout option, to ban IP 
addresses. I know fail2ban exists, but I am considering other options.
nftables sets, implemented in the kernel, with the timeout option, 
seem to be a great and very light option.


No, postfix itself can not. You can use a milter to read the headers 
looking for an authentication fail. The milter can run a shell command 
for the firewall.


But when authentication fails for submission, there are no headers. The 
mail is rejected at RCPT TO (or as otherwise configured.)


The way I do it, is I use omprog of rsyslog to process postfix logs with 
a script. The script can watch for log lines from opendmarc and run a 
shell command for the firewall when it finds a fail.


Both of these ways requires the ability to do script coding.


--
   http://rob0.nodns4.us/

uceprotect.wtf (was: Send email to one @domain.com via authenticated relay?)

[Rob McGee]

On 12/2/2022 3:27 PM, Joachim Lindenberg wrote:
UCEProtect are gangsters, even the founder admits: https://uceprotect.wtf/ > You don´t want to do anything about it, except you are located in 

Europe> and can complain to their customers and authorities violating GDPR.

Excuse me, Joachim, but did you look at uceprotect.wtf and think that 
site is in any way affiliated with the UCEPROTECT DNSBLs?


It is very clearly a parody, put up by someone else who falsely believed 
that a UCEPROTECT listing was the cause of email delivery problems. This 
person went to a lot of effort to portray Dirk Lautenschlager in the 
worst possible light.


It was not worth the effort!

Just ignore UCEPROTECT, as any serious email administrator does.

Being listed there will not cause any significant email problems. The 
only sites who use it are run by very inexperienced people and/or those 
who don't care about receiving email. That is to say, not serious sites.

--
   http://rob0.nodns4.us/

Re: Send email to one @domain.com via authenticated relay?

[Rob McGee]

On 12/3/2022 9:37 AM, John Stoffel wrote:

"Jim" == Jim Popovitch  writes:



On Fri, 2022-12-02 at 11:36 -0500, John Stoffel wrote:
I check, but I find my IP for mail.stoffel.org in the UCEPROTECT-3
spam list.  Nothing I can do about it.




I doubt that many sites block by using UCEPROTECH-3 alone, but you can
use www.whitelisted.org to be excluded from it.


I'm not going to pay those scum to get my IP whitelisted, that's just
blackmail.  How does paying some extortionate third party make my
email problems go away?


Like Jim said, it's very unlikely that a UCEPROTECT listing would be the 
cause of any delivery problems. Do you have some evidence that your 
target site (charter.net?) is using UCEPROTECT for blocking?


If so, please share that evidence. If not, assume your listing has 
nothing to do with your problem. It surely does not.



I'm going to be looking into the transport maps solution that I was
pointed to.


--
   http://rob0.nodns4.us/

Re: Is there an easy way to "warm up" a new sending IP w/ Postfix

[Rob McGee]

On 11/30/2022 12:42 AM, Sean Hennessey wrote:
I'm going to toy w/ that one tomorrow, I don't recall seeing in your 
original post though the plumbing to config postfix to use the postgress 
db. I was going to send a mail on that tomorrow, but while you are here 

As with everything in Postfix, it is documented:

https://www.postfix.org/PGSQL_README.html
https://www.postfix.org/pgsql_table.5.html
and see also:
https://www.postfix.org/DATABASE_README.html
--
   http://rob0.nodns4.us/

Re: postfix/cleanup logs

[Rob McGee]

On 11/15/2022 2:25 AM, Fourhundred Thecat wrote:

I have this option in master.cf for smtpd:

   -o cleanup_service_name=anonymize-sender-ip

and here it is defined:

   anonymize-sender-ip  unix  n -    n    -    0
  cleanup
   -o header_checks=regexp:/var/local/postfix/maps/anonymize-sender-ip

and in anonymize-sender-ip, I just replace my actual IP address with
127.0.0.1

Everything works fine, but every time I send email, postfix/cleanup logs
the replace operation in my log:

   postfix/cleanup: D62108F: replace: header Received: from 

I don't need this in my logs. Can I somehow disable log only for my
custom defined service "anonymize-sender-ip" ?


No log silencing feature has [yet] been implemented TTBOMK. There is of 
course the -v feature of grep(1):

   grep -v  /path/to/logfile | less
so you can only see what you want to see.

A couple other suggestions:
* -o syslog_name for this cleanup service can greatly ease and improve
  the grep (the syslog_name specified could be the expression)
* Even on a filesystem as small as that, you should consider
  enable_long_queue_ids:
  https://www.postfix.org/postconf.5.html#enable_long_queue_ids
--
   http://rob0.nodns4.us/

Re: How to verify that the Return-Path matches the From header

[Rob McGee]

On 11/14/2022 9:16 AM, wodel youchi wrote:
Some of my users got emails pretending to be from the admin, but looking 
into the source of these emails, the From header was modified to mislead 
the users, but the return-path still holds the real sender email address.


What is the best way to deal with this? Is it a good idea to match the 
 From header with the Return-path, if yes how?


If you did, you would break this, and every other mailing list.
--
   http://rob0.nodns4.us/

Re: how to differ the remote SMTP clients

[Rob McGee]

On 10/28/2022 7:44 AM, Jaroslaw Rafa wrote:

Dnia 28.10.2022 o godz. 20:40:44 Piperみかこ pisze:

What's the difference between these two options?

smtp_use_tls
smtpd_use_tls


The first one is for outgoing mail, the second one for incoming.


And BOTH are deprecated.

smtp(8) is for the SMTP client,
https://www.postfix.org/TLS_README.html#client_tls

smtpd(8) is for the SMTP server,
https://www.postfix.org/TLS_README.html#server_tls

Someone starting out in 2022 should not be using deprecated settings. 
Don't use random HOWTOs on the Internet, stick with the Postfix 
documentation.

--
   http://rob0.nodns4.us/

Re: Cannot resolve support@ alias

[Rob McGee]

On 10/25/2022 3:58 PM, Dominik George wrote:

I am facing a strange issue here, where I cannot resolve a virtual
alias with the local part support@.

I have a domain example.com in $virtual_mailbox_domains. The virtual
transport sends mail on to Dovecot. For virtual aliases, I use a basic
hash table, containing:

   i...@example.comn...@example.com
   supp...@example.com n...@example.com
   suppo...@example.comn...@example.com

The strange thing is that only the first and third aliases work. The
support@ alias is not resolved, Postfix just sends it on to Dovecot
with supp...@example.com as final recipient.


I suspect a subtle typo is at work. Try:
postmap -q supp...@example.com hash:/path/to/your/virtual_alias_map


Is there some special-casing for a support@ local poart of some kind?


No.

I am really lost here…-- 

   http://rob0.nodns4.us/

Re: comments in config files

[Rob McGee]

On 9/27/2022 2:00 AM, juan smitt wrote:

Can you please confirm that it won't cause any problem if we put
comments at the end of config lines?

Example:
file: /etc/postfix/virtual
postmaster  postmas...@example.com # this is a comment


https://www.postfix.org/virtual.5.html

See TABLE FORMAT

   blank lines and comments
  Empty  lines and whitespace-only lines are ignored, as
  are lines whose first non-whitespace character is a `#'.

That does not say you can put comments on the same line.
--
   http://rob0.nodns4.us/

Re: How to setup the secondary MX server

[Rob McGee]

On 9/15/2022 8:45 AM, I wrote:

The concept of "secondary MX" dates way back to pre-spam days. I think
it can safely be considered an outmoded idea at this point. But if you
insist on doing it, make sure that you use:
   * Recipient validation
   * Identical anti-spam controls on both hosts

 * And ensure that the Primary NEVER rejects anything forwarded from
   the Secondary
--
   http://rob0.nodns4.us/

Re: How to setup the secondary MX server

[Rob McGee]

On Wed, Sep 14 2022 at 07:10:57 PM +0800, Henrik Pang

 wrote:

Hello,

Is there a guide for adding a secondary MX with postfix?
the secondary MX would forward messages to the main MX.
When the main MX was in failure, the secondary MX should hold messages 
for some time.

On 9/14/2022 6:14 AM, Jonathan Sélea wrote:

Here you go:

https://www.howtoforge.com/postfix_backup_mx 


The first result on Google ;)


This is a perfect example of why NOT to use Google for your first resort
in asking questions! The linked howto is very bad, and it will make your
new secondary MX host a spam magnet.

The better advice is to reconsider the goal.

Why do you need this? If your primary MX host lacks reliability (could
be hardware, software, or Internet connectivity) your best bet is to
improve that reliability.

The concept of "secondary MX" dates way back to pre-spam days. I think
it can safely be considered an outmoded idea at this point. But if you
insist on doing it, make sure that you use:
  * Recipient validation
  * Identical anti-spam controls on both hosts
--
   http://rob0.nodns4.us/

Re: Milter vs. policy protocol

[Rob McGee]

On 2022-08-12 06:23, Dominik George wrote:

now that I have moved alias expansion to a socketmap service, I was
wondering what would be best for policy checks (for now, as simple as
"is address A allowed to send to address B?).

This os obviously possible using the milter, but then there is
Postfix' SMTP Access Policy Delegation.

When would I choose one over the other?


What it comes down to, mostly, is this: does your action require
access to the DATA payload (message headers and body) or not?

SPF, for example, does not, so SPF checking can be done in a policy
service.

DKIM (both signing and verification), OTOH, does. So DKIM actions
require a milter.

Rule of thumb, if you can do it in a policy service, choose that
over a milter. It's fast and lightweight.
--
  http://rob0.nodns4.us/

Re: Where to place spamhaus tests

[Rob McGee]

On 2022-08-08 03:09, Linkcheck wrote:

Thank you, but there never was an error in my resolver, which I
have not altered in any way.


Then the error is PEBKAC, in that you are not reading what people
have told you. Especially note the link to the Spamhaus FAQ about
query blocking and the 127.255.255.254 return code.

Of course your resolver is not returning an error; it is giving
you the answers you requested, through your upstream forwarders,
that I and others have told you that you must not use.


It was my own mistake in applying an incorrect dig. :(


There's really no such thing; dig will take just about any odd
combination of arguments and options that you can throw at it.

If you want to solve the problem you posted about, go back and
reread. The information is here. Good luck.
--
  http://rob0.nodns4.us/

Re: Where to place spamhaus tests

[Rob McGee]

On 2022-08-07 08:50, Linkcheck wrote:

On 07/08/2022 1:12 pm, Rob McGee wrote:

dig 2.0.0.127.zen.spamhaus.org. any


ANY has to be after DIG, not at the end, but...


Thank you for the correction. But as you have probably discovered
by now, my syntax was correct. In fact refer to the SIMPLE USAGE
section of "man dig"; my syntax was exactly as documented.



; <<>> DiG 9.10.3-P4-Ubuntu <<>> any 2.0.0.127.zen.spamhaus.org.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18750
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;2.0.0.127.zen.spamhaus.org.IN  ANY

;; ANSWER SECTION:
2.0.0.127.zen.spamhaus.org. 3579 IN A   127.255.255.254


This means you queried through a blocked resolver, as others have
mentioned.


;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Aug 07 14:34:59 BST 2022
;; MSG SIZE  rcvd: 71


And I use a local copy of Unbound for all DNS work.


This means that your local resolver is(was) using forwarders. The
forwarder is blocked, not you. Simply remove the forwarders from
your configuration and all should be well.

With your nameserver configuration fixed (as it seems to be from
another post in this thread), you might want to reconsider your
decision about not using Zen.

I recommend (in *addition* to the POSTSCREEN_README) this short
guide:
http://rob0.nodns4.us/postscreen.html
--
  http://rob0.nodns4.us/

Re: Where to place spamhaus tests

[Rob McGee]

On 2022-08-07 06:08, PGNet Dev wrote:

For reference, a couple of samples of the blocked emails are:

NOQUEUE: reject: RCPT from o4.email.wetransfer.com[192.254.123.89]: 
554 5.7.1 Service


I would add to the useful information below that neither sample is in
fact listed in Zen at this time.

YOU CANNOT USE DNSBL SERVICES THROUGH YOUR ISP RESOLVER.
YOU CANNOT USE DNSBL SERVICES THROUGH OPEN RESOLVERS (Google, et c.)

You must run a local resolver (such as BIND named(8), unbound(8) or
whatever) for your MTA to look up DNSBL records.

Show us the complete result of this command on your Postfix machine:
dig 2.0.0.127.zen.spamhaus.org. any

This will probably show us the "forbidden access" return codes. In
addition it will show the nameserver IP address you are using.


Zen list is an amalgam of XBL, PBL, SBL, SBLCSS & PBL blocklists

Data can be transient or delisted ... policy depends on the specific 
list.


What were the return codes for the rejections above -- at the time of 
rejection?


When did you *check* listings, relative to the rejection time stamps?

What is your 'postscreen_dnsbl_threshold' setting, and wow are you
scoring the individual spamhaus return-code ranges?

--
  http://rob0.nodns4.us/

Re: order of recipients in To, Cc, etc.

[Rob McGee]

On 2022-07-04 00:21, pat...@patpro.net wrote:

Few days ago I've stumbled on this gem:
https://twitter.com/gabsmashh/status/1542154330836553728


This is not a technical problem that can be fixed. The problem is the
manager and his/her personal insecurity. Email protocols make no
distinction in the social hierarchy of recipients.


It made me wonder about headers manipulation so I have few questions:


I would strongly suggest, just don't ask. If you find yourself in a
similar situation, try respectfully to explain it to the insecure
manager as best you can. And start updating your resume! Wouldn't be
a bad idea to put out some feelers about new employment.


- are you aware of email servers that can/will manipulate headers so
that recipients order is altered?
- would it be possible to randomize recipients order with some header
rewrite in Postfix?

--
  http://rob0.nodns4.us/

Re: How can I set a "Reply-To" header ?

[Rob McGee]

On 2022-06-30 23:41, Bob Proulx wrote:

Wietse Venema wrote:

White, Daniel E. (GSFC-770.0)[AEGIS]:
> I found out how to do it from command line:
>
> echo -e "Testing Mail\nThank you" | mailx -v -s "Testing Mail" -S 
"reply-to=yom...@example.com"  m...@example.com

This smells like a common webserver problem, where the webserver
submits email messages that appear to come from rhe web server's
UNIX account (www-ser...@example.com). Adding a Reply-To: header
is the WRONG solution for that. Instead, specify the correct
envelope sender address:

/usr/bin/sendmail -f yom...@example.com recipient


WDYT about using a canonical table to map www-d...@example.com to
desi...@example.com?  Then no Reply-To would be needed since the From:
address would be correct.


Of course this would only work in cases where only a single envelope
sender address is used.  In the case of a webmail client with multiple
users, it won't scale.  The better choice is to consult documentation
for that webmail and configure it to use sender addresses of logged-in
users.


For the OP:

http://www.postfix.org/ADDRESS_REWRITING_README.html#canonical

--
  http://rob0.nodns4.us/

Re: Rejecting mail from localhost.localdomain

[Rob McGee]

On 2022-06-26 21:23, Alex wrote:

Hi,
I was surprised to see I received an email with localhost.localdomain
as the envelope sender. It was a legitimate email, but not from my


This would have been stopped by
http://www.postfix.org/postconf.5.html#reject_unknown_sender_domain
(unless you have created "localhost.localdomain" as a valid record in
your local DNS, which there is no reason to do.)
--
  http://rob0.nodns4.us/

Re: Spamtrap email — milter that can still receive, but reject?

[Rob McGee]

On 2022-05-24 09:14, Dan Mahoney wrote:

Is there a milter of some sort that I can configure to reject (for
some to: addresses) at the end of DATA, but still forward the mail on?
 Im dealing with some deleted users who both got a lot of spam, but
also were in the critical path for things and I’m hoping the VERP
bounces trim some of this down.


Hi Dan,

I think the problem you will encounter is the feature:
smtpd_reject_unlisted_recipient.  You will have to "undelete" the
user before smtpd will accept their mail.  If the user does not
exist, a milter can't override the smtpd rejection.
--
  http://rob0.nodns4.us/

Re: Migrate mbox from 2.6.6 to 3.5.6

[Rob McGee]

On 2022-05-19 22:13, Phil Stracchino wrote:

On 5/19/22 19:25, Jim Garrison wrote:

I am migrating an ancient mail server running 2.6.6 to a new host
running postfix 3.5.6.  This is a simple setup with just a handful of
users and no complications like virtual mailboxes.

Simple question: Is it as easy as copying the /var/spool/mail/[user]
file and ~/mail directory to the new host for each user?  I.e. is the
mbox format used still the same, or will I run into incompatibilities?


Your main concern here is the proper ownership and permissions of the
relevant files and directories.


mbox is mbox is mbox.  The whole point of standards is that they are
standard.

(Of course, it's also said that the wonderful thing about standards is
that there are so many to choose from.)

Don't sweat it, it'll Just Work.


It's also perhaps worth mentioning that Postfix has nothing to to with
mail once it has been delivered.  This question should have been sent
to a mailing list for the unstated IMAP server.
--
  http://rob0.nodns4.us/

Re: zen.spamhaus.org suggestion in postifx main.cf

[Rob McGee]

On 2022-05-04 20:37, li...@lazygranch.com wrote:

Quad 9 uses a number of DNS servers with different names but I guess
that isn't good enough. I had set up unbound on the VPS used for my VPN
when I set up dnscrypt. I don't recall why I pulled it. I am going to
give systemd resolved a try. I suspect if it is a good replacement for
unbound it would be praised as such. But the install is a low effort so


It is not a replacement for unbound.  Just like dncrypt, it requires
you to use upstream forwarders, of the kind which Spamhaus and other
DNSBL services will block.


it is worth a shot.


Nope.

Unbound or BIND named will work.  The latter is as simple as clearing
out your distro-provided named.conf(5) file.  With default settings it
will do the external configuration you need.

The only configuration I'd recommend for named is:

options { listen-on { 127.0.0.1; }; listen-on-v6 { none; }; };

Remove resolv.conf or point it at "nameserver 127.0.0.1" and start
named.  That's it!

Of course unbound or pdns-recursor should be similarly easy, but I'll
leave that to their users to explain.

While configuration of DNS software is basically off topic here, you
cannot expect to run a modern MTA without it.
--
  http://rob0.nodns4.us/

Re: PIX workarounds incorrectly triggering?

[Rob McGee]

On 2022-05-02 04:42, Ole Laursen wrote:

I got a report that our Postfix server wasn't using TLS on outbound
connections, and looking in the log, it seems like I get a lot of PIX
workarounds with both gmail.com [1] and Microsoft's service:

  postfix/smtp[1243304]: 7BDFA6B7: enabling PIX workarounds:
disable_esmtp for aspmx.l.google.com [2][74.125.205.27]:25

I have not followed Postfix history, but it looks to me that the PIX
code is more than 20 years old and was introduced to handle old Cisco
firewalls. Surely that's not the the case for gmail.com [1] and
Microsoft? If I try telnetting the gmail.com [1] server, I get:


It is not the case for Google and Microsoft.  It is the case for YOU.


  telnet aspmx.l.google.com [2] 25
  Trying 74.125.205.26...
  Connected to aspmx.l.google.com [2].
  Escape character is '^]'.
  220
**

At the moment, I'm working around this by excluding disable_esmtp:


The only workaround is to get rid of or fix the PIX/ASA.

If your provider is doing this to you, complain.
--
  http://rob0.nodns4.us/

Re: Rewriting envelope-from of root mail (realname, not email address)

[Rob McGee]

On 2022-04-22 22:53, Viktor Dukhovni wrote:

On Fri, Apr 22, 2022 at 06:54:56PM -0700, Dan Mahoney wrote:
We *also* recently set sp=reject in dmarc.  Which presents us with a 
problem.


I have no advice re DMARC, never have or will use it.


Which indeed IS a word of advice. :)
--
  http://rob0.nodns4.us/

Re: Best way forwarding to Gmail

[Rob McGee]

On 2022-04-06 12:09, John Levine wrote:

It appears that Byung-Hee HWANG  said:
There is good guidance for forwarding? If it is on Gmail, is best 
option.


In my experience, forwarding to Gmail is an exercise in futility. I


My view is that if you want to use gmail, hire them to host mail for
your domain.

If you want to host your own mail, use IMAP, or console-based MUAs on
the mail server host.
--
  http://rob0.nodns4.us/

Re: Mail is being delivered to /var/mail/*user* instead of Maildir

[Rob McGee]

On 2022-04-07 01:25, Tan Mientras wrote:

On Wed, Apr 6, 2022 at 3:34 PM Wietse Venema 
wrote:


You have configured *the other Postfix* system to deliver mail with

virtual_transport = virtual (which is the default)

That uses virtual_mailbox_maps to locate mailboxes/maildirs.

But here, you have:

virtual_transport = local

This uses mail_spool_directory to locate mailboxes/maildirs.


IIUC, you are telling me to change local to virtual, in order to use
virtual_mailbox_maps, so vmailbox_result_format => Maildir.


"vmailbox_result_format" is not a setting, where did you see this
documented?

IMO it's pretty much always a misconfiguration to mix up your address
classes like this.

http://www.postfix.org/ADDRESS_CLASS_README.html


What drives me crazy is that this is actually working on Debian6.
Is this a buggy behaviour in debian 6 which actually works ok?


The bug is that you have yet to share any non-verbose logging that
shows the issue.

http://www.postfix.org/DEBUG_README.html#mail
--
  http://rob0.nodns4.us/

Re: Mail and mail traces lost (?)

[Rob McGee]

On 2022-03-30 07:32, Nikolaos Milas wrote:

It seems as if these mails are not delivered successfully, but I
cannot see them in any queue either.


Delivered mail is deleted from the Postfix queue.  It would have been
moved out of Postfix by some means, such as a delivery agent or an
external transport(5) like smtp(8).


How can I troubleshoot these? What may be going wrong?


syslog_name is your friend.  I noticed none of your log lines had any
syslog_name other than the default.

Postfix will have a default smtpd(8) instance (usually the one on 25,
listening for mail arriving from outside) and also a default smtp(8),
the client process delivering mail to external MX hosts.

Any OTHER instance of these should have a descriptive syslog_name set
in master.cf:
...   ...   ...   ...   smtpd
-o ...
-o syslog_name=postfix/whatever
-o ...
Where "whatever" describes the purpose of that listener or transport.

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

See also the sample master.cf as distributed in source code.
--
  http://rob0.nodns4.us/

Re: Why the name Postfix?

[Rob McGee]

On 2022-03-27 14:18, Viktor Dukhovni wrote:

This sounds plausible.  As for why "Postfix" and not, say,
"Platypus", I don't know.


Oh that's easy.  Same reason as why it's not called "Duckfix."

Wietse couldn't afford to pay the bill.
--
  http://rob0.nodns4.us/

Re: Firewall Ports

[Rob McGee]

On 2022-03-08 06:53, White, Daniel E. (GSFC-770.0)[NICS] wrote:

For a mail relay server running only Postfix,
I am making an educated guess that the only potentially needed open
ports would be 25, 465, 587, and 2525


25:   all mail exchange is exclusively done with connections to port 25
465:  submissions, authenticated mail submission using implicit TLS
  (RFC 8314)
587:  submission, authenticated mail submission using explicit TLS
  (plaintext is possible but usually not recommended)
2525: ?


(According to
https://sectigostore.com/blog/what-is-a-secure-smtp-ssl-port-heres-what-to-know-about-smtp-security/)


The author in March 2020 was unaware of RFC 8314 from January 2018.

Re: 2525, I don't know, but I would ask what providers are using it,
and why?  She mentions that it's in case of blocked port 587.  But
blocking 587 makes little sense.  Who is blocking 587, and why?  And
if so, why would they not also be blocking 2525?


No need to open imap(s) and/or pop3(s), right ?


You might need to open some of these on your IMAP server.
--
  http://rob0.nodns4.us/

Re: virtual_mailbox_maps & virtual_alias_maps

[Rob McGee]

On 2022-02-20 01:49, Phil Biggs wrote:

I have virtual_mailbox_maps in use with reject_unlisted
_recipent and use virtual_alias_maps to translate a
validated address into a single matching
address for the corresponding dovecot user. For example:

/usr/local/etc/postfix/vmailbox
validu...@example.com whatever

/usr/local/etc/postfix/vuser
validu...@example.com dovecotu...@example.com

In my case, these two tables will always match on the LHS.

Just wondering whether there any reason not to use the virtual
_alias table for both purposes?  It would make synchronisation with
the dovecot users DB just a little easier.

virtual_mailbox_maps = hash:/usr/local/etc/postfix/vuser
virtual_alias_maps = hash:/usr/local/etc/postfix/vuser


Seems to me that someone asking this is probably receiving mail for a
very small number of users and domains, and therefore, virtual(8)
mailbox delivery might not be the best choice.

http://www.postfix.org/BASIC_CONFIGURATION_README.html

local(8) delivery (to Unix system users) has many features lacking in
virtual mailbox delivery.  For example, ~.forward files and user
control of delivery of recipient_delimiter tagged mail.  I make
extensive use of this feature.

As for the question itself, keep in mind, virtual_mailbox_maps only
apply to domains in virtual_mailbox_domains, whereas virtual(5) alias
mapping is done for every address, regardless of class.  (Offer void
where taxed or prohibited, or in cases of receive_override_options
disabling address mapping.)


(Mail sent directly to dovecotu...@example.com should be rejected.)


That's actually a second question.  Two ways, basically.  You can
ensure the address does not exist in the recipient maps for your
chosen address class.  Or, you can use a check_recipient_access
restriction to reject for that address in smtpd(8).
--
  http://rob0.nodns4.us/

Re: Removing a user...

[Rob McGee]

On 2022-02-07 21:09, SH Development wrote:

The user in question was moved to another server on our network.  So,


This was not stated in the OP.


in effect, yes, I was sending to the removed user on another server.

I have sent to the “moved” user from an outside address and it
works as expected.

I believe the issue is that when I send a test email, the moved user
was on the same server and therefore considered local.  Somehow,
postfix still thinks the user is on the old server even though I have
removed all references to it that I am aware of.


It sounds like you are trying to share one domain's hosting among
two or more servers.  This is not a trivial thing to do.

One way to do it is with per-address transport_maps, routing each
address to the correct server.  You are not doing this.

Another way to do it is with Dovecot director, and likewise, I see
no evidence of this.

If, as it appears (STILL without logs and complete config as per
DEBUG_README.htkl#mail), you have simply assigned each server the
authority of the domain in virtual_mailbox_domains, users on one
server will not be able to contact users on the other one[s].  And
mail from outside will be playing Russian roulette: delivered if
the correct server is reached, rejected otherwise.

How big is this operation?  How many thousands of users, how many
domains?  If as I suspect, you're not that big, YDIW.  Just go with
a single server and make your life easier.
--
  http://rob0.nodns4.us/

Re: Removing a user...

[Rob McGee]

On 2022-02-07 13:25, SH Development wrote:

We have a postfix/dovecot/mysql configuration.  We recently removed
one of the users from the database, however when we send email, it
still looks like the address we are sending to is a local address


You're sending mail to the address you removed?


and bounces with a “no such user” error.


Is this a problem?  Is this not what you intended?  Did you try
sending to the removed address from outside, e.g., from a free mail
provider?


I have tried restarting both postfix and dovecot with no change in
the problem.


That would also be expected.


Do we maybe need to get rid of the actual vmail box file?


Cannot affect what Postfix does.


Is there a cache or something that needs to be cleared?


Maybe.  You did not show the logs of this.
--
  http://rob0.nodns4.us/

Re: smtpd in master.cf

[Rob McGee]

On 2022-01-22 21:53, Ruben Safir wrote:

Sorry not main, in master

On Sat, Jan 22, 2022 at 10:51:31PM -0500, Ruben Safir wrote:

Is this an error?

smtp  inet  n   -   n   -   -   smtpd


"smtp" is the port name.  It's 25.
"getent services smtp"


submission inet n   -   n   -   -   smtpd


"submission" is the port name.  It's 587.
"getent services submission"


 -o syslog_name=postfix/submission
 -o smtpd_tls_security_level=encrypt
 -o smtpd_sasl_auth_enable=yes
 -o smtpd_sasl_auth_enable=yes
 -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject

Are they both defining smtpd and listening on 587?


Yes, no.
--
  http://rob0.nodns4.us/

Re: GhettoForge Postfix3

[Rob McGee]

On 2022-01-19 01:00, jdebert wrote:

On Tue, 18 Jan 2022 17:13:32 -0500
post...@ptld.com wrote:



Wait, so its a fork of Postfix?


It is not.  It was intended to be a way for Red Hat / derivate users
to be able to have up-to-date Postfix features.  Users' needs are
being actively addressed here, in the upstream project, but not in
Red Hat Enterprise Linux.


And not the same code as what Wietse releases for the same version?


To my knowledge, it is the same code, unpatched.


It's whatever the maintainer of that code wants, intends, etc.

Why not ask the maintainer?


The maintainer is on this list, but due to time zones and perhaps
personal circumstances has not been able to reply yet.  You can also
find him in irc.libera.chat/#postfix as "pj".
--
  http://rob0.nodns4.us/

Re: Can i run postfix on my home IP

[Rob McGee]

On 2022-01-12 21:45, Fred Morris wrote:

If you've got a static IP and there's no games being played, it should
work as long as the connection is "always on" and accepts connections
(SYN) on port 25 from the outside world. -- FWM

On Thu, 13 Jan 2022, Yamadaえりな wrote:


I have got a DSL from the ISP, having a static IP.
Can I run postfix with this IP for accepting email for my own domain?


Fred and Richard are of course correct, but you are very likely to
have problems sending mail from a residential IP netblock.  See if
you're on PBL:
  https://www.spamhaus.org/pbl/

If your ISP will set a custom PTR record for your IP address, you
can remove yourself from PBL.  If not, you can possibly receive at
your home IP address, but you would have to relay outbound through
a VPS.  Or, upgrade to business-class service from your ISP.  Most
often a VPS is cheaper.
--
  http://rob0.nodns4.us/

Re: method to discard email with body containing gmail address

[Rob McGee]

On 2021-11-06 06:15, li...@lazygranch.com wrote:

Most of my spam contains a gmail address to reply to the spammer. I
would like to discard email whose body contains a gmail address. Since
discarding mail could get ugly, I would hope someone on the list can
eyeball my plan.


Indeed it is ugly.  You just as well could have asked for a method
to throw out the baby with the bathwater!


I added
body_checks = pcre:/etc/postfix/body_checks
to main.cf. I made a null body_checks file and ran postmap on it, then


postmap "compiles" hash: and other indexed map types.  It's not
needed for a pcre_table(5) map.


did a reload & restart. Postfix wouldn't send email if the file was
missing.

postconf -d mail_version
mail_version = 3.6.2

Trawling the internet I found this regix to match gmail addresses:
^[\w.+\-]+@gmail\.com$

So if body_checks contained
/^[\w.+\-]+@gmail\.com$/ DISCARD
work.


Change DISCARD to WARN first, to see what it matches.

Also, you anchored the expression on both ends, ^ and $, so you're
only going to match mail with ONLY the gmail address on one line.
This line with zeixsgw9gufv2isophpdyisr0bgz0...@gmail.com will not
match.  Neither will this, with the <> enclosing brackets:


I think once you get the bugs worked out you will give up on this.

See my postscreen howto for a much more effective means of dealing
with spam.
--
  http://rob0.nodns4.us/

Re: logwatch sending to r...@subdomain.domain.com

[Rob McGee]

On 2021-07-07 08:50, Mike Hughes wrote:

 I just noticed that we have a bunch of undeliverable messages piling
up in the queue. I have root defined in aliases for another address,
which works when sending to r...@domain.com. However, since the FQDN
in main.cf is defined as host.subdomain.domain.com it's appending the
whole string.

 What's the most stable way to encourage everything to go to
r...@domain.com instead?


This may or may not be a Postfix question; you did not share enough
information for us to know.

It could be that logwatch is sending mail with a bare localpart,
"root", in which case your Postfix answer is $myorigin:

http://www.postfix.org/postconf.5.html#myorigin
http://www.postfix.org/BASIC_CONFIGURATION_README.html

Or, it could be that your distribution configured mailx(1) or similar
to send mail as localp...@hostname.example.com.  You could know by
checking your logs and consulting your logwatch/mailx/distro
documentation.
--
  http://rob0.nodns4.us/

Re: AW: Milter-Reject

[Rob McGee]

On 2021-06-18 09:16, Maurizio Caloro wrote:

Adding the hostname and/or IP here or exist and other thing that
this mail will be deliver for first try?
postscreen_access_list = permit_mynetworks,


You seem to be confused.

Your postscreen settings have no bearing on what smtpd does with a
message.  You can accept/permit something in postscreen, but if
smtpd or a milter later rejects it, it's rejected.


hash:/etc/postfix/whitelistIP


Also, hash: maps are discouraged for postscreen_access_list.  But I
think we should focus on the actual issue here, and stop chasing
after irrelevant things.

A "permit" in postscreen simply means that the client connection is
handed off to smtpd.  Nothing more.
--
  http://rob0.nodns4.us/

Re: Postfix stable release 3.6.0

[Rob McGee]

On 2021-04-30 02:18, @lbutlr wrote:

On 29 Apr 2021, at 17:05, Wietse Venema  wrote:

   This release requires "postfix stop" before updating, or before
   backing out to an earlier release, because some internal protocols
   have changed. Otherwise, long-running daemons (pickup, qmgr,
   verify, tlsproxy, postscreen) may fail to communicate with the
   rest of Postfix, causing mail delivery delays until Postfix is
   restarted.


This seems to be contradicting itself. Do we have to stop postfix
before updating, or do we have to restart postfix after updating?

Restarting postfix is much faster than than stopping it, installing
the update, and then starting, so I wold prefer to restart if will
work.


Perhaps you are confused because of your distributor's abstraction of
postfix(1) commands?  There is no "postfix restart" command.  There is
[among others] reload, start, and stop.  You need to do whatever
translates to "postfix stop" and then "postfix start".  (And yes, use
"postfix start-fg" if that's what your OS requires.)
--
  http://rob0.nodns4.us/

Re: Clients Sending Phantom Email

[Rob McGee]

On 2021-04-28 11:28, Asai wrote:

We are getting reports, more and more, of email clients (Type App, Mac
Mail, iOS Mail) that seem to send email, and show that the email has
been sent on the client, but the mail server has no record of email
ever reaching the SMTP service, nor does it even seem that the client
is connecting to the server.

Can someone advise as to what area of debugging we can turn on?


You can't.  If the non-verbose logs don't show the connection coming to
you, the verbose logs won't have it either, and they will just obscure
the relevant bits in a whole lot of noise.


There's a lot of info in debugging, and we can't turn it all on at
once, so we could use some specifics.

Thanks for your insights here.


No logs mean you should double-check your DNS and firewall, as well as
your syslogd and/or other logging mechanism.  For syslog daemons,
logger(1) is your friend.
--
  http://rob0.nodns4.us/

Re: Postfix : corrupted SMTP transactions?

[Rob McGee]

On 2021-04-15 21:02, Bill Cole wrote:

On 15 Apr 2021, at 18:23, Rob McGee wrote:


Being pedantic, however, I'd suggest using the IANA and RFC 8314
port name, "submissions",


It would be good to first confirm and/or fix what is in the
/etc/services file on the system in question before making that
change. See the man pages for master(5) and getservbyname(3).


Of course.  But IANA has already made the change in the upstream
services(5) file, so in due time the use of "smtps" possibly
will stop working.
--
  http://rob0.nodns4.us/

Re: REDIRECT overrides always_bcc

[Rob McGee]

On 2021-04-16 12:03, Dominic Raferd wrote:

I have started using a REDIRECT action in a header_checks table
which works but seems to prevent always_bcc from operating -
the email is not bcc'd.


It's ugly, but a possible workaround: REDIRECT to an address which
runs a script (transport_maps entry to a pipe(8) or to a local(8)
address with a ~/.forward), and the script delivers a copy to your
BCC address by some means.

It's ugly, but the idea of redirecting based on a header is also
ugly. :)
--
  http://rob0.nodns4.us/

Re: Postfix : corrupted SMTP transactions?

[Rob McGee]

On 2021-04-15 03:10, Matus UHLAR - fantomas wrote:
On 14 Apr 2021, at 15:55, (lists) Denis BUCHER 
 wrote:

smtps  inet  n   -   -   -   -   smtpd
-o syslog_name=postfix/smtps
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject


On 14.04.21 23:28, @lbutlr wrote:

Seems short.


Not much, maybe only missing wrappermode.

Being pedantic, however, I'd suggest using the IANA and RFC 8314
port name, "submissions", because that's more specific and
correct than "smtps", which name implies that it might be a
substitute port for smtp, 25.


smtps  inet  n   -   n   -   -   smtpd
   -o smtpd_sasl_auth_enable=yes
   -o smtpd_tls_wrappermode=yes


The following all properly belong in main.cf, even if this is the
only submission service you're running.  But as Matus points out,
typically you'd also offer RFC 6409 submission on 587.


   -o smtpd_sasl_type=dovecot
   -o smtpd_sasl_security_options=noanonymous
   -o smtpd_sasl_path=private/auth


And the following can be implemented with mua_mumble_restrictions
all defined in main.cf; this is the default offered in the
commented smtps and submission commented entries in master.cf as
distributed by Wietse:


   -o smtpd_client_restrictions=permit_sasl_authenticated,reject
   -o 
smtpd_relay_restrictions=permit_sasl_authenticated,reject_unauth_destination,reject
   -o 
smtpd_recipient_restrictions=permit_sasl_authenticated,reject_unauth_destination,reject

   -o smtpd_helo_restrictions=
   -o smtpd_data_restrictions=


If any of those mua_*_restrictions are not set you get "".  The only
one really required is mua_relay_restrictions, but the default
smtpd_relay_restrictions even avoids that requirement.  So the
smtpd_client_restrictions=permit_sasl_authenticated,reject will at
least require all submitting clients to AUTH.

tls_wrappermode=yes is required for smtps to actually work as 
expected,

as well as, I believe, sasl_type?


you should better put sasl options to main.cf, unless you are going to
use different SASL types on different ports.


--
  http://rob0.nodns4.us/

Re: How to delivery all incoming mails to 2 backend mail servers

[Rob McGee]

On 2021-04-08 13:44, Clifford Gonsalves wrote:

The servers are 1 Exchange and 1 Zimbra.

Can this work?
1: First server delivery via transport map.
2: Second delivery via address rewrite (recipient _bcc maps ) then
transport map to the rewritten address.
3: At Zimbra rewrite address again and delivery to local mailbox.

The solution is only required for incoming emails from the Internet.


What's still missing here is the ultimate goal: why do you want
this?

If you want to have a "hot spare" mail store, you're in the wrong
place.  You would implement that in the IMAP server.  See, a user
mailbox is not read-only, it's read-write.  Users make changes all
the time; not just deleting mail, but also reading it.  Those read
and replied (and other) tags are stored along with the mail.  If
your user reads something in Exchange, how is Dovecot to know?

If you simply want another copy, that can be done with a pcre_ or
regexp_table of recipient_bcc_maps.  Suppose the first server gets
the mail, make a copy for the other:

(.*)\@() $1.$2@second.server

and "second.server" is another transport_maps entry.
--
  http://rob0.nodns4.us/

Re: warning: dnsblog_query lookup error

[Rob McGee]

On 2021-04-08 09:12, Benny Pedersen wrote:

On 2021-04-08 15:56, Matus UHLAR - fantomas wrote:

On 2021-04-08 14:16, Matus UHLAR - fantomas wrote:
in addition to this, you can whitelist outlook's IP ranges at 
postscreen
level, as they "likely" aren't what postscreen is supposed to stop - 
bots.


On 08.04.21 15:31, Benny Pedersen wrote:
there is bots at microsoft, there servers try port 465, and 587 
randomly, no mta would do this


no sane person runs postscreen at 465/587 ports.


it does not change abusers ips


Whitelisting in postscreen only affects postscreen itself, not any other
ports nor services.

http://www.postfix.org/postconf.5.html#postscreen_access_list
--
  http://rob0.nodns4.us/

Re: 450 4.3.2 - Postscreen

[Rob McGee]

On 2021-04-07 11:57, Maurizio Caloro wrote:

Today I have activate postscreen on mailserver, now one email will now
reject but I understood that this

Will be delivered after some time….. "this are like in waiting"


Depends.  There are some transactional mail senders which do not
retry.


Apr  7 18:49:36 ail postfix/postscreen[32484]: NOQUEUE: reject: RCPT
from [40.92.73.101]:47169: 450 4.3.2 Service currently unavailable;
from=jemes.c...@hotmail.com, to=mauri...@domain.ch, proto=ESMTP,
helo=


Microsoft's outbound server farm certainly WILL retry.  I do not
know, however, if they will retry from the same IP address.


Please how long will this action take, or its possible to shorting
this time?


That's entirely up to the sending client.  Most should retry in a
matter of minutes.

The delay can be avoided if the sending client is whitelisted, and
indeed all the Microsoft outbound farm hosts are listed in
list.dnswl.org's whitelist.


Or I need to understood more about this postrscreen?


You definitely do.

You should not have enabled the after-220 tests before you
understand what they do and what they cost you.

http://www.postfix.org/POSTSCREEN_README.html is the primary
reference.

http://rob0.nodns4.us/postscreen.html is my own configuration.  It
includes an example of the aforementioned whitelist feature
( 
http://www.postfix.org/postconf.5.html#postscreen_dnsbl_whitelist_threshold 
).

--
  http://rob0.nodns4.us/

Re: Display relevant message-id for all postfix log lines

[Rob McGee]

On 2021-04-07 09:25, sandeep pawar wrote:

I am using multiple postfix mta instance for internal relaying
purpose. I am sending postfix logs to ELK and was wondering if it
would be possible to display message-id in each log line. This
could help in various kind of searches.


Note that the message body does not exist until the SMTP DATA
command has completed.  (Yes, headers are included here.)  So
anything logged before DATA cannot know the Message-Id: header.


Is there any configuration which can be tweaked to for custom
logging.


Not that I know of, and the above limitation is unavoidable in
Postfix.  Your workaround would be some script to post-process
your logs.
--
  http://rob0.nodns4.us/

Re: problem connecting from Outlook Android

[Rob McGee]

On 2021-04-03 11:55, @lbutlr wrote:

On 01 Apr 2021, at 12:31, DEPRÉ Gaëtan - NGServers.com
 wrote:
mua_client_restrictions = permit_mynetworks, 
permit_sasl_authenticated, reject
mua_relay_restrictions = reject_non_fqdn_recipient, 
reject_unknown_recipient_domain, permit_mynetworks, 
permit_sasl_authenticated,reject


I know your problem with smtps is solved, but I noticed that you are
allowing unauthenticated my networks to submit mail.

This is not a good idea and opens you up to poorly written or


Agreed.


malicious local scripts. You should require authentication for ANYONE
sending mail out from your machine, even if they are a script on
localhost.

I don't know why you are using mua_* but that's a different issue.


mua_mumble_restrictions are the default for submission and smtps
(submissions) in recent master.cf examples.  The idea is, override
each smtpd_mumble_restrictions stage in master.cf, so if you add
some new restrictions for port 25, submission/submissions are not
affected.  Note that if mua_client_restrictions (or whatever) are
not set, you get " -o smtpd_client_restrictions=", empty, which is
probably what you want.

It also makes it easy to set whatever submission-only restrictions
you might want.

I do think these examples might be better documented, along with a
README to explain why it's a good idea to require AUTH for all
submission.  If someone nags me enough I might try to start a first
draft thereof. :)
--
  http://rob0.nodns4.us/

Re: inet_protocols

[Rob McGee]

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/