Transport to non-standard external port

[Daniel Miller]

I am setting up to use a service from an external company that utilizes 
SMTP for messaging via a non-standard port. So to be clear - this is 
*not* for standard mail!


Given a recipient address in the form "s123...@example.com", and I'm 
given the IP and port, do I just need to define an entry in my transport 
map? E.g.:


s123...@example.com 1.2.3.4:5525

Do I need to define anything for relay_domains or anything else?


Separate question - since my own server is *not* an open relay and only 
permits authorized users, how do I allow that external address to either 
be used as the sender (which I'd rather not) or re-write my authorized 
sender for the relay?


--
Daniel

Re: Suggestions for submission protection

[Daniel Miller]

On 9/22/2019 12:59 PM, Bill Cole wrote:

On 20 Sep 2019, at 17:12, Daniel Miller wrote:

I'm seeing some higher levels of attempted logins from various 
sources. Are there any automated filters that are suggested?


The Spamhaus SBL and XBL are safe for use on submission ports, as is the 
Surriel 'PSBL.' It's possible for innocent infectees to get listed on 
those DNSBLs or to coincidentally get a dynamic IP formerly held by an 
infected device, but that is a manageable problem. Fail2ban is also 
useful against credential-stuffer attacks.


Definitely helpful - thank you.



Or do I simply add a check_client_a_access and reference a manually 
maintained blacklist?


If you do use a manual local blacklist for this (as I do on my personal 
system) it is most useful to apply it at the network level: either in 
your router/firewall or in a host-local packet filter (e.g. iptables, 
ipfw, etc) because rejecting auth attempts at the application level is 
relatively heavy compared to dropping SYNs. If your user population is 
relatively small and homogeneous (e.g. a family or small business mail 
system) you can block *almost* all of the Internet from port 587 and 465 
with no damage. Even if you need to support "road warrior" users who 
might log in from anywhere in the world, there are still some very large 
networks that host lots of credential-stuffers and no legitimate mail 
submission or IMAP users than can be blocked safely to good effect: AWS, 
Azure, GCP, Digital Ocean, etc.




I totally concur that if an IP deserves blocking for one service it 
generally does so for all - anyone attempting to brute-force any service 
on my server has no need to ever touch it again.


Is there a "simple" table of such "credential-stuffer" network addresses 
I can load on my router for blocking?


--
Daniel

Re: Suggestions for submission protection

[Daniel Miller]

On 9/22/2019 8:24 AM, Dominic Raferd wrote:

On Sat, 21 Sep 2019 at 01:21, Wietse Venema  wrote:


Benny Pedersen:

Daniel Miller skrev den 2019-09-20 23:12:


I'm seeing some higher levels of attempted logins from various
sources. Are there any automated filters that are suggested? Or do I
simply add a check_client_a_access and reference a manually maintained
blacklist?

[...]


I use fail2ban with dovecot jail and a custom 'postfix-auth' jail (see
https://github.com/fail2ban/fail2ban/issues/2200), both of which block
a lot of repeated auth attempts. I also harvest attempted passwords
and relay them (filtered) to the relevant users.



This was *very* helpful - thanks!

Daniel

Re: Question getting Mail.app working with PostFix SMTP

[Daniel Miller]

On 9/21/2019 9:23 PM, John Dale wrote:
Ugh .. still having trouble getting apple's mail client to work with 
postfix SMTP settings.


I'm not seeing anything in the logs that I can make sense of:

[...]

Explain it to me like I'm five, please .. what are the SMTP settings 
that I need to be most concerned with for this authentication portion.


In the mail server world I'm going on six myself but I'll give it a shot.

To begin with you need to start small - get things working with a test 
server with a minimum of restrictions and then tweak one item at a time 
until you have at least some comfort level of what that does.


First, some terms as I understand them. Hopefully someone will correct 
me if I'm providing too much misinformation.


MUA - Mail User Agent - Client. Thunderbird, Mail.app, and others. These 
programs talk to MTA's and expect the MTA to transport mail to a 
destination. Local, remote, virtual, or whatever the next concept might be.


MTA - Mail Transfer Agent - Server. MTA's like Postfix *transfer* 
messages between...various sources & destinations. A source can be a 
MUA. It can also be another MTA - local or remote. The destination can 
be another MTA - or there may be a delivery.


MDA - Mail Delivery Agent - Storage Interface. The MDA (like Postfix's 
local or Dovecot's LMTP) accept messages from a MTA and store them - 
which typically means saving to disk in some fashion.


Host System - the running O/S that is running the MTA (Postfix).

Local Users - known to the host system. Users configured in your 
/etc/passwd as an example.


Virtual Users - valid users that are not necessarily known to the host 
system. Basically any user database that is not used by the host system.


With those defined - consider the interaction of MUA-MTA-MDA. Using your 
workstation mail client (for convenience let's say Thunderbird) you send 
a mail...to yourself. Whether your mail account is local or virtual is 
irrelevant. Thunderbird connects to the configured Outgoing Server - 
let's say at mail.mydomain.com on port 587. The Postfix listener (which 
is smtpd, as in SMTP Daemon) takes that message and via the black magic 
- I mean exceptional coding of the various processes (and there is no 
sarcasm whatsoever in that statement) - determines that it belongs to 
this same server. The message is then passed to the MDA and is saved for 
later retrieval.


Now consider the next level - someone from outside your system, on the 
nasty InfectedNet, sends you a message. This is MTA-MTA-MDA. Just like a 
MUA, the remote MTA connects to your MTA except this time using port 25 
- which is handled by another instance of smtpd. A near-identical 
process occurs, the message is determined to be handled locally, and is 
passed to the MDA.


The above two interactions are basically the only "local" possibilities. 
If the MTA passes the message to anything other than a MDA - that's a 
relay operation. Which means when *your* MUA connects to *your* MTA and 
asks it to send your birthday congratulations to m...@giggle.com - that's 
a relay operation.


Hopefully the above makes sense and my subjective version isn't too far 
off from objective reality.


If you made it to this point - go back to the top where I said start 
small. Do so. Attempting to introduce encryption to a server that is not 
both fully-functional with plaintext and whose configuration is not 
understood is an excursion into extreme masochism.



[...]
Seems most documentation is written for folks who 
already have a good understanding of the state of SMTP.


You are correct.


My goals are to stand up a reasonably secure mail server as quickly as 
possible so I can get back to designing databases and writing middleware 
code.


Generally such an attitude, while understandable and often shared, is 
generally going to be met with a response that administering a mail 
server is not a part-time job and if you're not "qualified" then you 
should hire someone who is. I've been lucky enough to have received some 
hand-holding myself so I'm trying to pay it forward.




I'm running 3.3.0 - I would sure appreciate your help.  I've had some 
success so far and I look forward to continuing to build my competency 
in smtp admin with postfix.



There's no better place to do so!

--
Daniel

Suggestions for submission protection

[Daniel Miller]

I have what seems to be a reasonably stable and functional filter 
protecting my port 25 SMTP interface to the outside world. However, most 
filters (including postscreen) state they are not intended for use 
between MUAs and the MTA. Therefore my 587 submission port does not have 
additional filters beyond TLS & SASL AUTH.


I'm seeing some higher levels of attempted logins from various sources. 
Are there any automated filters that are suggested? Or do I simply add a 
check_client_a_access and reference a manually maintained blacklist?

--
Daniel

Re: Testing new server

[Daniel Miller]

On 4/19/2019 3:35 PM, Daniel Miller wrote:


If anyone wants to test - please try sending to the address "pubtest at 
danmarkreps.com".




Well...I've gotten at least one test message (thank you Lazy G!) so I 
can't be *completely* broken.


Which leaves me with two likely possibilities - either Gmail/Hotmail, 
unique to themselves, are expecting some responses from my server that 
they aren't getting...or I must have something filtering them at a lower 
level.


This server was setup partially as a testbed for a new config. In 
particular, I'm trying ASSP in the "proper" manner, where ASSP only 
directly listens on port 25 - ports 465/587 are handled by Postfix 
initially.  And that's been working fine - but now that I've actually 
enabled TLS in ASSP...


brief deviation - I thought I had TLS enabled previously...trying to 
make hardenize happy showed that ASSP didn't have access to my 
certificates.  Apparently my installation of certbot didn't allow read 
access to the necessary folders.  Note to all - if you're going to use 
the "live" certs directly from any other program make sure you have 
proper read/enter access to the "live" and "archive" folders.


Now that I've corrected that and am actually supporting STARTTLS...I 
have this problem. Does anyone see anything wrong via their logs or 
telnet? Otherwise either Gmail/Hotmail must have me blocked...or I'm 
blocking them and have to find where it's hiding.


--
Daniel

Testing new server

[Daniel Miller]

I've setup a new server - and it *was* working fine...but then I enabled 
a few more settings...  I was attempting to make hardenize.com happy 
(and I'm glad I did - it exposed some stupid mistakes on my part).


I'm able to send without issue and receive from most other servers. But 
in particular, Google & Outlook seem unable to connect via TLS.  It 
looks like the initial handshakes are fine...but then nothing happens.


If anyone wants to test - please try sending to the address "pubtest at 
danmarkreps.com".


Thank you.

--
Daniel

Re: Google blocking...again...

[Daniel Miller]

On 2/1/2019 9:20 PM, listacco...@starionline.com wrote:
How much time?  It's already been close to 2 weeks.  I AM on Google's 
feedback loop, have never received anything from it.  I have verified 
the domain with Google, correct reverse DNS, SPF, none of that has 
changed.



Visit this page and fill it out *completely*.  And do it again daily for 
a few days.  You also need to have been cleared from most RBLs.


https://support.google.com/mail/contact/msgdelivery

--
Daniel

Re: Rethinking the Postfix release schedule

[Daniel Miller]

On 1/29/2019 7:40 AM, Wietse Venema wrote:

I'm reconsidering the once-per-year schedule for stable releases.
Basically, a Postfix stable release freezes development at a point
in time, forever. Primarily, this is good for stability.


Are the reasons you imposed a once-per-year release previously lessened 
in some way today? The release schedule is far less important than the 
quality & usability of the product.  So the question is what works for 
you - and what will encourage you to continue making your efforts 
available to others?


As a user - I'd prefer releases "when they're ready" regardless of 
timeline or age.  Postfix has the unfortunately unusual record of 
extreme stability - so as far as I'm concerned if you and those you work 
with consider a particular revision "stable-worthy" I'd rather you 
release it instead of waiting an arbitrary time period.  Which/how many 
versions you choose to provide support for is far less important to *me* 
than seeing continued growth.


But knowing that Postfix enjoys a preferred role for many distributions 
as the SMTP solution of choice I'm assuming you're also concerned about 
interactions with distro maintainers. So I suggest two possibilities:


1.  Similar to Ubuntu - have more frequent "short-term support" releases 
with designated "long-term support" releases at longer intervals.


2.  Re-consider whether arbitrary date-based releases are meaningful at 
all.  Instead, release on the "when they're ready" model and when a 
combination of reporting frequency and your own sensibilities tell you 
conditions are right designate a particular release as "long-term 
stable" - which will probably be close to an annual basis and will 
hopefully line-up with most distro freeze schedules as well.



--

Daniel

Re: ignore SASL/Auth to specific server (internal exchange relay)

[Daniel Miller]

Not wanting to get in the way of the experts but this may help:

An oversimplified view of the transport map is it tells Postfix what 
line in master.cf to use for a given recipient domain (or full 
address).  There's only one transport map but it can have several lines 
for individual decisions.


Wietse's email told you to perform a command-line test to verify your 
transport map is setup correctly.  So do that first.


The definitions in master.cf tell Postfix where to listen and where to 
send the message.  So with an explicit transport mapping, using 
master.cf you provide explicit overrides to the defaults or global 
settings from main.cf.  So if the only "special" behavior you need for 
the exchange transport is no sasl:


exchange  unix -       -       n       -       -       smtp
 -o smtp_sender_dependent_authentication=no

Daniel

On 12/11/2018 1:40 PM, Stefan Bauer wrote:

thank you for your help!

If i understood you correctly, i set in transport:

domain1.de                exchange:

In master.cf 

exchange  unix -       -       n       -       -  smtp
 -o smtp_sender_dependent_authentication=no
 -o transport_maps=hash:/etc/postfix/transport_internal

And in transport_internal

domain1.de            smtp:192.168.124.5:2525 



but this way, postfix is doing a MX-lookup for domain1.de 
 and not honoring transport_internal as it seems.


Is this basically the right path?


Am Di., 11. Dez. 2018 um 21:48 Uhr schrieb Viktor Dukhovni 
mailto:postfix-us...@dukhovni.org>>:


> On Dec 11, 2018, at 3:41 PM, Stefan Bauer
mailto:cubew...@googlemail.com>> wrote:
>
> Can you recommend appropriate manual(s)? I dont understand what
you mean with separate transport.

http://www.postfix.org/master.5.html
http://www.postfix.org/transport.5.html
http://www.postfix.org/ADDRESS_REWRITING_README.html
http://www.postfix.org/FILTER_README.html#advanced_filter
  ( Advanced content filter: sending unfiltered mail to the
content filter )

Also the Postfix book by Patrick Koetter and Ralf Hildebrandt.

-- 
        Viktor.

Re: fast postfix smtp only

[Daniel Miller]

On 8/31/2017 12:42 AM, Matteo Cazzador wrote:

Hi, is it possible to create a fast smtp server only?

This is my scenario:

a customer have 2 sites: "site1" and "site2" , but only one mail 
server that reside in "site2", with TLS sasl and all the user defined 
on it.


The connection of site1 is low.

Is it possible to create a postfix smtp only server that reside on 
"site1".


My purpose is to "make" sending mail faster from "site1", on mail 
client side.


Is it possible to use TLS/sasl with this smtp server (site1) only? 
Maybe i need to create a dedicated account?


Related to dns configuration, is it possible to define only PTR record 
without MX record for "site1" or is better to make a simple relay on 
mail server "site2".
If I understand you correctly site1 has a slow internet connection. So 
the process of connecting to and sending via site2 is slow. There is no 
magic you can apply to fix this - besides increasing the speed of the 
connection.


If you setup a relay server on site1, that forwards to site2 - you're 
still limited by the connection speed.  And if you setup a "complete" 
sending server on site1 - it will still be slow.


Possibly turning off recipient validation would speed up the perceived 
mail client operation - but I really wouldn't recommend that.


--

Daniel

Re: Limit the damage of a hacked sender acount

[Daniel Miller]

On 2017-06-23 17:11, wie...@porcupine.org wrote:

Daniel Miller:
I had a couple of accounts with too simple passwords hacked. And 
obviously

my mail server is entirely too efficient - I think about 50k spams got
blasted out before I caught it (because we got in the DNSBL's).

Separate from improving the password security - what can I do to limit 
the
damage a compromised account can cause? Without receiving user 
complaints
about not being able to send the latest cute kitty pictures to their 
whole

addressbook?

Are there per-sender limits that can/should be applied? And is there a 
way
I can be notified of a suspicious condition - without manually 
monitoring

the queue?


Search for "postfix policy rate limit"

Wietse


The bulk of the results I receive from that refer to external policy 
daemons. ASSP can probably handle that (I'm looking) but I was hoping 
for something more Postfix-specific. I did come across references to 
some parameters I haven't used before - including


smtpd_client_connection_count_limit
smtpd_client_connection_rate_limit

which I have presently set to 5 - haven't done any testing to see if 
that will have any impact.


If there's another reference I should consult please tell me.

---
Daniel

Limit the damage of a hacked sender acount

[Daniel Miller]

I had a couple of accounts with too simple passwords hacked. And obviously 
my mail server is entirely too efficient - I think about 50k spams got 
blasted out before I caught it (because we got in the DNSBL's).


Separate from improving the password security - what can I do to limit the 
damage a compromised account can cause? Without receiving user complaints 
about not being able to send the latest cute kitty pictures to their whole 
addressbook?


Are there per-sender limits that can/should be applied? And is there a way 
I can be notified of a suspicious condition - without manually monitoring 
the queue?


--
Daniel

Re: Policy server sender verification

[Daniel Miller]

June 4 2015 4:29 PM, wie...@porcupine.org wrote:
 Daniel Miller:
 
 Is there a way for a policy server to validate senders using
 Postfix's built-in authentication (like meeting permit_mynetworks
 and permit_sasl_authenticated)? ?Or must the necessary checks be
 duplicated?
 
 Let Postfix do the permit_mynetworks, permit_sasl_authenticated etc.
 valudation before invoking hte policy service:
 
 smtpd_xxx_restrictions =
 permit_mynetworks,
 permit_sasl_authenticated,
 reject_unauth_destination
 check_policy_service protocol:endpoint
 ...
 
 Wietse

But doesn't the permit_xxx halt processing?  My fault for not being specific 
- I want to invoke the policy service for doing header checks, or rather header 
removal, but only call the policy service after the other validation checks 
have been passed.

--
Daniel

Policy server sender verification

[Daniel Miller]

Is there a way for a policy server to validate senders using Postfix's built-in 
authentication (like meeting permit_mynetworks and permit_sasl_authenticated)?  
Or must the necessary checks be duplicated?

--
Daniel

Strip receipt request

[Daniel Miller]

Is there a way of removing return-receipt requests from internal senders for a 
particular external recipient?  Or does this require a separate tool/script to 
pass sent messages through?

--
Daniel

Re: Strip receipt request

[Daniel Miller]

I don't think that's the case - the users in question submit using Thunderbird.

--
Daniel

June 1 2015 5:46 PM, wie...@porcupine.org wrote:
 Daniel Miller:
 
 Is there a way of removing return-receipt requests from internal
 senders for a particular external recipient? ?Or does this require
 a separate tool/script to pass sent messages through?
 
 If the request is made in SMTP, like this:
 
 RCPT TO:recipient@rcpt-domain NOTIFY=SUCCESS,...
 
 Then it is possible to fix this with smtpd_command_filter.
 http://www.postfix.org/postconf.5.html#smtpd_command_filter
 has examples.
 
 Let me know if you need help with this solution. Explaining this
 takes time, and I don't want to do it if your problem is something
 else.
 
 Wietse

Re: OT, where to turn?

[Daniel Miller]

On 1/22/2015 3:13 AM, Joe Acquisto-j4 wrote:

Thanks. I appreciate the reminder.  The methodology is long standing
and should be altered.  The users have only the tools offered to them.

However, not trying to be argumentative at all -

While I agree Bcc is correct, I am having difficulty accepting,
logically, not in fact,  that the forwarded message should fail.
After all, it is actually addressed to only one person.

By analogy,  would UPS or FedEx be correct to refuse a shipment
as overweight if it consisted of an envelope empty except for a
sticky note that had 500 Lbs. written on it?

If the answer is: RFC says, I would feel the same, but have to shut up
and sit down.

I should let it go, on this list at least.

joe a.




Are you asking to have a single copy of all mail forwarded to the o365 
account?  You could perhaps make use of the sender_bcc_maps and 
recipient_bcc_maps to do it behind the scenes.  Though if o365 is 
rejecting anything that has a header greater than a given size that 
wouldn't help.


Perhaps you could define a transport map for o365, that passed the 
message through a simple script that stripped the CC  BCC headers prior 
to sending it on.



--
Daniel

Secondary MX behaviour

[Daniel Miller]

This question is actually two questions - neither of which are 
Postfix-specific but email-generic - but this list is the best resource 
I have to ask such questions.


First - I've been contributing to Project Tarbaby, which means I have 
a pair of secondary MX records below my primary which accept anything 
they get - and those get used to build DNS blacklists. Properly 
configured hosts talk to my primary server without issue. The only 
question here is - does anyone have an objection to what I'm doing with 
this?


Second - while this has been working for quite some time, recently my 
fax-to-email service provider has started sending everything to the 
secondaries.  Which means I get no faxes.  I can't configure their 
servers so I can't fix them.  I've told them their systems are broken - 
at the least they need to refresh their MX lookup - but they insist 
everything is fine on their end.  When I said the were in violation of 
the RFC's, they sent me back something that said the RFC's are ambiguous 
with how they should treat MX records, order, and failures.  Based on 
the log exerpts they sent me I believe they're using Sendmail.


Is the method for working with primary vs secondary MX records clear - 
at least clear enough that my tarpit setup should work?  Or is there 
enough of a grey area that this setup is doomed to failure regardless?


--
Daniel

Re: Secondary MX behaviour

[Daniel Miller]

On 9/10/2014 10:24 AM, Viktor Dukhovni wrote:
If your system ever responds with a 4XX, retries will hit the 
secondaries. You need to at least exclude clients that first tried the 
primary and tempfailed. However, transient connection or DNS problems 
can also cause a legitimate client to skip the primary now and then. 
Therefore, such automatic blacklisting needs to be implemented with 
great care, by excluding clients that have mostly gotten it right in 
the not too distant past. 


The DNS blacklisting is score-based - so if anyone winds up in the there 
it won't be the end-all, certainly not for my primary which has 
extensive whitelisting.

MTAs MUST try the highest priority (lowest value)  MX records first.
However, there is no expectation that such an attempt will always
be observed by the receiving system.  See above.

If a sender consistently fails to reach the primary MX, and you're
not greylisting or otherwise returning 4XX responses forcing them
to the secondaries, perhaps there is a systemic connectivity or
DNS problem.

Their Sendmail MTA could perhaps be misconfigured, but that seems
unlikely at this time.



The problem I'm facing is the remote server isn't reaching my primary at 
all - I have absolutely no indication of it in my logs whatsoever.  And 
they're extensively whitelisted (by IP, domain, and address).  They're 
just going right to the secondaries and have been for the past couple 
weeks.  Yet everyone else is able to reach me without issue.


Temporarily at least I'll drop the secondaries from my DNS and see if it 
helps - but I still think there's something broken on their end.  I just 
don't know how to express it properly beyond, it's wrong, and it's on 
your end.


--
Daniel

Re: Secondary MX behaviour

[Daniel Miller]

On 9/10/2014 10:35 AM, Wietse Venema wrote:

Daniel Miller:

This question is actually two questions - neither of which are
Postfix-specific but email-generic - but this list is the best resource
I have to ask such questions.

First - I've been contributing to Project Tarbaby, which means I have
a pair of secondary MX records below my primary which accept anything
they get - and those get used to build DNS blacklists. Properly
configured hosts talk to my primary server without issue. The only
question here is - does anyone have an objection to what I'm doing with
this?

This is unsafe, because the connection to the primary MX may fail
for all kinds of reasons, including a temporary network outage
somewhere far away on the Internet.


Is the method for working with primary vs secondary MX records clear -
at least clear enough that my tarpit setup should work?  Or is there
enough of a grey area that this setup is doomed to failure regardless?

Tricks with MX-priority spamtraps share the problem that they make
assumptions about the behavior of all legitimate MTAs.

For a related approach, see, for example, nolisting.

Wietse


Do I infer from that MX-priority spamtraps are a Bad Idea - at least in 
the real world?  This is the first time in about...I think 6 months 
since I implemented the tarpit that I found a problem.


--

Daniel