[pfx] Re: Some TLS connections untrusted in postfix but trusted with posttls-finger

[Tom Hendrikx via Postfix-users]

On 01-12-2023 08:59, Alexander Leidinger via Postfix-users wrote:

Am 2023-11-30 16:53, schrieb Wietse Venema via Postfix-users:

Alexander Leidinger via Postfix-users:
What is wrong here that [tlsproxy] doesn't establish a trusted 
connection

to the github mailservers when posttls-finger is able to do that with
the same cert store?


Because there are differences between tlsproxy and posttls-finger.

1) Different executable files may be subject to different SeLinux,
AppArmor etc. policies.


This is FreeBSD, no different policies.


2) Different privileges: tlsproxy runs as the "postfix" user,
posttls-finger as "root".


Ok.
The cert store permissions are OK. Any ordinary user is able to read it. 
posttls-finger as any other user (incl. postfix) produces the same 
output. With -P it verifies the cert, without it it doesn't.


So still the question why the same configured cert store (posttls-finger 
+ postfix + @FreeBSD.org + @reply.github.com) works for sending mail to 
FreeBSD.org but not to github.com.



3) Different certificate stores, when tlsproxy may runs chrooted,
and posttls-finger does not.


No chroot-difference between both. This runs in a FreeBSD jail (like a 
container or a Solaris zone) and I was logged into this container, so 
both have seen the same filesystem content.




There still seems to be a disconnect in communication here, as you 
didn't quote Viktors response on 'smtp_tls_policy_maps', which seems to 
be the key issue here. The policy in your connection to github seems to 
be 'verify' or higher.


Maybe you could test again with an empty 'smtp_tls_policy_maps' 
parameter in postfix config, or show all values in your policy map 
explicitly (which might be difficult due to mysql usage)?


Kind regards,
Tom
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Domain-Specific inbound relay host rules

[Tom Hendrikx via Postfix-users]

On 15-10-2023 15:52, B Williams via Postfix-users wrote:

All:

Long time postfix user. I have an internet facing mail server running 
Postfix. For about half of my domains, I have them run through a spam 
filtering service (like MimeCast/Proofpoint). The other half just come 
direct because they are either very low volume or are used for 
testing/automation.


There is a spam network that has figured out that they can bypass my 
spam filtering service by ignoring the MX record and just sending mail 
directly to the mail server. Pretty sneaky.


So what I’m trying to devise is a strategy that would allow me to reject 
email for some domains if it didn’t come through the spam filtering 
service, but allow messages for other domains to be delivered that I 
don’t have going through the spam service.


Ideally, there would be some kind of hash map that would basically say 
if the domain is present in the map it must come through a defined 
relayhost. Or maybe there is a custom milter strategy.




I'm running a similar Postfix instance, receiving mail from an external 
spamfilter. I run an additional smtpd process on a dedicated port for 
the spamfilter. This port only accepts mail from the spamfiltering 
company (using a check_client_access cidr map).
Note: The spamfilter company allows me to configure a specific delivery 
hostname and port, so no port 25 required.


On the public smtpd process at port 25, there should never arrive any 
mail for the spamfiltered domains, so you can leave the domains out of 
mydestination, virtual_alias_domains, or whichever way you define the 
list of domains that you accept mail for.


Or maybe simpler to add to your existing setup: create a 
check_recipient_access table to reject the domains only in the smtpd 
process listening at port 25.


Tom
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Njal.la

[Tom Hendrikx via Postfix-users]

On 02-05-2023 13:14, pripercat--- via Postfix-users wrote:

Thanks, but it still doesn't work for me with those parameters. The
relayhost value is an email server of my hosting. And I don't have that
information. The njal.la admin refers me to this forum. :(



If njal.la provides documentation on how to setup an authenticated relay 
server, but without credentials, and then they point you here, my simple 
conclusion would be that don't provide this service. Probably you'll 
have to use an e-mail relay service from a different provider (which 
might be your home ISP, domain provider etc).


My 2 cents,
Tom
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Different set of milters for one domain?

[Tom Hendrikx via Postfix-users]

Hi,

I've been using milter-manager [1] for a long time now to run various 
milters selectively. In my case, I defined a custom 'Applicable 
condition' (see docs) to exempt various email accounts from 
spamfilter/virus checks (f.i. spamtraps).


The docs look like they haven't been updated in a while, but the github 
repo [2] is quite active.


[1] https://milter-manager.osdn.jp/
[2] https://github.com/milter-manager/milter-manager/

On 28-03-2023 15:32, Bill Cole via Postfix-users wrote:

On 2023-03-28 at 06:10:27 UTC-0400 (Tue, 28 Mar 2023 03:10:27 -0700 (PDT))
Dan Mahoney (Gushi) via Postfix-users 
is rumored to have said:


Hey there all,

Dayjob sometimes receives mail for one domain that we'd like to have 
bypass certain milters (specifically, we want to exempt them from some 
filtering/scanning mitlers since the domain is pretty much entirely 
passthrough) --


Is there an easy way to do this in postfix without completely 
splitting the config up?


Short answer: No.

The question  has come up here multiple times and always gets the same 
assortment of alternative ideas for how to do what people want...


Fortunately, many milters provide the tools to be selective about how to 
handle different target domains.



___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

Re: Postfix with Kibana, help with configuration?

[Tom Hendrikx]

On 27-10-2021 07:43, raf wrote:

On Tue, Oct 26, 2021 at 02:01:11PM -0300, SysAdmin EM  wrote:


Hello everyone?
Has anyone correctly configured kibana to read postfix logs?

I read this documentation, but in kibana 7 not work for me.
https://github.com/whyscream/postfix-grok-patterns

postfix_queue_id postfix_from postfix_to postfix_date

The idea is to have a dashboard with the mails sent to prevent users from
entering the console to search for them.

Regards,


Sorry, can't help. Maybe you could present the problem you are having
as an issue on that github repository. If you show them what logs you
have, and what you are expecting to be grokked, they might be able to
see what the problem is.



Please do, I'd be happy help you out if possible.

Kind regards,

Tom (the repo maintainer)

Re: Clients Sending Phantom Email

[Tom Hendrikx]

On 28-04-2021 22:41, Wietse Venema wrote:

Asai:

Greetings,

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.


This means that client systems are compromised with malware
that sends email directly to the outside world, bypassing
your mail server.

To stop these, block outbound port 25 on your firewall for all
systems except your mail server.



The OP has not specified whether the intended recipient ever receives 
the message, only that the sender thinks it's sent, and that the 
expected MSA doesn't see the message in transfer.


In the past, I've also seen desktop malware scanners that setup a local 
SMTP proxy for all outgoing email. It might be that the Mail client 
sends the message successfully to the proxy, but the proxy sends it to 
/dev/null and doesn't inform the desktop user properly.


Kind regards,
Tom

Re: How do I stop getting multiple copies of emails from "always_bcc" option?

[Tom Hendrikx]

On 05-03-2021 09:41, Steve Dondley wrote:

You may also have disabled recipient duplication. We will
never knwo unles yo reveal yur configration as described
in http://www.postfix.org/DEBUG_README.html#mail.


I've been looking at this a lng time tonight. Despite my best
efforts, I did not find a reason for the duplicate email.

I even created my own content filter to rule out some kind of
spamassassin/spamc/spamd miconfiguration. I'm still receiving emails
twice with this customs content filter turned on (only once with the
content filter turned ooff).

I turned on verbose for cleanup and trivial-rewrite but there was so
much output and much of it repetitive that it didn't help me determine
what's going on.

Here are postfix config file: https://pastebin.com/bZxjHF5y

Hopefully something jumps out at you.



Isn't this as simple as:

1. new email comes in, is delivered to content filter, with bcc to 
always_bcc recipient.
2. content filter re-injects email into the queue for final delivery, 
postfix performs final delivery, with bcc to the always_bcc recipient?


Since these are 2 separate deliveries (with different routes) as far as 
postfix is concerned,there will be 2 messages to the always_bcc 
receipient, and no deduplication.


Kind regards,
Tom

Re: Recommended milters for small setup

[Tom Hendrikx]

On 15-10-2020 17:19, Ian Evans wrote:
The long story short is that due to dealing with family medical issues 
over the past few years, my Combo web/postfix server is still on 
Ubuntu 14.04.


In a couple of months I will have some time to upgrade. Instead of 
risking an in place upgrade, I am going to fire up a new droplet on 
Digitalocean, install the latest stuff over there, and migrate my data.


My site has two email users, me and the missus. I currently run an 
email stack of postfix, amavis, spamassassin, clamav and dovecot. The 
Postfix also has dkim, dmarc, spf and postscreen.


Is there a more efficient, memory stingy, faster milter way to run 
spamassassin, clamav, etc, or would you recommend sticking with amavis?


Thanks.


I use https://github.com/milter-manager/milter-manager, works great if 
you like milters :)


Kind regards,

    Tom

Re: Sender restriction to reject message with multiple from addresses

[Tom Hendrikx]

On 07-10-2020 02:27, Pau Peris wrote:

I'm hosting my dad's webpage which has a contact form (which should be
improved to avoid spam and/or bots) and from time to time someone
types multiple email addresses in the from field of the form so
contact emails with multiple from addresses like "from:
h...@example.com, f...@example.net" are generated. I though that those
kind of messages should get rejected and thought that maybe there was
a builtin restriction for this use case.

Your basic setup is lacking, and causing you problems. The website 
should not send the emails using the email addresses of the person 
submitting data on your website in the From: header.


If the email address has DKIM/SPF/DMARC policies attached, actual 
delivery of the message is likely harder, because f.i. the webserver is 
not listed in the SPF policy of the sender domain. Essentially, the 
email your website is sending, is spoofing the From: header. This might 
not be too obvious when all email sent from the website ends up in your 
mailbox (being the website administrator), but when you try to deliver 
to 3rd parties, you'll find this out very quickly.


Conceptually, you could even say that ther person entering data in the 
form did not send an email: he/she entered data into a form on a 
website, and the website sent the email. Hence, the From: header should 
contain webs...@example.org.


Back to your problem: the website controls the From: header so no 
multiple email addresses in there. You could configure the website to 
put the email address of the person entering data in the form in the 
Reply-To: header.


Kind regards,

    Tom

Re: Rejecting emails based on address extension?

[Tom Hendrikx]

On 10-04-2020 18:09, Fred Morris wrote:

I didn't follow this to begin with, apologies.

On Fri, 10 Apr 2020, Tom Hendrikx wrote:

On 09-04-2020 01:01, @lbutlr wrote:

 Given an email address of user+ama...@example.com how can I reject all
 emails to that address that do not come from amazon.com?


The mechanics of extracting the relevant (definitionally speaking) "test
string", in this case "amazon", from the (definitionally speaking)
"destination address" are left as an exercise for the reader.
;-)

There are some larger mechanics to be discussed.

The "destination address" is extracted from which header? To: would be 
the

naive choice, but Delivered-To: is probably better. However, using this
header requires that the filtering take place very close to final
delivery, as that's when the header is inserted.

What is "come[ing] from", definitionally speaking? As Tom observes, 
there are choices. I offer the following definition of "effective 
domain" for this purpose: "The 'effective domain' is the domain 
extracted from the Return-Path: if present, otherwise the From: 
header." Using Return-Path: likewise requires being closer to the 
delivery event than not. As seen in discussions of the functional 
impacts of techniques such as SPF and DKIM on the operation of for 
example mailing lists, the domain in Return-Path: will violate the 
principle of least surprise often enough to require thought and 
deliberation; unfortunately that's unavoidable. (Personally I use 
Return-Path:, as I use effective domain for processing myself.)


Being inserted close to delivery both the Return-Path: and 
Delivered-To: headers will typically be very close to the top of the 
header stack; other choices, such as From: or To: may not be. This is 
by way of observing that for reliable processing it's often necessary 
to load all of the headers into a map where they can be looked up by 
header name. This means that strict stream processing, line by line, 
or as milters are wont to do, is not possible (of course you can do it 
with a milter, but you will need to maintain state and think about 
it). Also for certain multiple occurrence fields, particularly 
Received:, the ordering does matter; for Received: the instance at the 
top of the stack is typically the only one which can be "trusted" (not 
attempting to define that one!).


I'm using address extensions like this for more than 10 years, for 
almost every commercial interaction through the web. I'm using the 
domain name of the website of the party that I'm giving my address 
to, or a reference to the mobile app that wants me to sign up.


https://github.com/m3047/trualias

I haven't seen any abuse (a company bought or repurposed an address) 
except for 1 specific incident.


Tom's experience is very different from mine or that of Andrew Lewman, 
whose blog is referenced in the README.md for that project.


The blog link is broken, the actual article is here: 
https://blog.lewman.com/why-i-have-over-one-thousand-personal-email-addresses.html


Please note that I don't wildcard a domain: I'm using a single regex in 
postfix that aliases addresses with a specific prefix to my inbox:


in 'virtual_alias_maps.pcre':
/^hi\..*@example.com$/   personal.in...@example.org

I give out addresses like: "hi.company@example.com". Note that the 
address "h...@example.com" is NOT deliverable, so simply stripping the 
label from the address will result in a delivery error. The prefix 
protects against fully random (f.i. message-id@servername) or 
'common-named' localparts (sales@). No tcp tables, milters or external 
tools needed here.


While I've looked at your project, I don't understand which problem you 
are solving with the verification code: when some evil party has 
bought/sold a labeled address, they could in theory unlabel or relabel 
it, rendering the address (possibly) invalid. But they want to send 
email to tens of thousands of addresses, of which only a few are labeled 
anyway: if they are even aware of the issue, why would they even bother 
for these few recipients? If they are aware of the issue, a more 
plausible solution (to me at least) would be to simply delete the 
labeled addresses, which is much easier than altering them into 
something that is no longer pointing to the original company.


The only solution that the verification code provides (IMHO), is that I 
know (to some degree) that I actually gave out that alias. But then: how 
often does it happen that you receive email that actually has a label, 
but has no or an invalid verification code?


In short: I'm very curious about your experience :)

Regards,

    Tom

Re: Rejecting emails based on address extension?

[Tom Hendrikx]

On 09-04-2020 01:01, @lbutlr wrote:

Given an email address of user+ama...@example.com how can I reject all emails 
to that address that do not come from amazon.com?

I think I did something like this once but if I did, I didn’t keep notes. :/




A slightly different take on this:

I'm using address extensions like this for more than 10 years, for 
almost every commercial interaction through the web. I'm using the 
domain name of the website of the party that I'm giving my address to, 
or a reference to the mobile app that wants me to sign up.


I haven't seen any abuse (a company bought or repurposed an address) 
except for 1 specific incident. Maybe I'm too picky about doing business 
with shady companies... The number of addresses handed out should be in 
the hundreds.


What  I took from this:

- Handing out addresses is easy, but it's hard to keep track of them. I 
can create new addresses on the fly on any occasion (anything I make up 
is accepted by my server), but to remember them and write a specific 
line in my postfix config for them later that day, is hard. If you want 
rules in your spam setup for this, they should be automated: f.i. a 
regexp that matches the label in the recipient address to be (part of) 
the sender address.


- Matching actual senders with the label you give them is a grey area. 
Many senders use a less brand-specific email-sending platform than what 
you expected when you made up the label: f.i. an online order at 
bbq-stuff.org actually sends mail from the company-wide domain 
garden-apparel.com. These matches need human interpretation (or a very 
large database and sufficient input data) before you can decide whether 
someone is actually doing something wrong.


- The few actual wrongdoers you will be catching are probably more 
interesting to receive and keep for research purposes, than to simply 
reject.


My 2 cents on this.

Kind regards,

Tom

Re: milter_default_action=accept not honored

[Tom Hendrikx]

Hi,

In http://opendkim.org/opendkim.conf.5.html there are several error 
conditions defined, with the default actions for them, for instance 
"On-SignatureError", "On-KeyNotFound". Ar least some conditions default 
to tempfail. Configure the milter correctly and you should be fine.


Kind regards,
Tom

On 19-11-19 20:45, Viktor Dukhovni wrote:

On Tue, Nov 19, 2019 at 11:39:03AM -0800, Jeremiah Rothschild wrote:


It seems the tempfail is from the milter, not from Postfix.  Postfix
is not in a position to know that the milter is not working as it
should, the milter is responding "normally".


That's too bad. I'm surely oversimplifying things but I figured the milter
would do something like pass a non-zero exit along, which postfix could then
use to make a decision on the status.


Postfix isn't executing the milter as a subprocess, they communicate over a
socket.  If the milter returns a 4XX verdict, that's normal milter behaviour.
If the milter drops the connection, times out, ... that's a milter failure,
and *then* the Postfix milter_default_action kicks in.

Your best bet is to invest effort in keeping your milter working properly,
optimizing what happens when it is not working is likely the lesser option.

Re: ODMR/ATRN ?

[Tom Hendrikx]

On 10-06-19 03:37, Ronald F. Guilmette wrote:
> In message <64994169-2c87-4029-9c31-0765608f4...@opendmz.com>, 
> Christopher van de Sande  wrote:
> 
>> Yes absolutely correct
>>
>> If your sever at home is online then it will pass through your cloud VM in
>> mere seconds  If your home server is offline then it will continue trying
>> to deliver at intervals Ewhich you can also configure
> 
> Perfect.  Just perfect.
> 
> Thank you Postfix!  Thank you Wietse!  Thank you everybody!  This is
> going to be simpler than I had anticipated, I think.  (Knock on wood.)
> 
> I do have just a couple of small lingering concerns... things that just
> now occurred to me.  These relate to dynamic DNS, which I've never actually
> used before myself, but which I nontheless have a sort of vague conceptual
> understanding of.
> 
> As I understand it, you get yourself your own private FQDN, which is
> assigned to you by whatever dynamic DNS provider you choose.  And then,
> each time your machine gets itself a fresh new DHCP lease, it needs to
> send that address, in some manner, to the DDNS provider which will then
> update the relevant A record based on your new dynamic IP.  Is that a
> fair summary?
> 
> Assuming so, I have two questions about this...
> 
> Well, make that one question.  (I just answered my own first question,
> which was "Yeabut, what if my whole local network is actually behind my
> ASUS SOHO WiFi router and what if it is my router intself that is, in
> the first instance, getting the DHCP lease?"  Apparently, some ASUS
> router models, including mine, fortunately, have an in-built DDNS client,
> and that in-built DDNS client can, allagedly, work wth both ASUS's own
> free DDNS service and also, allegedly, with the one provided by noip.com...
> and possibly also others for all I know.  So, no problem here!  This will
> work.)
> 
> So, here is my only other question:
> 
> Assuming the setup, as discussed here so far, where I'll have a Postfix
> instance running on a cloud VM, and where that Postfix instance will have
> an appropriate set of entries in transport_maps to cause that Postfix
> intance to try to send all mail it has received for my domains on to:
> 
> smtp:my-dynamic-fqdn
> 
> What happens in this scenario when and if there is a power failure that
> takes down my whole network, including my router?
> 
> Let's say that the the dynamic IP that I *was* using, just before the
> power fail, was a.b.c.d.  The question is:  While I am wandering around
> with my flashlight in the dark, what if some other customer of my ISP
> happens to request a DHCP lease and also happens to get a.b.c.d ... which
> is possible, because after all, *I* am not using that specific IP address
> anymore, so it will have been returned to the DHCP free pool.
> 
> In this scenario, could that other party who got a.b.c.d, dynamically,
> turn on a mail server and begin sucking down *my* emails from *my* cloud
> VM Postfix instance?
> 
> I guess that another way of asking this might be:  Does DDNS have any sort
> of "keep alive" signal that, if it goes dark suddenly, will result in
> revocation of the relevant DDNS name-to-address mapping?
> 
> I know.  I know.  I should probably be asking about these DDNS details
> someplace else.  And I probably shall.  But since all you folks here
> already know exactly what I'm trying to do, and why, and how, it's just
> easier to start here.
> 
> If what I have described is in fact a plausible and serious potential
> security issue, then I guess that rather than using plain old SMTP to
> move messages from my VM Postfix to my home Postfix, maybe I should
> instead be looking for some alternative transport protocol that verifies
> that the receiving node is actually one that *I* own and control... yes?

You can add TLS verification to your postfix client in the cloud. The
client will only deliver to a server when it presents a specific SSL
certificate to the client during the handshake. See
http://www.postfix.org/TLS_README.html#client_tls_policy




signature.asc
Description: OpenPGP digital signature

Re: any api to read logs ?

[Tom Hendrikx]

Hi,

I have a set of grok patterns for logstash. You can send the postfix
logs to logstash, have them parsed into something more or less
structured by the pattersn, then expose the logstash data through some api.

https://github.com/whyscream/postfix-grok-patterns/

Kind regards,
Tom


On 01-10-18 07:47, Илья Шипицин wrote:
> 
> 
> вс, 30 сент. 2018 г. в 4:40, Wietse Venema  >:
> 
> Wietse:
> > > Open a web search engine, ask for for 'logfile analysis tools'.
> 
>  ???:
> > logfile analys is good for human, it is not rest api.
> > I did search already
> 
> Here is an idea: combine log analysis with a web API. End of problem.
> 
> 
> 
> that was what I was going to implement.
> however, I do not like to implement thing that are implemented already.
> so, I did a google search and I asked mailing list.
> 
> seems, I need to implement rest api myself.
> 
> 
> one more question.
> I like text logs. they are fast, and available 100% (comparing, for
> example to some network logging).
> 
> is there a way (I did a seach already) to make logs structured ?
> something like apache access log (field with separator), json, xml, csv ?
> whatever to be machine readable (to make rest api actually read it)
>  
> 
> 
>         Wietse
> 

Re: spamming mailbox ?

[Tom Hendrikx]

On 14-06-18 15:27, Poliman - Serwis wrote:
> I check the mail queue and the logs and this time I found some strange
> thing. I used command "grep -r "emailemailemail.com
> " /var/log/mail.log" and result is in
> attached .txt file. If I understand properly there is many tries to send
> from do_not_re...@s1.poliman.net  to
> emailemailemailemailemailem...@emailemailemail.com
>  but nothing
> happens later because of failing connection to emailemailemail.com
>  on port 25.
> 

Yes, that are many attempts to deliver the same email. Because the
receiving server does not exist, the message is kept in the queue and
retried later.

This is easily visible because all log messages show the same queue id
(9438613CE9E). This will continue until maximal_queue_lifetime (default
5d) is reached.

Kind regards,
Tom

Re: Outbound address rewriting

[Tom Hendrikx]

On 19-04-18 23:26, Kevin Miller wrote:
> -Original Message-
>> I think in this case both domains are remote, in which case the
>> bounce issue may be moot.  Only users authorized to send outbound
>> mail can create email for the destination in question, and the
>> goal is to "correct" the destination domain.
> 
> Right.  As it stands now, the mail will sit in the outbound queue for days 
> until it finally times out as undeliverable.  My thought is that with the 
> rewriting, the mail will be either immediately delivered, or the sender get a 
> 550 rejection in a timely manner.
> 

You could also simply reject inbound messages to the non-existent domain
with a somewhat helpful reject message, explaining that the sender
should use the new domain. That way users will learn very quickly to
update their address book.

Kind regards,
Tom



signature.asc
Description: OpenPGP digital signature

Re: Specify VPN for postfix

[Tom Hendrikx]

On 01-08-17 16:46, Wietse Venema wrote:
> Yubin Ruan:
>> Can anyone tell me how to point postfix to a VPN connection? I have
>> setup a VPN listening at background on my Ubuntu and I want to point
>> postfix to that listening port whenever postfix try to connect to the
>> internet.
> 
> Wietse:
>> You specify 
>> /etc/postfix/main.cf:
>>   relayhost = smtp:[host on other side of tunnel]
>  
> Gary Sellani:
>> Could the host be something like 10.8.0.0/24? 
> 
> I wrote 'host' not 'network block'.
> 
> Consider the network as a collection of layers. An example applicable
> to Postfix looks like: physical layer (ethernet), network layer
> (IP), transport layer (TCP), and application layer (SMTP). In this
> architecture, an SMTP destination is a domain or host, where the
> host may be specified as an IP address. It's not an IP address block
> nor is it an ethernet broadast domain.
> 
>   Wietse
> 

Maybe you (the OP) should clarify what you mean with 'connect to the
internet'. Does this mean accepting email from hosts 'on the internet',
does it mean sending email to random hosts 'on the internet', or does it
mean something else? Explain in laymen terms what you're trying to do,
your question is too vague.

Tom

Re: Where are bounce messages for milters configured?

[Tom Hendrikx]

On 11-03-17 15:17, Den1 wrote:
> Since Linda brought it up I thought I would pop in as well. That's exactly
> what I tried to configure too but in spamass-milter in combination with
> Postfix. It's working OK but always says this,
> 
> 5xx Reject milter 
> END-OF-MESSAGE
> 185.127.117.96   server52744.sledco.com
> Blocked by SpamAssassin
> 
> The line I tried to change was "Blocked by SpamAssassin" but I gave it up as
> I couldn't find it where and how to do it. Any pointers on this specific
> milter would also be highly appreciated. Many thanks!
> 

The easiest trick to achieve this is to configure the milter to add a
header in stead of rejecting.

Then use postfix milter_headers_checks option to detect the header and
make postfix send the reject, including your custom message. I use this
with clamav and spamass-milter. Not sure about SNFMilter, never used
that one.

Kind regards,

Tom




signature.asc
Description: OpenPGP digital signature

Re: simple greylisting by geoip? milter or policy server?

[Tom Hendrikx]

On 15-06-16 02:21, Allen Coates wrote:
> 
> 
> On 14/06/16 23:31, list...@tutanota.com wrote:
>>
>> 14. Jun 2016 15:01 by njo...@megan.vbhcs.org
>> :
>>
>> Is there some way to integrate the GeoIP dbs with postscreen?
>>
>>
>> No, at least not easily.
>>
>>  
>>
>> Ok.  That would be a nice function to have, in my own opinion.
>>
> 
> FWIW -  my postscreen_dnsbl_sites contains the lines:-
> 
> zz.countries.nerd.dk,
> zz.countries.nerd.dk=127.0.3.58*-1,
> 
> The first line ALWAYS returns  a country code (for analysis), and also
> scores 1 "blacklist point" which is
> recinded by the second line if the remote host is in my own country (the UK)
> 
> You can also interrogate the site by country, eg   "host
> 4.3.2.1.uk.countries.nerd.dk", which will only return a code if the ip
> address belongs to the uk...
> 
> It might give you another "angle" on processing by country
> 

You could also convert the cidr tables from
http://www.ipdeny.com/ipblocks/ into check_client_access rules that
whitelist some countries from greylisting.

Kind regards,
Tom

Re: Test DANE

[Tom Hendrikx]

On 06-06-16 17:46, Viktor Dukhovni wrote:
> On Mon, Jun 06, 2016 at 05:31:49PM +0200, Tom Hendrikx wrote:
> 
>> I have been playing around with the dane check tool from sys4 too, and
>> it seems it doesn't support the nice CNAME trick shown in
>> https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022
> 
> In the dane.sys4.de test code CNAMEs in TLSA records are supported
> and work, provided the target of the CNAME is in a signed zone of
> course.  MX hosts that are CNAMEs are deliberately not supported
> as these violate the RFC requirements for MX records.
> 
> For example:
> 
> _25._tcp.gazonk.org.CNAME   _tlsa.gazonk.org.
> _tlsa.gazonk.org.   TLSA3 1 1 
> 2EE262031C03AD1143E557074DADCE1F681F1818D6B0DC59ED33F472 6B180B6C
> 
> For which https://dane.sys4.de correctly shows (that this domain
> is misconfigured by promising and then not offering  STARTTLS):
> 
> 42 gazonk.org
>212.247.24.42: STARTTLS not offered
> 
> IP Addresses
>212.247.24.42
> 
> Usable TLSA Records
>3, 1, 1 2ee262031c03ad11[...]ed33f4726b180b6c
> 

I did some further research. It seems that validns does not like this
construct, because it insists that TLSA records are 'properly prefixed'
(i.e. with a port and service prefix, see [1]).

My dnssec auto-signing setup invalidated the zone because of this, so it
was never published with these records, concluding in the sane tool not
being able to see them. My bad...

[1]
https://github.com/tobez/validns/blob/5a374cf1d629d8d2fecdf6f215aec9b056370868/tlsa.c#L87

Regards,
Tom



signature.asc
Description: OpenPGP digital signature

Re: Test DANE

[Tom Hendrikx]

On 06-06-16 20:26, Tom Hendrikx wrote:
> On 06-06-16 17:46, Viktor Dukhovni wrote:
>> On Mon, Jun 06, 2016 at 05:31:49PM +0200, Tom Hendrikx wrote:
>>
>>> I have been playing around with the dane check tool from sys4 too, and
>>> it seems it doesn't support the nice CNAME trick shown in
>>> https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022
>>
>> In the dane.sys4.de test code CNAMEs in TLSA records are supported
>> and work, provided the target of the CNAME is in a signed zone of
>> course.  MX hosts that are CNAMEs are deliberately not supported
>> as these violate the RFC requirements for MX records.
>>
>> For example:
>>
>> _25._tcp.gazonk.org.CNAME   _tlsa.gazonk.org.
>> _tlsa.gazonk.org.   TLSA3 1 1 
>> 2EE262031C03AD1143E557074DADCE1F681F1818D6B0DC59ED33F472 6B180B6C
>>
>> For which https://dane.sys4.de correctly shows (that this domain
>> is misconfigured by promising and then not offering  STARTTLS):
>>
>> 42 gazonk.org
>>212.247.24.42: STARTTLS not offered
>>
>> IP Addresses
>>212.247.24.42
>>
>> Usable TLSA Records
>>3, 1, 1 2ee262031c03ad11[...]ed33f4726b180b6c
>>
> 
> I did some further research. It seems that validns does not like this
> construct, because it insists that TLSA records are 'properly prefixed'
> (i.e. with a port and service prefix, see [1]).

Insists, as a policy check, which I have enabled (but is off by default)...

> 
> My dnssec auto-signing setup invalidated the zone because of this, so it
> was never published with these records, concluding in the sane tool not
> being able to see them. My bad...
> 
> [1]
> https://github.com/tobez/validns/blob/5a374cf1d629d8d2fecdf6f215aec9b056370868/tlsa.c#L87
> 
> Regards,
>   Tom
> 




signature.asc
Description: OpenPGP digital signature

Re: Test DANE

[Tom Hendrikx]

Hi,

I have been playing around with the dane check tool from sys4 too, and
it seems it doesn't support the nice CNAME trick shown in
https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022

The tool does not seem to follow the CNAME pointer, and concludes with
the error "No TLSA records." Seems to me a nice imporment if it would
support the CNAME trick ;)

Regards,
Tom

On 06-06-16 16:46, Viktor Dukhovni wrote:
> On Mon, Jun 06, 2016 at 03:58:51PM +0200, Alexandre Ellert wrote:
> 
>> I�ve juste enable DANE and https://dane.sys4.de 
>> is green when I test my domain numeezy.com .  Also
>> postfix SMTP client says "Verified TLS connection established to
>> mail-in-1.numeezy.com[188.165.154.163]:25: TLSv1.2 with cipher
>> ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)"
>>
>> Maybe some DANE expert here can definitely confirm that my setup is sane.
> 
> Yes, your DANE TLSA records match for both the primary and secondary
> MX hosts.  You've also *not* made the mistake of using the same
> certificate for both the primary and secondary MX hosts, thereby
> risking an outage of both when you replace a single certificate.
> And you're using "3 1 1" records which are stable when you renew
> your certificate with the same private key.  So overall, quite
> good, however you can do even better, see:
> 
> https://www.ietf.org/mail-archive/web/uta/current/msg01498.html
> 
> based on which I would strongly recommend:
> 
> _25._tcp.mail-in-1.numeezy.com. IN TLSA 3 1 1 
> cf43899685886c77e6e86d6a063c957df7858e7ea1bc3896b464fc6502685b48
> _25._tcp.mail-in-1.numeezy.com. IN TLSA 2 1 1 
> d765efb29fd40114afb1e830dbca8d1283e99086617ff18b07ad4ba58e7b0166
> 
> _25._tcp.mail-in-2.numeezy.com. IN TLSA 3 1 1 
> 8aee8995fca9c9cb89d0057f40b42cdcf23b1abc037681acd74af8c68b12a41e
> _25._tcp.mail-in-2.numeezy.com. IN TLSA 2 1 1 
> d765efb29fd40114afb1e830dbca8d1283e99086617ff18b07ad4ba58e7b0166
> 
> The above is based on the below observed DNS records, certificate
> chain and associated matching TLSA records:
> 
> numeezy.com. IN MX 1 mail-in-1.numeezy.com.
> numeezy.fr. IN MX 1 mail-in-1.numeezy.com.
> medialta.com. IN MX 1 mail-in-1.numeezy.com.
> medialta.fr. IN MX 1 mail-in-1.numeezy.com.
> medialta.eu. IN MX 1 mail-in-1.numeezy.com.
> mail-in-1.numeezy.com. IN A 188.165.154.163 ; passed
> _25._tcp.mail-in-1.numeezy.com. IN TLSA 3 1 1 
> cf43899685886c77e6e86d6a063c957df7858e7ea1bc3896b464fc6502685b48 ; passed at 
> depth=0
> ;
> ;Depth: actual=0, wire=0
> ;Subject = CN=mail-in-1.numeezy.com,O=Numeezy 
> SARL,L=PARIS,ST=Ile-de-France,C=FR
> ;Issuer = CN=StartCom Class 3 OV Server CA,OU=StartCom Certification 
> Authority,O=StartCom Ltd.,C=IL
> ;Valid from 2016-05-17T12:16:30Z until 2019-05-17T12:16:30Z
> ; _25._tcp.mail-in-1.numeezy.com. IN TLSA 3 1 1 
> cf43899685886c77e6e86d6a063c957df7858e7ea1bc3896b464fc6502685b48
> ; _25._tcp.mail-in-1.numeezy.com. IN TLSA 3 0 1 
> 50f417dbdab3677847eb0107d363044f4166eed1bb333daf6320d6b8daefb70e
> ; _25._tcp.mail-in-1.numeezy.com. IN TLSA 3 1 2 
> 5061dc02e6df14ad409acb5c2bb4992f80e1a5a1cc53faa5d81bd42d644010260e9a94747599c49df6b576981a6c6bf02b86764758c2bf4008ae6387f558a7c4
> ; _25._tcp.mail-in-1.numeezy.com. IN TLSA 3 0 2 
> b7b3d2036ad1d77d6c187e1f3fd9de28fc3f74af725a48c242bebc8eb1c4af56b06747bb1622cb27ef696f8741d09066d640768f9caa944a8981da174752a058
> ;
> ;Depth: actual=1, wire=1
> ;Match = mail-in-1.numeezy.com
> ;Subject = CN=StartCom Class 3 OV Server CA,OU=StartCom Certification 
> Authority,O=StartCom Ltd.,C=IL
> ;Issuer = CN=StartCom Certification Authority,OU=Secure Digital 
> Certificate Signing,O=StartCom Ltd.,C=IL
> ;Valid from 2015-12-16T01:00:05Z until 2030-12-16T01:00:05Z
> ; _25._tcp.mail-in-1.numeezy.com. IN TLSA 2 1 1 
> d765efb29fd40114afb1e830dbca8d1283e99086617ff18b07ad4ba58e7b0166
> ; _25._tcp.mail-in-1.numeezy.com. IN TLSA 2 0 1 
> ea4e5d2b9c99560f13dd094b8121a623bfdd902038dfd6d772ce32ffabec094d
> ; _25._tcp.mail-in-1.numeezy.com. IN TLSA 2 1 2 
> d26da4f0733b1f4af61f9db3c0e5bd6e379022e41038cb2cf7f38e273bdcaf98e0afd9b119e0fd85b090afec3d46020cbaee0158015666360ccc73418a0d3794
> ; _25._tcp.mail-in-1.numeezy.com. IN TLSA 2 0 2 
> 6a4bd383b21927f44f09263819d2917edbd8a8ea58d97dac48c26a1e88e5c7062691366f79300705da4b68b5bf9153477241f7603faf4ac03d1cde69abaef328
> 
> numeezy.com. IN MX 5 mail-in-2.numeezy.com.
> numeezy.fr. IN MX 5 mail-in-2.numeezy.com.
> medialta.com. IN MX 5 mail-in-2.numeezy.com.
> medialta.fr. IN MX 5 mail-in-2.numeezy.com.
> medialta.eu. IN MX 5 mail-in-2.numeezy.com.
> mail-in-2.numeezy.com. IN A 37.59.203.174 ; passed
> _25._tcp.mail-in-2.numeezy.com. IN TLSA 3 1 1 
> 8aee8995fca9c9cb89d0057f40b42cdcf23b1abc037681acd74af8c68b12a41e ; passed at 
> depth=0
> ;
> ;

Re: Special method required for Gmail dkim/spf verification

[Tom Hendrikx]

On 13-04-16 01:54, li...@lazygranch.com wrote:
> Google sent me a "fail" on my DMARC.  Everyone else seems happy. It
> turns out much like Google not accepting robots.txt for some search
> engines controls, they expect special fields in their DNS.
> 
> https://support.google.com/mail/answer/6227174‎

This page describes use of google's feedback loop. This has nothing to
do with spf, dkim and dmarc. It just gives you more insight into your
delivery results. Most large mailers have such a service, and they all
are specific to that party.

The additional dns records are used to verify that they give access to
the feedback loop to someone that actually owns the domain (or at least,
can add dns entries).

> 
> Why? Because we're Google and we can.
> 
You misunderstood.

Regards,
Tom

pflogsumm patch: SRS unmunging

[Tom Hendrikx]

Hi postfix users,

Ever since I added SRS to my mail setup, reading daily pflogsumm reports
got a lot harder since most senders were changed to SRS addresses. This
also threw off statistics since multiple sender addresses were used when
actually the sender was the same.

Attached is a patch for pflogsumm that unmunges SRS'ed addresses before
using them in the report. Basically I looked at how verp unmunging was
done, and copied that with a regex for SRS. The regex is based on the
SRS format found on Wikipedia and used in the papers in libsrs docs.

@Jim: maybe you could be so kind to include this in the next pflogsumm
version?

Kind regards,
Tom
--- pflogsumm.pl.orig	2016-03-24 11:07:30.806142020 +0100
+++ pflogsumm.pl	2016-03-24 11:36:39.468481189 +0100
@@ -17,7 +17,7 @@
 	[--rej-add-from] [--reject-detail ] [--smtp-detail ]
 	[--smtpd-stats] [--smtpd-warning-detail ]
 	[--syslog-name=string] [-u ] [--verbose-msg-detail]
-	[--verp-mung[=]] [--zero-fill] [file1 [filen]]
+	[--verp-mung[=]] [--srs-mung] [--zero-fill] [file1 [filen]]
 
 pflogsumm.pl -[help|version]
 
@@ -238,6 +238,18 @@
 
 		   See "NOTES" regarding this option.
 
+--srs-mung Undo SRS address munging.
+
+   If your postfix install has an SRS plugin running, many
+   addresses in the report will contain the SRS-formatted
+   email addresses, also for non-local adresses (f.i. 
+   senders). This option will try to undo the "damage".
+
+   Addresses of the form:
+ SRS0=A6cv=PT=sender.example.com=supp...@srs.example.net
+   will be reformatted to their original value:
+ supp...@sender.example.com
+
 --version  Print program name and version and bail out.
 
 --zero-fill"Zero-fill" certain arrays so reports come out with
@@ -496,7 +508,7 @@
 	[--rej-add-from] [--reject-detail ] [--smtp-detail ]
 	[--smtpd-stats] [--smtpd-warning-detail ]
 	[--syslog-name=string] [-u ] [--verbose-msg-detail]
-	[--verp-mung[=]] [--zero-fill] [file1 [filen]]
+	[--verp-mung[=]] [--srs-mung] [--zero-fill] [file1 [filen]]
 
$progName --[version|help]";
 
@@ -538,6 +550,7 @@
 "uucp-mung"=> \$opts{'m'},
 "verbose-msg-detail"   => \$opts{'verbMsgDetail'},
 "verp-mung:i"  => \$opts{'verpMung'},
+"srs-mung" => \$opts{'srsMung'},
 "version"  => \$opts{'version'},
 "zero-fill"=> \$opts{'zeroFill'}
 ) || die "$usageMsg\n";
@@ -795,6 +808,7 @@
 		$addr =~ s/(@.+)/\L$1/ unless($opts{'i'});
 		$addr = lc($addr) if($opts{'i'});
 		$addr = verp_mung($addr);
+		$addr = srs_mung($addr);
 	} else {
 		$addr = "from=<>"
 	}
@@ -1682,6 +1696,7 @@
 if(defined($from)) {
 	$rejAddFrom = $opts{'rejAddFrom'};
 	$from = verp_mung($from);
+	$from = srs_mung($from);
 	$from = lc($from) if($opts{'i'});
 }
 
@@ -1738,6 +1753,16 @@
 }
 
 return $addr;
+}
+
+sub srs_mung {
+my $addr = $_[0];
+
+if(defined($opts{'srsMung'})) {
+$addr =~ s/^SRS(?:[01])(?:[=+-])(?:[^=]+=[\w\.]+==)*(?:[^=]+=[^=]+=)([\w\.]+)=(.+)@[\w\.]+$/$2\@$1/i;
+}
+
+return $addr;
 }
 
 ###


signature.asc
Description: OpenPGP digital signature

[OT] Re: Is /usr/bin/mail a link to sendmail/postfix

[Tom Hendrikx]

On 14-03-16 17:05, @lbutlr wrote:
> On Mar 13, 2016, at 9:06 AM, Robert Chalmers 
> wrote:
>> Nice hardware, but the software is really recycled FreeBSD. say
>> what?
> 
> This should not be news. One of the reasons I chose FreeBSD for my
> servers was because I wouldn’t have to change modes between OS X and
> my servers.
> 

Hehe,

That is why I run ubuntu on my macbook. :P

Regards,
Tom



signature.asc
Description: OpenPGP digital signature

Re: Milter not to all messages

[Tom Hendrikx]

On 11-03-16 15:48, Alfredo Saldanha wrote:
> Is there some way to use milter check in a type of conditional ?
> In my situation here, it can not be mandatory to each message.
> I'm asking this because some users here want to receive all messages without 
> Spam verification.
> 
> Part of my main.cf:
> http://dpaste.com/3HFRR6V
> 


I;m using milter-manager [1] as a go-between for all postfix -> milter
connections. Milter-manager supports plugins for whitelisting and other
neat tricks based on envelope details (ip, sender, recipients), and is
easy extensible using ruby. WOrks very nice when off-the-shelf milters
don't support all exclusions you need, or when you don't want to
configure multiple milters in their own separate way.

[1] http://milter-manager.sourceforge.net/

Kind regards,
Tom



signature.asc
Description: OpenPGP digital signature

Re: 3.0.3: "mynetworks" values are busted and missing ipv6 info

[Tom Hendrikx]

On 09-02-16 12:14, Wietse Venema wrote:
> Quanah Gibson-Mount:
>> --On Monday, February 08, 2016 8:00 PM -0500 Wietse Venema 
>>  wrote:
>>
>>> Quanah Gibson-Mount:
 In Postfix > 3.0.x, the value from postconf mynetworks returns incorrect
 netmask values, and it is missing IPv6 entirely:
>>>
>>> This depends on the inet_protocols setting.
>>>
>>> # postconf inet_protocols=all
>>> # postconf mynetworks
>>> mynetworks = 127.0.0.1/32 192.168.122.1/32 168.100.189.7/32 [::1]/128
>>> [fe80::223:55ff:fe5c:3985]/128
>>
>> And the invalid netmask?  Which was the 1st part of what I was noting.  It 
>> should be 127.0.0.1/8 for example, not 127.0.0.1/32.
> 
> RTFM. Also in the RELEASE_NOTES.
> 
>   Wietse
> 
> $ man 5 postconf | less +/'^mynetworks_style'
> mynetworks_style (default: Postfix >= 3.0: host, Postfix < 3.0: subnet)
>The  method to generate the default value for the mynetworks parameter.
>This is the list of trusted networks for relay access control etc.
>   ...
> 
> $ postconf -d mynetworks_style
> mynetworks_style = ${{$compatibility_level} < {2} ? {subnet} : {host}}
> 

You could argue that "mynetworks_style = host" still should set the
subnet for 127.0.0.1 to /8, and not /32

Regards,
Tom

Re: Can anyone decipher this Policyd-spf error?

[Tom Hendrikx]

Hi,

As the ticket says, the error is caused by handling ipv6 addresses. When
you hit any troubles later, you could look into disabling ipv6 :/

Regards,
Tom

On 05-02-16 00:08, Danny Horne wrote:
> Thanks for both replies,
> 
> I've just checked and I'm running python-ipaddr 2.1.9, with no updates
> available.  I can live with the problem for now, I think this is the
> only time I've seen that error (though that doesn't mean it hasn't
> happened before).
> 
> Thanks again for your help
> 
> On 04/02/2016 9:34 pm, Scott Kitterman wrote:
>> On Thursday, February 04, 2016 04:19:54 PM Bill Cole wrote:
>>> On 4 Feb 2016, at 15:52, Danny Horne wrote:
 Hi all,

 I am getting the following error on just one email address from
 policyd-spf, called from Postfix.  No other email address has caused
 me
 problems (as far as I'm aware) and I had to completely disable
 policyd-spf in Postfix to allow the email through.  Can anyone
 decipher
 what the problem was?
>>> Only enough to be sure that the problem happened inside policyd-spf and
>>> that you're using the Python implementation, not the Perl one, since
>>> that log mess is a Python error trackback.
>>>
>>> These lines tell the immediate error:
>>>
>>> Feb  4 14:32:06 gallium policyd-spf[8810]:  File
>>> "/usr/lib/python2.7/site-packages/spf.py", line 1206, in dns_a
>>> Feb  4 14:32:06 gallium policyd-spf[8810]:return
>>> [ipaddress.Bytes(ip) for ip in r]
>>> Feb  4 14:32:06 gallium policyd-spf[8810]: AttributeError: 'module'
>>> object has no attribute 'Bytes'
>>>
>>> That would *probably* be meaningful to the developers of policyd-spf and
>>> perhaps to any good Python developer. To me it says "spf.py has a bug"
>>> but my guess is far from expert.
>>>
>>> Looks possible that this is your answer:
>>>
>>> https://bugs.launchpad.net/pypolicyd-spf/+bug/1229862/comments/3
>> I believe that's correct.  I just confirmed that ipaddr.Bytes (which gets 
>> used 
>> as ipaddress.Bytes in this policy server for python3 compatibility) was 
>> added 
>> in ipaddr-py 2.1.10, so running with an older version will cause that error.
>>
>> Scott K
> 
> 

Re: smtp-sink does not support all ipv6 addresses?

[Tom Hendrikx]

On 04-01-16 18:58, Wietse Venema wrote:
> Tom Hendrikx:
>>
>> Hi,
>>
>> I'm trying to setup a test environment using smtp-sink as a mail
>> receiver. For ipv4 I'm running smtp-sink on random addresses in
>> 127.0.0.0/8, and was looking for the same trick on ipv6. My OS allows me
>> to (ab)use :::0:0/96 for this, but unfortunately, smtp-sink does not:
>>
>> $ smtp-sink -v :::127.1.2.3:12345 100
>> smtp-sink: name_mask: all
>> smtp-sink: trying... [:::127.1.2.3]:12345
>> smtp-sink: fatal: bind :::127.1.2.3 port 12345: Invalid argument
> 
> The bind(2) system call rejects the address. Postfix is the messenger
> of bad news.  Don't blame the messenger.
> 
>   Wietse
> 

I did some rummaging in the source code to see what I'm doing wrong, and
found out that inet_listen.c sets the IPV6_V6ONLY flag on the socket
[1], which makes the bind(2) bail out. If I remove the setsockopt(2)
call and recompile, smtp-sink works as I hoped:

$ ./smtp-sink -v :::127.1.2.3:12345 100
./smtp-sink: name_mask: all
./smtp-sink: trying... [:::127.1.2.3]:12345

./smtp-sink: connect (AF_INET6 :::127.0.0.1)
./smtp-sink: vstream_tweak_tcp: TCP_MAXSEG 21888
./smtp-sink: fd=5: stream buffer size old=0 new=43776
./smtp-sink: smtp_stream_setup: maxtime=100 enable_deadline=0
./smtp-sink: helo test
./smtp-sink: quit
./smtp-sink: disconnect

I can see the use of the setsockopt call, since leaving it out has the
side effect that smtp-sink is also reachable on 127.1.2.3 (ipv4). On the
other hand, that behaviour is sort of what I requested when I explicitly
specified an IPv4-mapped IPv6 address.

So this means IMHO that IPv4-mapped IPv6 listen addresses are not
supported/explicitly disabled by postfix, it has nothing to do with
bind(2). Would be nice if that was mentioned somewhere.

[1]:
https://github.com/vdukhovni/postfix/blob/master/postfix/src/util/inet_listen.c#L145

Regards,
Tom

smtp-sink does not support all ipv6 addresses?

[Tom Hendrikx]

Hi,

I'm trying to setup a test environment using smtp-sink as a mail
receiver. For ipv4 I'm running smtp-sink on random addresses in
127.0.0.0/8, and was looking for the same trick on ipv6. My OS allows me
to (ab)use :::0:0/96 for this, but unfortunately, smtp-sink does not:

$ smtp-sink -v :::127.1.2.3:12345 100
smtp-sink: name_mask: all
smtp-sink: trying... [:::127.1.2.3]:12345
smtp-sink: fatal: bind :::127.1.2.3 port 12345: Invalid argument

$ smtp-sink -v :::7f01:203:12345 100
smtp-sink: name_mask: all
smtp-sink: trying... [:::127.1.2.3]:12345
smtp-sink: fatal: bind :::127.1.2.3 port 12345: Invalid argument

As shown below, postfix and smtp-sink are built with ipv6 support:

$ smtp-sink -v ::1:12345 100
smtp-sink: name_mask: all
smtp-sink: trying... [::1]:12345

smtp-sink: connect (AF_INET6 ::5b00:0:6e00:0)
smtp-sink: vstream_tweak_tcp: TCP_MAXSEG 21888
smtp-sink: fd=5: stream buffer size old=0 new=43776
smtp-sink: smtp_stream_setup: maxtime=100 enable_deadline=0
smtp-sink: helo test
smtp-sink: quit
smtp-sink: disconnect

And this is the way I want to actually connect to it (using postfix in
stead of smtp-sink, seems to work fine):

$ python3
Python 3.4.3+ (default, Oct 14 2015, 16:03:50)
[GCC 5.2.1 20151010] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> sock = socket.socket(socket.AF_INET6)
>>> sock.bind((':::127.1.2.3', 0))
>>> sock.connect((':::127.0.0.1', 25))
>>> sock.recv(1024)
b'220 tom-workstation ESMTP Postfix (Ubuntu)\r\n'
>>>

For the record: I'm hoping to be able to use an ipv6 address that is
available by default on a unix system (i.e. without explicitly setting
up an actual route-able address). Any ideas why this is isn't working?

Using postfix 2.11.3

Regards,
Tom

Re: reject connections from hosts without mx record

[Tom Hendrikx]

On 09-12-15 17:46, sb wrote:
> 
> In what follows, "(secure)" means authenticated DNSSEC response, 
> "(insecure)" means spoofable DNS response.
> 
>> ... Received: from spike.porcupine.org (spike.porcupine.org 
>> [IPv6:2604:8d00:189::2]) by english-breakfast.cloud9.net
>> (Postfix) with ESMTP id E5B44331FA3 for
>> ; Mon,  7 Dec 2015 13:19:20 -0500 
>> (EST) Received: by spike.porcupine.org (Postfix, from userid
>> 1001) id 3pDtFh4YYszJrQ6; Mon,  7 Dec 2015 13:19:20 -0500 (EST)
> 
>> unbound-host -rvD spike.porcupine.org

>> unbound-host -rvD postfix.org

> 
>> /opt/org.OpenServer/port-53/sbin/unbound-host -rvD
>> mail.cloud9.net

> 

Most DNSxLs are ip based, not hostname based. The client's ip is
provided by the tcp/ip stack of our own server. No DNSSEC needed.

> 
> Is there a good DNSWL we can use?
> 
>> unbound-host -rvD 7.1.100.168.list.dnswl.org
> unbound-host -rvD 7.1.100.168.list.dnswl.org

> 
> So, postfix.org e-mail originates from a non-whitelisted IP, 
> assuming we checked the right IPs for lack of DNSSEC.
> 

If you need more trust in DNSxL data retrieval, then sign up and pay
for list access, and be able to retrieve the data using a secure and
authenticated channel. Asking list providers to DNSSEC-sign their
zones would also be picked up a lot faster when you're a paying
customer (but I think that practical/technical reasons would make this
a hard nut to crack anyway).

If you're afraid that someone spoofs/hijacks DNSxL results, then
combine multiple DNSxL results into the decision using weighted
queries in postscreen. Spoofing/hijacking multiple DNSBLs is a lot
harder than a single one.

Your insistence on DNSSEC for DNSxL data is unnecessary and uncalled
for, IMHO.

> 
> Is there a good DNSBL we can use?
> 
> Let us check an IP that delivered spam.
> 

> Perhaps a less known RNSBL would do?
> 
> http://multirbl.valli.org/lookup/78-134-2-123.v4.ngi.it.html
> 
> No, it does not.

However, it does list the ip address for multiple lists, 9 at this
moment (of which a few I would trust to use on my servers).

> 
> In summary, the spammer's reputation is neither good nor bad. Just
> like postfix, the filter would let the e-mail through.
> 

Anyway, DNSxL usage is not about a single edge case, it's about the
big numbers: if you're able to block 70% of incoming spam quickly
using DNSBLs, it means you can spend more resources of the remaining 30%.

Kind regards,
Tom

Re: Throttling locally generated email

[Tom Hendrikx]

Hi,

You might want to 'replace' the postfix sendmail command with
mini_sendmail or something alike, and have that actually forward to
localhost:25 using SMTP. Then you can apply throttling on the localhost
ip, but lose the ability to see which local user was the source.


Tom

On 11-11-15 08:41, Benning, Markus wrote:
> On 2015-11-10 23:42, Donald Bindner wrote:
>> smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:10040
> 
> You may want to use a different restriction than recipient.
> The recipient restrictions are executed for every recipient.
> It gets executed multiple times if the mail has more than one recipient.
> 
>> However, this kind of rule seems to run only for mail "passing
>> through" my Postfix server and not for mail originating locally.  In
>> any event, the service running on port 10040 does not receive
>> connections from Postfix for mail that is generated locally.
> 
> If you mean real local submission by commandline, then you cant limit
> mails sent
> this way. The checks are only implemented by smtpd.
> 
> If you mean the submission server (port 587) then you may want to check
> your master.cf.
> May be it overwrites the option with different value like:
> 
>   -o smtpd_recipient_restrictions=
> 
>> I'd love if someone would show an example that "hooks this up."  I'm
>> confident that I have postfwd configured correctly to listen on port
>> 10040, I just need Postfix to talk to it.
> 
> No postfwd example, but mtpolicyd is also able to add quotas based on
> sasl_username:
> 
> https://www.mtpolicyd.org/getting-started.html#Mail::MtPolicyd::Cookbook::HowtoAccountingQuota
> 
> 
> 
> Markus
> 

Re: DSpam and Postfix

[Tom Hendrikx]

On 13-10-15 18:47, Phil Stracchino wrote:
> On 10/13/15 12:40, Viktor Dukhovni wrote:
>> Keep in mind that wildcard virtual(5) aliases can also break
>> recipient validation.  Any "@domain" keys in the tables for alias_maps
>> or virtual_alias_maps?
> 
> Nope, none.  There are @domain keys in relay-recipients, but they are
> all for domains I do not control for which I am a secondary MX relay.
> 
>> Otherwise, how might these invalid recipients be entering your queue?
> 
> A good question.  It appears to be only occurring with messages that are
> quarantined by DSpam and then subsequently redelivered.
> 
> 

I've seen this issue before: dspam sends a garbled RCPT (binary data,
IIRC) when trying to deliver the quarantine message to postfix. Never
found out why, I stopped using dspam quarantine (and used tag and
deliver to spam folder).

The original message as received by postfix has no problems. You could
try to find the postfix logs for the incoming message by looking at the
message id in the dspam quarantine, but the bug here is in dspam.

--
Tom

Re: RegExp help

[Tom Hendrikx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 14-05-15 12:48, Barbara M. wrote:
 
 I am trying to use regexp to block mails from specific domains to 
 specific users (and let other users receive it).
 
 I need to merge (logical AND operator), something like:
 
 /^From:.*\@.*domainsource.tld/  REJECT  No Unrequested mail
 Please /^To:.*\@.*domaindest.tld/  REJECT  No Unrequested mail
 Please
 
 For my needs I want these rules evaluated in AND.
 
 How can do this with a valid rules in my
 /etc/postfix/header_checks? If there is a better solution ... ;-)

Header checks doesn't do AND for multiple headers, all headers get
evaluated separately. For this idea, you'd need a content filter.
Within Spamassassin these kind of rules are trivial.

Regards,
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVVI2KAAoJEJPfMZ19VO/188wQAKPF4NagLlnxnkTX7/7nCBEF
X9Fa4SvVocYFhA9dz9csmT6bN1vmADnkDHl02vAvBIhWszu5ghESI57/oeVhfuXn
9oapH/cfx6xuj4xsoA92zV0FuPfQu9jEUIC7rEi3A8K7nmjGTs3M/isU/8YiQn4C
hsORxhaKP2WCLylUk6KdOhrObZ3KlJwaIEETSl146g/ZG53YSJFeG29Zp/ksFu+H
5+VZEPnWb1sbwG6H59uUQ4vY+V/63fw6aZYfUdD3xgFuZbdJO738BoI/lLc8KssU
L+b5isQhq0D78pLPlMkG9dkKjHyZXCuhkTEAvtbZGxy/Rfz86toafr7IZq8GaYuh
XPM2KYzOZeDqeM53BWQ0UF0XR/jx4yBi1wQd7un1wJA+ZFGLxhlQdSav5Vt7y8Et
4UAAzWZ3jT+ESVJQ+3OlDin+ge4i8xNYKH28hxS5KDktkAk0k5tCpesn67jt+gqQ
CacO7tSYL6zJyrVDIXqwZIDtu1hQh3fo6Sty/Xi6B5MRBt0YCj4bv6qNW7PtuNQm
oQ3NEDex2PdsVS0E2JDaaLG+aSdWeSesWHvO6H4CWe1hdKHKDHwfVMTBBBZZ8Y/v
aXoMItPDM+mhp2MjvKza0RLQZWYZ9ig7yYQzlMQGoiMvZEKES5ZOX1BUMxIiBzuk
nVwTf7NZmlvgWPcqL0os
=s6lF
-END PGP SIGNATURE-

Re: postscreen feature request

[Tom Hendrikx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

If you want to block more DUL ip blocks, the easiest way is probably
to use some upstream DUL DNSBL providers, and use rbldnsd to create
your private DNSBL to provide your own additions.

There also is a community-maintained pcre file for smtpd restrictions
(located at: http://www.hardwarefreak.com/fqrdns.pcre), that will
block many of your candidates at the smtpd level.

You could probably get fail2ban or some homegrown logparser create
additions to your rbldnsd input file based on the rejections (i.e.
postscreen passes, smtpd blocks, ip(-block) is added to rbldnsd,
postscreen blocks at next connect).

Tom

On 10-03-15 16:16, Kovács Albert wrote:
 On Tuesday, March 10, 2015 1:42 PM, Wietse Venema
 wie...@porcupine.org wrote:
 
 
 
 I'm not sure how one (type of) dns query is a performance
 concern, and another is not, see below.
 
 You see no performance difference between querying a small
 number of well-operated DNS servers that are chosen by the local
 sysadmin, versus random DNS servers all over the Internet that
 are determined by the sender's IP address?
 
 
 this isn't exactly what i wrote :-) Obviously querying PTR records
 may take some time. However, smtpd also needs the PTR record to
 perform some DNS tests, so sooner or later you need the query.
 
 OK, postscreen blocks many of the zombie hosts for sure, so you
 don't need to perform PTR queries for that many times, however
 (based on my experience) lots of hosts with names like
 ppp|dsl|cable|-xx-xx-xx-xx.some.provider.com pass postscreen
 ending up at smtpd.
 
 
 Anyway I started to use an RBL targeting dynamic IP blocks, and it
 makes postscreen dropping many such zombies, though no RBL is
 accurate, so I believe there's still some room for optimization.
 
 If there's some deeper guide or you could provide some hints on how
 postfix does dns resolution, I'd appreciate it, and perhaps I could
 make it for myself.
 
 With postscreen, zombies don't get to occupy smtpd processes, by 
 using DNSBLs and pregreet tests.
 
 
 unfortunately not all of them, that's why I'd improve postscreen to
 have a better hit ratio.
 
 
 Albert
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJU/yPbAAoJEJPfMZ19VO/16YwQAMCbKHTgIcbltHWd1btMZfcl
E5BMs3ILcTK0+ABWJu9F4337SmWbZD/hOjO1F0JTi2UjfvmeyGGLGa+mjrRc2jSS
2I9UhqKF6wv/HI8O39P1NIYkoskav3Vlcimz5bRxtQAQPfhA8wcYiVM+Dun6R90G
YgZgjK3YiJOPNtfAvf+iiGPbKst7k/RVgRvyLHq/lcbm8+ykLh5DRvw0Gf2ENlmL
ImTClziBYFBvlJuLI9ECZu8RkSCl/5y3tNibjtUgktAUtRXO5jFg6oK0ht1E8hBK
qMtRxhQ4Z1nJ8KBz/FR/SiX1qL/kg9TzL+ab5FspzfMxA03GhEVl/CNz7CtU8sUB
dNfUayIMRq+5bwxJquixK+ux+8213AqOt5SGtX5sOGw5gLH2NGNk2wHQnZlyzN0n
6CvX0L1ESASRSJCpn2Ipc85EuuYoIE1njVNJiaaSZGE7TEadaCq9Xl9XTFjGOA+N
/+mLXd4GgUB+Liuyjs/sxYZbc2KqlY8L4t8a0N0K0gLsTy1ZFnffiUqUJD2crrcm
3PilFNV2dv4Oxj93VbaXAsF4FndGXPfcjs862ct21FIzO+Sbf+SDEdQperxI6ep+
6fEh0/mNQd+464zcMb0NtaVIrXJ+RhM/FHG+3kOhHuKwtxRslQNplH2lbWWxfquI
Tkkf6BBb5sHKTT1W4q0M
=7U0a
-END PGP SIGNATURE-

Re: Testing DANE-enabled smtp client

[Tom Hendrikx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 15-11-14 00:00, Viktor Dukhovni wrote:
 On Fri, Nov 14, 2014 at 10:58:08PM +0100, Tom Hendrikx wrote:
 
 Nov 14 22:55:56 hostname postfix-out/smtp[11505]: Verified TLS 
 connection established to mail.sys4.de[2001:1578:400:111::7]:25:
 TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits) Nov 14
 22:55:57 hostname postfix-out/smtp[11505]: 66FCB8049: 
 to=e...@sys4.de, relay=mail.sys4.de[2001:1578:400:111::7]:25, 
 delay=0.83, delays=0.16/0.05/0.17/0.45, dsn=2.1.5,
 status=deliverable (250 2.1.5 Ok)
 
 Do keep in mind that if your /etc/resolv.conf does in fact list 
 remote DNS caches, the reported security can be illusory.  Run a 
 local unbound listening on 127.0.0.1, list only that in
 /etc/resolv.conf, and don't let DHCP or other automation replace
 this with some remote nameserver.
 

As described, I run multiple VMs on a single piece of hardware. All
the VMs on that hardware are under my control. I understand the
implications of running a remote dns cache, but am comfortable in
deciding on the risks.

The repeated *very* pressing advices on this subject in earlier
threads made me think that postfix enforced this setup in the first
place, which proved to be an incorrect assumption. I'm glad I have
more options to choose from.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUZ1YxAAoJEJPfMZ19VO/1Pq0P/iQZN9oPLa0NIKLfloBE8YyH
oLuAc/UApS01Xck7UxnvGPflm5KgZ5QKPsEcPpOu3RrRbqxEngEikoYcPqCxCQwn
ENW/mFxya2KgMdPqJuqWMb++CZ96pwYaesJh6sPD2p3Z6X8lzYqxa+XFclg4UsmE
hkS7Elj6/ptKhRdzJx9wWvBcT6X82HcPprnR4vbPyTBAuVOjkjR4+pkIoKadpMT/
dz6Ox7zyXTl1Nchys+BG9mH3uytrE9RgDHJwyAVY8A4XRiQDUXaH7nuMhz80Wnah
d2LHpZEuYEWK5M652hVIzAacVPEBN1ofztIivU3xhfztt32/9am22AiOpXZtKEeh
kcfYvLBH6doFOHbQC1wH3zhKRyKKyavV533rrkCYpCRhLnqeYlQVGZHoGFduvc1Y
7vm2UpobcRY0oIvJnrhDjg8mXoh3FtLNg+BzCbe+t3KdJB+d6KKjhAuviIwTmgaB
yPiUHVq5MnTsVxDkX4TwXc/JBTv5hvhV5wUmuFzj7UOzHVT8FLfHb0S6GjL2E3Vu
xQXtqlaFTJDruckjeigtTVs/nDNUwYjGFwDf1CjUX//Rk9iA+8n+S1uEwO83R1H7
xFt5ssc8BWEBQUKlVLO+X0lCSGV4onnRa+jOSYSi1hU1janz0Zie8yK/b0VqGFoQ
EFJdewyDknOWyRgX+X67
=MRSY
-END PGP SIGNATURE-

Testing DANE-enabled smtp client

[Tom Hendrikx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

I configured my mailserver to use DANE for outbound mail whenever
possible, but I am having a hard time in verifying that this actually
works.

When I use posttls-finger from the machine, it indicates Verified TLS
connection established when i point to a few mxen that are known to
have TLSA records available (because they were announced here).
However, this does not test postfix itself.

One notable difference between posttls-finger and postfix (as
described in the documentation) is that postfix would only use the
TLSA record for deciding on a verified connection when the resolver
is running on localhost, while posttls-finger also accepts dnssec data
from a remote resolver (I run unbound in a different VM on the same
piece of hardware).

My guess is that I would actually need to send a mail to someone that
has TLSA records published in order to test my postfix setup, and then
check the local logs.

Am I wrong in understanding the docs, or is there actually a
difference in the restrictions on resolver usage between
posttls-finger and postfix. If so, would it be useful to keep these in
sync, or add a switch to posttls-finger to enforce this behaviour for
testing purposes?

Finally, does anybody have an email sinkhole available on a DANE
enabled server where I can send some test messages?:)

Kind regards,
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUZm2AAAoJEJPfMZ19VO/1L6cQAJkfg2GEifxL1dKJuU2xawxI
FY4RM+SeisK9PkpgOvizgDFjAvUOGnFH0m32BR7euG93jhLL4L87LBSnTE1MxXsh
emE6HDUdz4e9iCs55AD0MHbSQQvjStAoIlzBG2h92cKZSZpBBL/29HjgRI2w0iia
fUlx/7F8xq+Z41wH+Tq5GbMue23uHd5f2qiqZZyQTkgYTi8e5neamGaOY1xYH7Ab
rFv+CeJKfiA6PU9aUDX4X2d66uX+NDc5YfUr2w9X54TEXi0tH5o3CJ+Svgq1z+b/
5RB8UTu6BXHCpGAkrl3GrYt89IqjZJg1FzJwUrxqeHSP3waSTABtkdpPdhDBS2td
ox5ybFo7KFJMM6pNVe9sQGmQxI744OA6D95oqF42yQE4+NV5NCNMRAgegLlR4l2U
MfPd/NxHK3SE+bCUTjht+Z3hYvph5wEo7LMpHayeXKNuzUSASczbWO1HJQ2WCSif
5SWV0tPzaaksZ7O4NFqCnmY6ZDnu/RgEXvNz0Rdf4S6UHdkRQf/VsHv76/vLxbEp
a3Ybgv1ykAUc8wfOgx0TQaXcoZQjJTtG5+dvIgX26r1PL0Qd04/suGQh1QU/zcxl
8TA8SL6UtJDkQwJYgWPUzr/zS1TP9GMxYW27ZGMhPtDOE4+QY+jTYF0MdzYRRJs/
Yb1LUBESAixqjXBUg/h0
=UUw1
-END PGP SIGNATURE-

Re: Testing DANE-enabled smtp client

[Tom Hendrikx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 14-11-14 22:27, Viktor Dukhovni wrote:
 On Fri, Nov 14, 2014 at 10:01:02PM +0100, Tom Hendrikx wrote:
 
 One notable difference between posttls-finger and postfix (as 
 described in the documentation) is that postfix would only use
 the TLSA record for deciding on a verified connection when the
 resolver is running on localhost, while posttls-finger also
 accepts dnssec data from a remote resolver (I run unbound in a
 different VM on the same piece of hardware).
 
 Postfix will use (and wisely or otherwise trust) whatever resolver 
 is in /etc/resolv.conf.  If that's remote, and subject to MiTM 
 attacks, that your problem.  If you have a secure IPsec tunnel to a
 trusted resolver, feel free to use it.  You can even use remote 
 resolvers over untrusted networks, and expose yourself to active 
 attacks.
 
 My guess is that I would actually need to send a mail to someone
 that has TLSA records published in order to test my postfix
 setup, and then check the local logs.
 
 The posttls-finger and Postfix code exercise very similar
 verification logic.  You can use sendmail -bv to test without
 actually delivering the mail.
 
 /usr/sbin/sendmail -bv postmas...@example.net
 
 then check the logs.
 
 Am I wrong in understanding the docs, or is there actually a 
 difference in the restrictions on resolver usage between 
 posttls-finger and postfix. If so, would it be useful to keep
 these in sync, or add a switch to posttls-finger to enforce this
 behaviour for testing purposes?
 
 There is no difference.  Both use the same DNS library in the same 
 way.
 
 Finally, does anybody have an email sinkhole available on a DANE 
 enabled server where I can send some test messages?:)
 
 The sendmail -bv command probes a server without sending mail.
 

Thanks for the quick responses. That indeed works:

Nov 14 22:55:56 hostname postfix-out/smtp[11505]: Verified TLS
connection established to mail.sys4.de[2001:1578:400:111::7]:25: TLSv1
with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
Nov 14 22:55:57 hostname postfix-out/smtp[11505]: 66FCB8049:
to=e...@sys4.de, relay=mail.sys4.de[2001:1578:400:111::7]:25,
delay=0.83, delays=0.16/0.05/0.17/0.45, dsn=2.1.5, status=deliverable
(250 2.1.5 Ok)

Regards,
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUZnrwAAoJEJPfMZ19VO/1vgEP/jYQG5iQfKWMxZgiYRJZ3y8R
QnkkuUJLEJsa6u+JeEYoPZG3iNcL3nUrCG7F6WE8sirFWHFDQ/I/iL3lTyUw9xM0
I3ysvS8iQo9i5fgb6ixix+3zzPFGlh5eKiqHpdwpG9PeZgUcd0AGEj+4UUqbh4ty
VvNEk1Xfz7cCxenByurJFNzYIuWNq53VuSgVQu+Oaia0RqFmGW/Pm+YV2e3YGIN8
fu3HKEjZPlXDq7L17KeNfFUDkLoWk4rDWXZoYb/7yGV7JQzrpJwuTzTGMp602FUJ
0zUsOaK/PowymqlMpBrlcvdOdfJ+7hrtAPCN5VcHAT3VxUkUutw3pD/J2a7fB0qJ
UnW3En4CyYu+Si0xb1hGAh2sYFg8FllaJbkIjHnkWf5aLOdTmhuYoEbHk2QXNz8l
g3CY9oMwc3oxyMVt8UJnC7DV1XMYQZcKAyPCDO1azAem8mrbfwx1vLorR78a6CX3
lAlDtGeurTq12Kwz4sSg89sybnfI5yo/R8Tiq/t/5el/Hsk1Tyig0LwQwUDpb4JE
Lxvj8pY+rdOPjOypiIZy9wCEseTBBdXarw3ulJo2Yk3hmmxwA1xW4pFdJDqRw/0k
OuS9BnKku9OdAV/5MGY6rcASlkmWnfZ6WIDjCtHzUeSEmZuabsRV91TSTKqAmFaw
9XgJqCX6QZRw+N5H53dL
=X3Z2
-END PGP SIGNATURE-

Re: Logging for 'too many hops' issue

[Tom Hendrikx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 18-09-14 17:28, Wietse Venema wrote:
 Tom Hendrikx:
 However, it seems that the error message is only sent in the
 smtp dialog (554 5.4.0 Error: too many hops), postfix logging
 does not show anything. All I get in non-verbose logging is:
 
 Sep 18 12:38:58 test postfix-inbound/smtpd[29852]: connect
 from localhost[127.0.0.1] Sep 18 12:39:05 test
 postfix-inbound/smtpd[29852]: 3hzHmT118bz317f: 
 client=localhost[127.0.0.1] Sep 18 12:39:17 test
 postfix-inbound/smtpd[29852]: disconnect from 
 localhost[127.0.0.1]
 
 Is there a way to detect a 'too many hops' issue from the
 logging, preferably without changing postfix verbosity?
 
 Does the SMTP client log the rejected command (like Postfix
 does)? If not, which program should be changed?
 
 Asking this, because the client runs on the same machine
 (connecting from localhost[127.0.0.1]), so you might have the
 information already.

The logging was generated from a test suite. Real life situations
wouldn't use localhost.

 
 This works great for f.i. dnsbl rejects, but for some scenarios,
 there is no suitable message in postfix logging to work with.
 This basically means that we have to tell customers 'we don't
 know for sure, but try and ask third party who might have sent
 it', which sucks for obvious reasons.
 
 We also had similar issues with exceeding message_size_limit in
 MAIL FROM command, which does not log the sender e-mail address,
 making it hard to actually find the relevant log entries when
 questions are asked: there is only a timestamp + sender ip to
 work with.
 
 But from your remark about 'which program should be changed', I
 may conclude that this is not possible?
 
 There are tons of 5XX server responses without logging.  To begin 
 with, Postfix generally does not log SMTP command name or command 
 parameter errors because that could easily be mis-used to jam up 
 the logfile with garbage.
 
 However, the cleanup daemon should probably log when it sets the 
 hop-count error flag, just like it logs when it sets the write 
 error flag.
 
 Wietse
 
 --- /var/tmp/postfix-2.12-20140907/src/cleanup/cleanup_message.c
 2013-11-12 12:53:03.0 -0500 +++ ./cleanup_message.c
 2014-09-18 11:10:32.0 -0400 @@ -580,8 +580,11 @@ if
 (hdr_opts-type == HDR_RESENT_MESSAGE_ID) msg_info(%s:
 resent-message-id=%s, state-queue_id, hdrval); if (hdr_opts-type
 == HDR_RECEIVED) -if (++state-hop_count =
 var_hopcount_limit) + if (++state-hop_count =
 var_hopcount_limit) { +   msg_warn(%s: message rejected: hopcount
 exceeded, +   state-queue_id); state-errs |=
 CLEANUP_STAT_HOPS; +  } if (CLEANUP_OUT_OK(state)) { if
 (hdr_opts-flags  HDR_OPT_RR) state-resent = Resent-;
 

That looks promising. Thanks :)

Kind regards,
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUHBKQAAoJEJPfMZ19VO/15FoP/0if+36VvgIx/2GVDepmwu+z
ivvehqTHROhmXr5Q2KiOmEnAGqzi5lU6l9uhEL3qy+ZWsWBN+F1UgEiX9CexH2Kr
L7zJWdceIN9tEhZ6hU24NXSO8ex16TjFBcZ6GNR9uYPeiyM1VvFOM/ju1DtadFxe
vfIE+uhxhVcpuKYnHJCXYiDcGH8DLLgCBgPNirGPxVPadwcBt4mW2s8EsRF9+Xea
rItqUFdbDw7n9MauBb0J8itjaYkNI0Layjr1Fny3cnYhulZbAqCqBK5yg4vrXF6L
NIJSszFXDekylrzRAyXqSSPscg0ZdZgVjBezlR2nj2qWbfT3e4Rp973LdMAPamDU
pWjWXN0k7xos7015i8Z2Yoyqw3M6Kbfl/Gex3X2TFhu/QpJU/b+7t+9IHsbMNUEG
+GkgvoeQdusJlN0F/KSg06E/hMgs/8YrC0uxQgAY9CWjo9e+rWIP+eLv8X6myOry
tyJ1WnUs8ZVbYzIF9bZbX2PuutIZyzYXUyBtFwamdYtWixhRb2bychna6f6GXDSY
UMoZDt/1lZa5CVlvOPsfbrW0GcX85oMta77se6XY+8G8BL4T5Y00lA4yaA6Xlhkj
y3bEbHQOieEGdjQjtkLI/jalQiuB0mqklH94ANfKSuuN8LRjgd+Ww5DNAJ8qhgMC
GOu9StnbBki74c+w6YBR
=iwpq
-END PGP SIGNATURE-

Logging for 'too many hops' issue

[Tom Hendrikx]

Hi,

We're currently in the process of parsing postfix logs into something
that is suitable for end users. After covering lots of basic errors, we
are working through some edge cases. Since we use customer provided data
for relaying mail, there is a possibility that something gets
mis-configured and we get 'too many hops' and related issues.

However, it seems that the error message is only sent in the smtp dialog
(554 5.4.0 Error: too many hops), postfix logging does not show
anything. All I get in non-verbose logging is:

Sep 18 12:38:58 test postfix-inbound/smtpd[29852]: connect from
localhost[127.0.0.1]
Sep 18 12:39:05 test postfix-inbound/smtpd[29852]: 3hzHmT118bz317f:
client=localhost[127.0.0.1]
Sep 18 12:39:17 test postfix-inbound/smtpd[29852]: disconnect from
localhost[127.0.0.1]

Is there a way to detect a 'too many hops' issue from the logging,
preferably without changing postfix verbosity?

Kind regards,
Tom



signature.asc
Description: OpenPGP digital signature

Re: Logging for 'too many hops' issue

[Tom Hendrikx]

On 09/18/2014 03:22 PM, Wietse Venema wrote:
 Tom Hendrikx:
 We're currently in the process of parsing postfix logs into something
 that is suitable for end users. After covering lots of basic errors, we
 are working through some edge cases. Since we use customer provided data
 for relaying mail, there is a possibility that something gets
 mis-configured and we get 'too many hops' and related issues.

 However, it seems that the error message is only sent in the smtp dialog
 (554 5.4.0 Error: too many hops), postfix logging does not show
 anything. All I get in non-verbose logging is:

 Sep 18 12:38:58 test postfix-inbound/smtpd[29852]: connect from
 localhost[127.0.0.1]
 Sep 18 12:39:05 test postfix-inbound/smtpd[29852]: 3hzHmT118bz317f:
 client=localhost[127.0.0.1]
 Sep 18 12:39:17 test postfix-inbound/smtpd[29852]: disconnect from
 localhost[127.0.0.1]

 Is there a way to detect a 'too many hops' issue from the logging,
 preferably without changing postfix verbosity?
 
 Does the SMTP client log the rejected command (like Postfix does)?
 If not, which program should be changed?
 
   Wietse
 

We provide an interface where the customer can lookup details about
their mail flow. The idea is that customers can use the interface to
find their mail delivery details, and more importantly, that it can also
tell them when a mail was rejected.

This works great for f.i. dnsbl rejects, but for some scenarios, there
is no suitable message in postfix logging to work with. This basically
means that we have to tell customers 'we don't know for sure, but try
and ask third party who might have sent it', which sucks for obvious
reasons.

We also had similar issues with exceeding message_size_limit in MAIL
FROM command, which does not log the sender e-mail address, making it
hard to actually find the relevant log entries when questions are asked:
there is only a timestamp + sender ip to work with.

But from your remark about 'which program should be changed', I may
conclude that this is not possible?

Kind regards,
Tom



signature.asc
Description: OpenPGP digital signature

Re: header_checks and REPLACE

[Tom Hendrikx]

On 08/11/2014 01:00 PM, li...@rhsoft.net wrote:
 Hi
 
 http://www.postfix.org/header_checks.5.html
 
 RULE:   /X-Virus-Scanned/ REPLACE X-Virus-Scanned: Yes
 BEFORE: X-Virus-Scanned: clamav-milter 0.98.4 at testserver.rhsoft.net
 NOW:X-Virus-Scanned: Yes
 
 so far, so nice
 _
 
 but in case of X-Spam-Status i am out of ideas to get only the 
 version=3.4.0
 away to not leak software versions and if possible the wrong 
 UNPARSEABLE_RELAY
 and i am even not sure if it is possible at all
 
 the rest of the SpamAssasin header should stay untouched
 
 X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY 
 autolearn=ham autolearn_force=no version=3.4.0
 

If you don't like UNPARSEABLE_RELAY, then just disable the rule in
spamassassin. For the formatting of the header, it's probably easier to
use spamassassin itself:
http://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Conf.html#template_tags


Tom



signature.asc
Description: OpenPGP digital signature

Re: header_checks and REPLACE

[Tom Hendrikx]

Hi,

you already did this, but I'll point you to the correct chapter anyway:
RTFM :)

http://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Conf.html#scoring_options

You could probably do everything you want with REPLACE and
backreferences in the regular expressions too, but why complicate things
when unnecessary. You're too experienced (and large-mouthed :) to not
know that security cannot be obtained through obscurity. Header munging
is almost always the wrong solution.

Tom

On 08/11/2014 01:59 PM, li...@rhsoft.net wrote:
 thanks looks good
 
 X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY 
 autolearn=ham autolearn_force=no
 no idea wher the UNPARSEABLE_RELAY comes from and how to disable it :-(
 
 however, i am still interested in REPLACE just for things
 like /192\.168\.196\./ REPLACE /84\.113\.92\./
 
 Am 11.08.2014 um 13:51 schrieb Erik Logtenberg:
 Why don't you simply configure SpamAssassin to not put the version
 number in the header to begin with?

 You can use directives like clear_headers, add_headers in your local.cf
 configuration file to configure these.

 For instance I have these two lines in my local.cf:

 clear_headers
 add_header all Status _YESNO_, score=_SCORE_ required=_REQD_
 tests=_TESTS_ autolearn=_AUTOLEARN_

 This gives me headers like this:

 X-Spam-Status: No, score=-7.0 required=5.0
 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_HI,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL
 autolearn=ham

 On 11-08-14 13:00, li...@rhsoft.net wrote:
 Hi

 http://www.postfix.org/header_checks.5.html

 RULE:   /X-Virus-Scanned/ REPLACE X-Virus-Scanned: Yes
 BEFORE: X-Virus-Scanned: clamav-milter 0.98.4 at testserver.rhsoft.net
 NOW:X-Virus-Scanned: Yes

 so far, so nice
 _

 but in case of X-Spam-Status i am out of ideas to get only the 
 version=3.4.0
 away to not leak software versions and if possible the wrong 
 UNPARSEABLE_RELAY
 and i am even not sure if it is possible at all

 the rest of the SpamAssasin header should stay untouched

 X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY 
 autolearn=ham autolearn_force=no version=3.4.0






signature.asc
Description: OpenPGP digital signature

Re: SPF and leboncoin.fr vs sfr.fr

[Tom Hendrikx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 28-05-14 17:11, Daniele Nicolodi wrote:
 Hello,
 
 this question is not strictly related to Postfix but I don't know
 where else I may find knowledgeable people to ask about the issue.
 
 leboncoin.fr is classifieds website and it offers the possibility
 to answer insertions through a web form that sends an email to the 
 insertionist. The form requires to specify the email of the user 
 answering and it is used as From: for the sent message to allow
 replies.
 
 My domain implements SPF, and I have a few reports of emails
 generated by the web system and sent to sfr.fr addresses that has
 been refused by the receiving system on the base of the SPF record
 of my domain. Accidentally, leboncoin.fr uses Postfix as mailer,
 and this is an example of the reports generated:
 
 This is the mail system at host vmailer19.leboncoin.fr.
 
 I'm sorry to have to inform you that your message could not be
 delivered to one or more recipients. It's attached below.
 
 For further assistance, please send mail to postmaster
 
 If you do so, please include this problem report. You can delete
 your own text from the attached returned message.
 
 The mail system
 
 ndiberna...@neuf.fr: host smtp-in.neuf.fr[93.17.128.86] said:
 554 5.7.1 dani...@grinta.net: Sender address rejected: 
 Please%see%http://spf.pobox.com/why.html?sender=daniele%40grinta.netip=193.164.196.119receiver=msfrf2411

 
: Reason: mechanism (in reply to MAIL FROM command)
 
 
 
 Reporting-MTA: dns; vmailer19.leboncoin.fr X-Postfix-Queue-ID:
 5C8B0B8D55 X-Postfix-Sender: rfc822; dani...@grinta.net 
 Arrival-Date: Wed, 28 May 2014 16:02:28 +0200 (CEST)
 
 Final-Recipient: rfc822; ndiberna...@neuf.fr Original-Recipient:
 rfc822;ndiberna...@neuf.fr Action: failed Status: 5.7.1 
 Remote-MTA: dns; smtp-in.neuf.fr Diagnostic-Code: smtp; 554 5.7.1
 dani...@grinta.net: Sender address rejected: 
 Please%see%http://spf.pobox.com/why.html?sender=daniele%40grinta.netip=193.164.196.119receiver=msfrf2411

 
: Reason: mechanism
 
 
 Is the problem due to leboncoin.fr getting the mail forwarding
 wrong by using the wrong envelope sender address, or is sfr.fr
 getting SPF wrong by using the From: header sender address to
 verify SPF?
 
 There is anything I can do to help those mail to go through
 correctly?
 
 Thanks. Best regards, Daniele
 

Hi,
SPF is failing because the website using the email address entered at
the website as the smtp envelope sender.

The proper way to fix this issue is to convince the website owner to
change their mail form. The easy way is to change your SPF record,
like Robert suggested.

Tom

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJThgEoAAoJEJPfMZ19VO/1G3cP/3l3u2voY+bbFWoX2xt6jlmP
hNlA+oPhS/gJRTDwtORWWExoR26Skp5uR/Zo5Ag6REDJjQS5Qb3l2FKVRPWdfbBg
We0GVGvvCwFefcRGhwF2VXkPkbaVMHHCUciBidw5rXMznZkqOaBGJtU4OXQ1qW8/
ohoiliz+eXd1v+VGArPdKidQFtUJ6k/Ft+7IviQFJxnJkLeo+PRrtfIGNNbKXCmp
Nz45SpduformSMPREeQdArx9OhBmx2I+NKbZG4mkOnGHTQIdMDCTxA8dGtpjbDkS
XCfN/cYDmnA31wWH8GZj7nvCFOXL2+PENyMa141GBD/G9jpbaUny5PspbZz9+H+T
huMUQvVOAmkly7/rtH6dLXH1pHKnE++Kvs0AwAsnZN1DChrdByxoWjGyBMHGS/6x
mdFnMBeoehiTz9h5NG5qkyzbVb/Go5o1qoDihW+Wkq9OeoyR2Bmfc5TQGMHpvc9s
TZuwiFC3GXo4qCU5wHy8gR43ICDg5pIRIzAfRhTSe9m9uWzxK/Yw2gldWDHyu9+p
2sc7/A3Y/ugpiUzdkfk3TC+u+KVGXMF3qmKg2MPcYoW7nDGFUtKRwjMLRHMIz+yY
7znWrfURoZueJK7JUY7Ce93Di32MAe+/CEkyTiLOdXrhQVFSA/rUzpeN9QelHZ0Z
A2fQwoI80PdyLcW6GTSu
=R3Pe
-END PGP SIGNATURE-

Re: Understanding postscreen timeouts

[Tom Hendrikx]

On 05/02/2014 03:15 AM, Alex wrote:
 Hi,
 
 On Thu, May 1, 2014 at 5:38 PM, Wietse Venema wie...@porcupine.org
 mailto:wie...@porcupine.org wrote:
 
 Alex:
  I'm using postfix-2.10.3 with fedora20 and have configured
 postscreen with
  spamhaus, barracuda, and a few other DNSBLs. I'm however occasionally
  receiving the following timeout message:
 
  May  1 17:15:01 mail01 postfix/postscreen[4429]: warning: dnsblog
 reply
  timeout 10s for swl.spamhaus.org http://swl.spamhaus.org
 
 This time limit has unfortunately escaped my attention.  It is not
 yet configurable.
 
 The warning message means that postscreen gives up waiting for the
 DNS lookup result. This is a safety mechanism.
 
  I'm also using a half-dozen RBLs, but they don't all always timeout.
 
 I see occasional timeouts on residential and co-located servers.
 By default the resolver *system library* routines wait 5s before
 retrying; this may be configurable in resolv.conf, but the
 postscreen time limit is still hard-coded.
 
 
 These are both corporate 10mbs dedicated links and I don't think latency
 and/or bandwidth is a problem.
 
 It actually appears swl.spamhaus.org http://swl.spamhaus.org is the
 main problem. It doesn't even resolve when I try to do it manually. This
 was a recommendation I used from this list some time ago. Has something
 changed?

As a feed user of spamhaus, it's easy to see the amount of data that is
actually in the zones. Both DWL and SWL zones are empty, so the
whitelist experiments of spamhaus seem to be either 'on hold' or dead.
Feel free to drop the zones from your setup.

This won't fix dns lookup problems in general though.

Tom



signature.asc
Description: OpenPGP digital signature

Re: Forward secrecy

[Tom Hendrikx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 23-12-13 15:40, Wietse Venema wrote:
 nanotek:
 Still, might be a good time to create my own CA and upgrade to
 4096 bit keys/certificates using SHA512 algorithms and make use
 of some Diffie-Hellman ephemeral elliptic curve parameters for
 perfect forward secrecy. I've read
 http://www.postfix.org/TLS_README.html -- Postfix documentation
 is exceptional by the way -- are there any guides for DHE?
 
 There is a work-in-progress document on forward secrecy that
 covers both EDH and EECDH. It shows how to configure things (the
 defaults should be sufficient for many applications) and what you
 can expect to see in logging and message headers.
 
 http://www.postfix.org/FORWARD_SECRECY_README.html
 
 I am still fixing it for clarity, but it should be accurate.
 Feedback is welcome.
 

After reading, I'm having some questions.

The document states that forward secrecy is supported by default on
recent postfix installs. However, the quick-start still has some
settings that apparently need tweaking.

Setting 'smtpd_tls_eecdh_grade = strong' is already available as
default (tested with postfix 2.10), so no actual work here.

Setting the files (and refreshing them using a cronjob) specified by
'smtpd_tls_mumble_param_file' is a bit unclear though. The default for
these params is empty, and setting them does not really show a
different behavior in postfix (i.e. using different ciphers and keys)
as far as visible from the logged information.

But since forward secrecy is supported by default, what does it help
to specify these params, and re-generate them once in a while? I've no
deep ssl knowledge, but the smtpd_tls_dh1024_param_file postconf
documentation seems to indicate that openssl distributes some kind of
defaults for these contents? Maybe it's a nice idea to make the
forward secrecy and/or postconf documentation a bit verbose on how
this works, and what benefits manual generation of these params has?


Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSuGmkAAoJEJPfMZ19VO/1FbIP/jKzjUXPTGQLigTS5gZZzJA+
cEOuokXnYsUxcsce/kLfYvY0nPMI+YsByAPtcde8aNQ0efGJGI/sol4cfeJ2aXj0
ZGp3yUVN0RY+vcAdCvfL5Exa5nVM4UxMHfYuwJElZcid0ZpS/46D32EBZStq39n7
WbdPOqM2L3ey1PtsJZ4U9V0LSSz0uDfLTQRxtpK2nQJloPZHHShlWRZLsW3Sny4H
UdUdMijR8tpItOeLedaxmCeoBRyNEYxO++J+PRVp4feeeUVUicyU4CwUkx/wbS13
mE5EUttUmOU5GYF34B+9z+HdpyecnZjlr1s51Sfb5pKwSid6PxIeuNS6IvsgvSDQ
N0fP0wMNcTpgyDM196TctZc9OMtjhsUntXk90EnS34fOfEomjduXBHVGabZ+FARw
/pmJWeGNPdi7WtZJ/Ptr8ZgzdiIfZhqEkJWL5nhdCPzZGBX/2aI1ZRk236guhRkv
HOi6sRzrWw/iDdbfjbb31XqV4fsXCBUQ07SnVorCGcckt8PA5+KG6o/LRynhVK6r
RdlDs7iKGjQtHN2/SgKvgrenSxUYXyuHaN6hH+yihKZJ4JwHVTcDOarfUBTTJpi1
lr/AWQcKDHau5QtVr6s/YlzcRyv50ejgecViIfNcuwYjZoVgAVrGCfT7NJhcRA5H
2lxFvOTrFKxlvFlBg3Mx
=QrH8
-END PGP SIGNATURE-

Re: Forward secrecy

[Tom Hendrikx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 23-12-13 18:30, Viktor Dukhovni wrote:
 On Mon, Dec 23, 2013 at 05:49:40PM +0100, Tom Hendrikx wrote:
 
 I am still fixing it for clarity, but it should be accurate. 
 Feedback is welcome.
 
 
 After reading, I'm having some questions.
 
 s/reading/skimming/ :-)
 
 The document states that forward secrecy is supported by default
 on recent postfix installs. However, the quick-start still has
 some settings that apparently need tweaking.
 
 They don't *need* tweaking.  However, the tweaked settings are 
 *recommended.
 
 Setting 'smtpd_tls_eecdh_grade = strong' is already available as 
 default (tested with postfix 2.10), so no actual work here.
 
 As stated.
 
 Setting the files (and refreshing them using a cronjob) specified
 by 'smtpd_tls_mumble_param_file' is a bit unclear though. The
 default for these params is empty, and setting them does not
 really show a different behavior in postfix (i.e. using different
 ciphers and keys) as far as visible from the logged information.
 
 http://www.postfix.org/FORWARD_SECRECY_README.html#server_fs
 
 ...
 
 Postfix = 2.2 support 1024-bit-prime EDH out of the box, with no 
 additional configuration, but you may want to override the default 
 prime to be 2048 bits long, and you may want to regenerate your 
 primes periodically.
 
 But since forward secrecy is supported by default, what does it
 help to specify these params, and re-generate them once in a
 while?
 
 The default non-export prime is 1024 bits.  As explained in the 
 document, you should consider using a 2048 bit non-export prime.
 
 The best-attacks on prime EDH are pre-computation attacks, where 
 one spends a bunch of time computing a bunch of data about a 
 particular prime, and is then able to quickly solve the underlying 
 problem much faster for any input.
 
 Though prime lengths are chosen based such pre-computation attacks 
 (rule of thumb is that for equivalent security EDH primes should be
 about as long as RSA moduli) which are believed to be out of reach
 for 2048 bit primes and perhaps still out of reach even for 1024
 bit primes, one can make the attacks much less attractive by 
 frequently generating new primes independently at each site.
 
 The compiled-in default prime in the Postfix source code is
 perhaps within reach of the best-funded adversaries, who may have
 performed the requisite pre-computation.  Primes you generate on
 your server, and use for a short time are unlikely to warrant the
 extraordinary cost of the pre-computation attack.
 
 I've no deep ssl knowledge, but the smtpd_tls_dh1024_param_file
 postconf documentation seems to indicate that openssl distributes
 some kind of defaults for these contents?
 
 I don't believe that OpenSSL provides default parameters, but 
 Postfix does.
 
 Maybe it's a nice idea to make the forward secrecy and/or
 postconf documentation a bit verbose on how this works, and what
 benefits manual generation of these params has?
 
 The more advanced material we put in the document, the more 
 intimidating it will be for the average reader.  But of course an 
 empty document is not optimal, so we have to aim for the middle.

As stated, I assumed that the default primes came from openssl, based
on the smtpd_tls_dh1024_param_file description in postconf(5). While
reading 'using the exact same parameter sets as distributed with other
TLS packages', I was assuming 'other TLS packages' to be other
(non-postfix, non-SMTP) software packages also using openssl.

After another re-read of the forward secrecy document (and from your
reply), I now found the part that states that the default primes are
postfix builtins. I missed this link.

So it doesn't have to be more technical or advanced. There were some
connections between dots missing in the higher level picture.

Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSuHsrAAoJEJPfMZ19VO/1MY0P/RkJMxLYu77l8QVfQjuwQdk1
4xgMXiyR0IC8tSKFuulwX/sl+YoFcv2wkjupx0ZwTkVg32feccAUgnzy3wVfe3UM
Di5sxIdNq7M2MOb/O3nuoGkKiFDTtd/PXpInI6iLtKL9ADKXPwsbikQda1BEbV++
lO9BsVA1sJsAJOl40nOvx639cFQCEoLyAkuIgk6dZ//7sn1jmIFpYnZhkFvPo2rT
Y+3xwGtK+kz2E/b2uutkCO203iCf6hSkyV/jSF2rHl9L/iOkH2ohwt3ICrlH3r38
9Q3TUeMkJzWrHC1ME+LHA5bPhmKdtFsPywZHCWEMK/91U1EQSw8MI6JLHwiC9SZQ
JspWkm2JroIrkHl1mKHWi3IazI2hRTgjhmGwkaHy8+m3Cvkq5u9W8jEIBQ045luF
gKnCQdaDnfA0htg1dGmvpFItQeddraG+7DcXFDKtPny/mo3oTfAoSgiO3dKIjEDm
NihRXgJAtfJRXZG+vLGW0G/+h1DHT5u+l0l9W+TntJi9F2gBk1L6Lz+RSH9Jg5Cc
WBAvu2FH1HpoiTNKfdJu3Oi8P0PaSIbnwtODWZ0VVaRVT+YQgGkgjyMcMsvJkEF7
WknGNWBGk5/2n5/x7E/yX1VIV0416ehZSom0C/eBUZxCWAiidZwrRB+hQrcqGJUU
UfgkVU/WR+i9bBSxByEa
=i2Yp
-END PGP SIGNATURE-

Re: Forward secrecy

[Tom Hendrikx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 23-12-13 18:40, Wietse Venema wrote:
 Viktor Dukhovni:
 On Mon, Dec 23, 2013 at 05:49:40PM +0100, Tom Hendrikx wrote:
 
 I am still fixing it for clarity, but it should be accurate. 
 Feedback is welcome.
 
 
 After reading, I'm having some questions.
 
 s/reading/skimming/ :-)
 
 In this section, the commands that compute the parameters PRECEDE 
 the text that says why one might want to do this.
 

The text currently reads like:
- - you need to generate the params files once
- - for greater security, re-generate every now and then

The improved security that is gained in the first step is not obvious,
which is why I went looking for the details on the params that Postfix
uses when the settings are left untouched.

You might want to make it clearer that providing customized params is
more secure than using the builtins. After that, running a cronjob to
refresh them is another improvement.

Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSuH0qAAoJEJPfMZ19VO/18wsQAIwzLUl26Q6+j43vXudQpEq2
x8JUt/jjTcRz+PkurynM51YLlmikxzhwC3J/reUvp2zSvHojOAsbomDdp6NN72Km
eJdvxSgxc5i05tcoPxtoUZ3aKZUHHFdQ/p/HtnG2zXiU77AWnBzPPBwaZd0qo0f0
Ao22oL68qltuc23APMSYI78acwLFZO/X3Lky+UquyPiwn8qK1JkX3WtzOwsTiNX6
Xv4taIxLSn6sje3DCyWv2lAX0mPTo6B9mKzi7zO1PyUtym/jBo/6WUbW9QxB8ZWC
D3hRVkarDdUlWHPOHx1P3nkaA9aiZgy93rVCT0yrB14KS57GvGCBptjo36QHzsvP
QUSPo79jjIL/Z3YE+g/HbonFMiHdP0vCioFVU8rgRBZXH1/UbdKHu7eJxxgR6Ggm
GssbJkz3hx+JJNzXJcrPjlCrERn9cROKIY0gkE0shjMMcgUG41H9OGBR8GzEOYvm
wUOoORAkzaJddeApRrEPGQqQcnlCRulbkQYk8UmnkxH+/P+YSHZqbMXFbxOZzW6Z
+5ueiasIxlXA3+Dgmj0xlpOsWFRArFiJLBxfpvkE9Cl/ZhBV31t6DR09doCJznvn
5fFS803QEiwVPuQc0OGg7xYJUG4iDv5gqRxZh27Zuzz2SF5zKxMzTYb7xBxcJCqf
QGxvbqtkzTpKC1tE5wxv
=bwAN
-END PGP SIGNATURE-

Re: Use of smtpd_reject_unlisted_sender

[Tom Hendrikx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 20-12-13 20:54, Bernardo Pons wrote:
 On these days where theft of credentials of legitimate e-mail
 server users in order to send spam checking the MAIL FROM: using 
 smtpd_reject_unlisted_sender would be a helping Postfix feature.
 
 Perhaps it is a misunderstanding from my side about the actual
 meaning of parameter smtpd_reject_unlisted_sender but if 
 smtpd_reject_unlisted_sender = yes is present on main.cf...
 
 How is it possible for an user to send an mail from an unknown
 sender addresses neither listed in virtual nor canonical?
 
 The user is connecting to the smtp server and authenticates itself 
 correctly but he's sending e-mails from an absolutely alien e-mail 
 address (both user and domain part of the e-mail address)
 
 If the authenticated user tries to send e-mail from a non-existent 
 e-mail address (user part) of a local domain the e-mail is rejected
 but if he/she uses a non-existent e-mail address of an alien domain
 the e-mail message is accepted by smtpd server.
 
 Shouldn't ALL those mails be rejected by smtpd?
 

The problem is that postfix cannot look up localparts for domains that
are not hosted locally. For domains that the server is configured to
handle using local/virtual/etc, the localparts are also available
(i.e. 'listed'). For random offsite domains, the localpart cannot be
verified other than using a VRFY call, which is disable at most sites
because it enabled spammers to verify existance of addresses, and
usage is considered abusive by many admins.

In order to force authenticated senders to use a limited set of MAIL
FROM addresses, you'll probably need to use
reject_sender_login_mismatch in smtpd_mumble_restrictions.

Regards,
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJStKTaAAoJEJPfMZ19VO/1o5sQAJZlWimP2XWy6Ion5NvZtn3v
BIxvWuHQSvaytAeL6NyrjjL3eA+p9z8WpOqj1IUZGjL2Egvag8vU34HM8a64gRCF
Js8WlE5vop6yLDyDgmo8BdTDLmy00YI67jXCEWFn/H9ivTp8fbRL8QjWw+tDFWNB
bPJmWVRx43Qbf5TTl/H2idi/ZTftMIYDaL7cZ7pgG1w2o69r2bzj/uv/bKL7/Mvr
niKM4Rcw+zkvOVS9DmEfge8Eh7ZTHPL2nsQm4+pTkk1tgxgjW602i9mgfvjVK/CV
o073sF1lbfvMV/77Wm+dSoi4i7nC0A/A7sS4HXpRku9KNoSVfj+gJV2cb1ft5/6F
QnyRi/m33654SyzWvChC4UZWg3NleoAnwHTxfIYnoTCiEwdRzk7PczINuXkIZfDC
fpZmtu4DSs9jHMCuEA7On0lgDOxdwBCJz3guk3rxOcWvC+2m38vXW9txcjNgfeoE
QimyLC1d2sAQV7PVvPpquHmgJQyiiD536WDMwT2V05W13jXSZ7fwEUuXDb29/EIS
2O7dpYe/BiWut7gCwgdbU5jfVxgaJESIPp3kmsI4Zn/nViJH5cR2HaScLSWBjCdz
Bf3bVc3FYSZrXCRZyp6bc6ZFNJGCcIo4jmvawZEBSl2ToFTMUSDyG01NFHwu1csN
Oll9fk0E/wxupS2/TJKM
=OH5l
-END PGP SIGNATURE-

Re: default_milter_action

[Tom Hendrikx]

On 10/24/2013 08:39 AM, Roland de Lepper wrote:
 Hi ,
 
 The connection between Postfix and the archive is over SMTP.
 
 In my example with the smtpd_milter, will the email also go to the hold
 queue if only one archive connection is down?
 Or will it deliver the email to the archive which is online? This is an
 important question for me, to get both in sync.

Your config shows that you have 2 milter instances, delivering to both
archive backends. If one of them fails, the other can still succeed
since the milters don't communicate. Only postfix sees the final result
but it on't the milterA that milterB had a failure.

So, if you want to be sure that every mail is always sent to both
backends (i.e. consistency), you need to a single milter that talks to
both backends, and should be able to inform a backend to 'undo' the
store action on backendA when backendB is failing, and vice versa.


Tom

 
 If the emails will go in the HOLD queue, that is not really a problem for
 me. Our monitoring will scream within a few minutes, the mailq is too big
 and the connection to the archive is down. This way we are noticed to take
 action, keep the emails on HOLD till the problem is solved with the archive
 or take another action if the problem is severe and take too long too
 solve. We can always copy the data from one archive to another.
 This again raise the question if the emails will go to the HOLD queue too
 if one archive is down.
 
 regards,
 
 Roland
 
 
 On Wed, Oct 23, 2013 at 4:02 PM, Wietse Venema wie...@porcupine.org wrote:
 
 Roland de Lepper:
 Hi Wietse,

 Thanks for the reply.

 What about milter_default_action = quarantine  ?

 As documented, this leaves the message in the hold queue.  If the
 Milter should have done something with the message, then those
 things will never happen. The message is now in the queue, and the
 Milter is a before-queue feature.

 If I may ask, is the archive connected over SMTP or over a
 propietary protocol?

 I think that defer accepting mail while the archive is down is
 the safest option (i.e. leave it up to the sender to retry).
 Everything else requires that the message is queued in Postfix while
 the archive is down, for example as in this simplified picture:

 network - smtpd - queue - smtp - smtpd+milter - queue - delivery
 agents

 The part with smtp - smtpd+milter:  would implement an SMTP-based
 empty after-queue filter.

 Wietse

 regards,

 Roland de Lepper


 On Wed, Oct 23, 2013 at 1:24 PM, Wietse Venema wie...@porcupine.org
 wrote:

 Roland de Lepper:
 smtpd_milters = inet:81.x.x.x:8092 inet:217.x.x.x:8092
 milter_default_action = tempfail
 milter_connect_timeout = 10s

 This works perfectly without any problems. the question raised, what
 if
 the
 connection between the mailserver and location B is down. Is the
 email

 As documented no mail is delivered after Milter failure. The Postfix
 SMTP server will reply with an error status code (4xx) and the
 client will have to send the message again.

 The bad alternative is milter_default_action = accept, which means
 that mail will be delivered but not archived.

 If you want both mail delivered AND mail archived, then you need
 to use sender_bcc_maps or recipient_bcc_maps to add recipients for
 archival purposes.

 Then, Postfix will do the retrying until the message is too old,
 at which time it will be returned to the sender.

 Wietse


 




signature.asc
Description: OpenPGP digital signature

Re: default_milter_action

[Tom Hendrikx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Roland,

My proposed solution was a milter that runs locally on the postfix
box, and communicates with both archive boxes so the milter is able to
act on errors in both archive boxes. I did some reading on the
product, and it seems that the milter interface is part of the archive
solution, and even runs the milter interface on the archive box itself.

Anyway, that makes my advice obsolete. You should llok into non-milter
solutions if you need to get both backends synchronized. The
mailarchiva help has some nice alternatives for that. The High
Availability section describes some interesting features.

Tom

On 24-10-13 14:43, Roland de Lepper wrote:
 Hi Tom,
 
 Thanks for your answer, but unfortunatly, that's not possible
 because the MILTER sends the email to the archive. With only one
 MILTER, both archive server must have the same Ip-address. Or do I
 mis something?
 
 Roland
 
 
 On Thu, Oct 24, 2013 at 2:37 PM, Tom Hendrikx t...@whyscream.net 
 mailto:t...@whyscream.net wrote:
 
 On 10/24/2013 08:39 AM, Roland de Lepper wrote:
 Hi ,
 
 The connection between Postfix and the archive is over SMTP.
 
 In my example with the smtpd_milter, will the email also go to
 the
 hold
 queue if only one archive connection is down? Or will it deliver
 the email to the archive which is online? This
 is an
 important question for me, to get both in sync.
 
 Your config shows that you have 2 milter instances, delivering to
 both archive backends. If one of them fails, the other can still
 succeed since the milters don't communicate. Only postfix sees the
 final result but it on't the milterA that milterB had a failure.
 
 So, if you want to be sure that every mail is always sent to both 
 backends (i.e. consistency), you need to a single milter that talks
 to both backends, and should be able to inform a backend to 'undo'
 the store action on backendA when backendB is failing, and vice
 versa.
 
 
 Tom
 
 
 If the emails will go in the HOLD queue, that is not really a
 problem for
 me. Our monitoring will scream within a few minutes, the mailq
 is
 too big
 and the connection to the archive is down. This way we are
 noticed
 to take
 action, keep the emails on HOLD till the problem is solved with
 the archive
 or take another action if the problem is severe and take too long
 too solve. We can always copy the data from one archive to
 another. This again raise the question if the emails will go to
 the HOLD
 queue too
 if one archive is down.
 
 regards,
 
 Roland
 
 
 On Wed, Oct 23, 2013 at 4:02 PM, Wietse Venema
 wie...@porcupine.org mailto:wie...@porcupine.org wrote:
 
 Roland de Lepper:
 Hi Wietse,
 
 Thanks for the reply.
 
 What about milter_default_action = quarantine  ?
 
 As documented, this leaves the message in the hold queue.  If
 the Milter should have done something with the message, then
 those things will never happen. The message is now in the
 queue, and the Milter is a before-queue feature.
 
 If I may ask, is the archive connected over SMTP or over a 
 propietary protocol?
 
 I think that defer accepting mail while the archive is down
 is the safest option (i.e. leave it up to the sender to
 retry). Everything else requires that the message is queued in
 Postfix while the archive is down, for example as in this
 simplified picture:
 
 network - smtpd - queue - smtp - smtpd+milter - queue -
 delivery
 agents
 
 The part with smtp - smtpd+milter:  would implement an
 SMTP-based empty after-queue filter.
 
 Wietse
 
 regards,
 
 Roland de Lepper
 
 
 On Wed, Oct 23, 2013 at 1:24 PM, Wietse Venema
 wie...@porcupine.org mailto:wie...@porcupine.org
 wrote:
 
 Roland de Lepper:
 smtpd_milters = inet:81.x.x.x:8092 inet:217.x.x.x:8092 
 milter_default_action = tempfail milter_connect_timeout =
 10s
 
 This works perfectly without any problems. the question
 raised, what
 if
 the
 connection between the mailserver and location B is down.
 Is the
 email
 
 As documented no mail is delivered after Milter failure.
 The
 Postfix
 SMTP server will reply with an error status code (4xx) and
 the client will have to send the message again.
 
 The bad alternative is milter_default_action = accept,
 which
 means
 that mail will be delivered but not archived.
 
 If you want both mail delivered AND mail archived, then you
 need to use sender_bcc_maps or recipient_bcc_maps to add
 recipients for archival purposes.
 
 Then, Postfix will do the retrying until the message is too
 old, at which time it will be returned to the sender.
 
 Wietse
 
 
 
 
 
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSaW6BAAoJEJPfMZ19VO/1GnQQAM3JjgsNsogpNIxVkHECunwj
WlKrPOo959OzuXVnmOnfhEYYjzgYp7b6AaVTb8MM08bt6Db9tpiS6jNDK34m82fJ
3fowVTRoDBKgJfLSFkhfpyJgHCw/4gnN8XCoBZaRYbfRGi4jvyk8Pf9HVBfAzlSI
FbKzY15QGK1XEn/RnxZYlLSKEsTmn1nrqM+PUfwWOsm8+y2gK2pgnqzy0jbKkKFc

Re: smtpd optional authentication and relay

[Tom Hendrikx]

On 07/05/2013 04:07 PM, Viktor Dukhovni wrote:
 On Fri, Jul 05, 2013 at 10:00:02AM -0400, W T Riker wrote:
 
 Thanks for that explanation. I think I understand the way it works now
 so I modified my restrictions a bit. Does this order pass the sniff test?

 smtpd_recipient_restrictions =
 reject_non_fqdn_recipient,
 reject_non_fqdn_sender,
 reject_unlisted_recipient,

I'd say that reject_unlisted_recipient will also reject mail to offsite
recipients, even when it is sent by an authenticated sender (since
permit_sasl_authenticated is specified later).

 permit_mynetworks,
 permit_sasl_authenticated,
 reject_unauth_destination,
 reject_invalid_helo_hostname,
 reject_unknown_sender_domain,
 
 Fine up to here.
 
 reject_unknown_recipient_domain
 
 This is not a good idea in this context, you've already checked
 the message is to one of your own domains.  Unless you've specified
 relay_domains (and you have relay_domains listed in
 parent_domain_mathes_subdomains) or inherit relay_domains via its
 default $mydestination, every domain you accept should be known,
 you just risk deferring mail due to transient DNS lookup errors.
 
 You should generally avoid having subdomain matching in relay_domains,
 set parent_domain_matches_subdomains empty or perhaps just:
 
 parent_domain_matches_subdomains = smtpd_access_maps
 
 if your access tables rely on this to match a domain and all its
 subdomains.
 
 The backwards compatible default is:
 
 parent_domain_matches_subdomains =
   debug_peer_list,
   fast_flush_domains,
   mynetworks,
   permit_mx_backup_networks,
   qmqpd_authorized_clients,
   relay_domains,
   smtpd_access_maps
 




signature.asc
Description: OpenPGP digital signature

Re: Blacklist IP with a reject message

[Tom Hendrikx]

On 06/26/2013 08:11 AM, Abhijeet Rastogi wrote:
 Hi all,
 
 Straight to the point, I ban IPs using fail2ban based on 4 jails. The
 reasons vary from bruteforce sasl login attacks from specific IPs to
 number of attempts to send suspect/confirmed spam mails. Right now,
 there is a iptables rule that starts dropping packets for a IP. This is
 highly undesirable as if sometimes this IP is a NAT server's IP for a
 org, there are cases where SMTP packets from all clients of that org get
 dropped and they have no clue what so ever.
 
 For now, I want to start rejecting connects with a REJECT message that
 can be different for different IPs. One way I could do is using access
 file and adding IPs to it. Unfortunately, it will work for a single
 server but not for a cluster of outbound servers.
 
 Questions:
 1. If I use access file to block IPs, it's a challenge to keep all
 servers data in sync. Also, it'll require me to run postmap each and
 every time file changes, does that effect postfic performance in any way?
 2. I thought the option of writing milter using python where I could
 keep one Redis instance as master  rest outbound servers will have a
 slave Redis server. Each time a connect happens, I'll check the IP
 against my local Redis instance and act accordingly. I think it's a
 overkill. What do you guys think?
 3. I could also write a policy server. Is there already a policy server
 that's as simple as blocking IPs based on a ACL. But then, I'll have to
 run a local mysql server also.
 

How about running a local DNSBL using rbldnsd or some scriptable dns
server, making fail2ban add ip addresses there. You could run several
zones that return different reject messages to the connecting IP.

Regards,
Tom



signature.asc
Description: OpenPGP digital signature

Re: postfix munin graphs

[Tom Hendrikx]

On 06/19/2013 10:03 AM, Grant wrote:
 I think I need to tell munin where my postfix logs are
 (/var/log/mail/current) since I use metalog.  How can I do that?

 Instead of searching online, use the built-in pod based format, e.g.:

 $ munindoc postfix_mailstats

 You just improved my life.

 You might also need to set group permissions to be able to read the log
 file.

 I have this on /var/log/mail/:

 drwx-- 2 rootroot

 Since Gentoo set it up this way, I wonder if changing it would open a
 hole.  What do you think?

 - Grant
 
 Actually, it seems to be working with permissions as-is.  How can that
 be since apache runs as apache:apache?

The webinterface (running as apache:apache) does not collect the data,
the munin-node daemon does that. Probably the data collection is
configured to run as root (at least for the postfix plugin).

Again, read the docs ;) You seem to have missed (a part of) the basic
understanding of how munin works...


--
Tom



signature.asc
Description: OpenPGP digital signature

Re: Problem with transport setup

[Tom Hendrikx]

On 10-06-13 21:30, Patrick Lists wrote:
 On 06/10/2013 09:14 PM, Wietse Venema wrote:
 Patrick Lists:
 Jun 10 20:19:11 test postfix/smtpd[13975]: NOQUEUE: reject: RCPT from
 localhost[::1]: 550 5.1.1 s...@example.org.org: Recipient address
 rejected: User unknown; from=patr...@example.org to=s...@exmaple.org
 proto=ESMTP helo=test.puzzled.xs4all.nl

 To fix the User unknown error see this document:

 http://www.postfix.org/ADDRESS_CLASS_README.html
 
 Thank you for your feedback Wietse. The problem (to my untrained eye) is
 not the User unknown error. It's that after the forwarded email was
 submitted to the dspam-retrain transport and processed, postfix attempts
 to deliver it. I would expect it to stop once the forwarded email was
 handed off to the dspam-retrain transport and processed by the script.
 So I don't understand how fixing the User unknown issue would solve
 this problem. I just want the forwarded email to be processed by the
 dspam script and *not* be delivered afterwards. What did I miss?
 

The final delivery attempt is triggered by either the retrain script, or
dspam (after accepting the message from the retrain script). Inherently,
this is actually a dspam question and not a postfix one.

Normally, you'd tell dspam to not deliver the messages passed while
retraining by adding '--deliver=' (i.e. deliver never) to the retrain
command line. I'm missing support for that in the script (as available
in the dspam git repo), but I'm not sure whether there is a valid reason
for that, since I have no experience with the actual script. Re-post
your message to the dspam mailinglist, maybe someone else knows more.

Kind regards,
Tom

Re: question about postfix queue scheduler

[Tom Hendrikx]

On 06/04/2013 01:22 PM, Antonio Gutiérrez Mayoral wrote:
 Hi Wietse,
 
 Yes, its a solution, but these emails should be delivered in
 bussines-time :-(
 (it doesnt matter if it takes 2 hours... but in bussiness time...)
 
 thank you so much!
 

You could run a script as a cronjob that queues x messages when the
active queue contains (100 minus x) messages (where 100 is an arbitrary
number). This means that all mails on HOLD trickle out as quick as
possible, while not overloading the active queue...

--
Tom

Re: Postfix 2.8.x anti anti backscattering settings

[Tom Hendrikx]

On 04/19/2013 12:07 AM, Stan Hoeppner wrote:
 On 4/18/2013 4:26 AM, Mikael Bak wrote:
 Hi Josef,

 On 04/18/2013 11:06 AM, Josef Karliak wrote:
   Good morning,
   our outgoing smtp server gets into a backscatter blacklist. When I
 checked my logs, there were only one mailer daemon email to some server
 in the time that is mentioned on the backscatter web.
   In all servers in the way of the email (incoming MX-antispam server-
 our imap server) has unknown_local_recipient_reject_code = 550.
   What else could I do ? There could be one thing - incoming MX accept
 all emails for our domain, he doesn't know our aliases. The mail is send
 to antispam and when antispam wanna sent the email to imap server and
 the target email address doesn't exists, it has 550 error and it is send
 away by our antispam server (it is our outgoing server).
   So, is this all wrong ? We decided to have more servers because of
 loading reasons (we've daily up to 15 000 emails, but there were a 60
 000 peak)

 You can have reject_unverified_recipient on the MX to check the IMAP
 server if the email address exists before accepting it.
 
 
 To be clear Josef, reject_unverified_recipient performs recipient
 address verification via an SMTP RCPT TO test.  See:
 http://www.postfix.org/postconf.5.html#reject_unverified_recipient
 
 You state your MX Postfix server relays all mail to the AS appliance
 which accepts everything regardless of recipient address, which is why
 you're in trouble currently.  Verification queries will be sent to the
 AS box, so reject_unverified_recipient will not work in your setup.

Last time I read ADDRESS_VERIFICATION_README, I noticed that this isn't
true: you can route your probes to the final delivery machine while
leaving the current delivery mechanism intact:
http://www.postfix.org/ADDRESS_VERIFICATION_README.html#probe_routing

 
 To fix your problem you must have some form of recipient validation at
 the MX so it only accepts mail for valid mailbox addresses and rejects
 mail to invalid addresses.  You have a couple of options:
 
 1.  Export the valid recipient list from the mailbox server to the MX
 server with one address per line in a text file.  Create an access table
 from this file with OK action.  Use check_recipient_access:
 http://www.postfix.org/postconf.5.html#check_recipient_access
 
 2.  Implement an LDAP or mysql database containing valid addresses.
 This can be used with check_recipient_access, local_recipient_maps,
 virtual_mailbox_maps, etc.  For implementation details of each see:
 http://www.postfix.org/postconf.5.html
 




signature.asc
Description: OpenPGP digital signature

Re: LDA understanding

[Tom Hendrikx]

On 03/14/2013 05:07 PM, Kris Deugau wrote:
 Jerry wrote:
 Personally, I have no idea why anyone uses procmail. For relatively
 fine grain sorting of mail upon delivery, I use Dovecot and Sieve. From
 what I can ascertain, procmail hasn't even been maintained in over a
 decade.
 
 Sieve can't call outside programs (eg SpamAssassin) by design.  IMO the
 inability to call any external filtering programs (even from a
 restricted whitelist) makes overall mail filtering significantly harder.
 
 -kgd
 

To complete this discussion, recent sieve standards/proposals have
support for a generic interface to external spam and virus filters such
as spamassassin, called at sieve runtime (i.e. not decisions based on
earlier added headers), see [1].

Pigeonhole sieve for Dovecot [2] supports this. pigoenhole also has
experimental support calling arbitrary external programs in an
administrator-controlled way [3], which I use with great success to add
spamtrap messages to a database.

I hope this might convince people to try sieve once more as a
replacement for procmail ;)

[1] http://tools.ietf.org/html/rfc5235
[2] http://pigeonhole.dovecot.org/
[3] http://wiki2.dovecot.org/Pigeonhole/Sieve/Plugins/Extprograms

--
Regards,
Tom



signature.asc
Description: OpenPGP digital signature

Re: possible localhost dns spoof attack

[Tom Hendrikx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/26/2013 11:32 AM, Jamie wrote:
 Hi
 
 Earlier today I noticed a spammer using my Postfix server as a
 relay to send out spam. This was puzzling because i had all
 requisite anti relay host settings applied. Further, it was
 particularly alarming that Postfix seemed to be receiving the spam
 messages from localhost as indicated:
 
 connect from localhost.localdomain[127.0.0.1]
 
 After further analysis, I discovered that the traffic was not in
 fact being sent from 127.0.0.1. The packets were coming from:
 
 113.167.239.162
 
 Funnily enough, this IP's DNS resolves to the name localhost.
 
 Christian and I are suspicious of this. Could it be that this DNS
 name forms the basis of a simple DNS spoof attack that somehow
 confuses Postfix into thinking that the traffic comes from
 localhost and therefore, allows the relay to proceed?

It is easy to add a directive to postfix that whitelists a hostname
localhost, or a server HELOing as such. Of course, none of that is
in the default config.

We can never be sure unless you provide postfix logging of the actual
attempt, and you post your configuration.

Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRLJkJAAoJEJPfMZ19VO/1svAQAIMtiHus2nuvH6Re+GtTPud7
ZJRLFqiWB094CIN00X4VqsAAVWvphN4ZKD2XpMmmR20oEfLQJT269RCvT/McwYVu
4BhugnhWtA1dTtrJ+A7qvxCDR2M6aCvvGaRDQJ0toUIDqYeGX28VtBuJlDuXIte0
dOLDhc5RMfAj8nEVSSAe7e/G/ArJiLlB724wVn9Scgm46Tdsu0+6uiseX0/WNpCM
I0beqbrGvCD19npUSK46oqf+mYpcVIie1dtYLctkUld1nRPjlCLRGc+qNs24ISLe
jkPSD/rwzdWpPaPKqtomrq07WAWl83+b3cm5ozxGYaAGqP/C/DRRGSVN15lyYdpz
0BzA1FA8TWwoysXuFKO+g5zZVD2rnnTFdvMuk7fcNJerh5OrGjXvzng+vShcm4P1
2ozzKmvM8y/8SezMNSLIn4CF/WXj6+DOi0sWe+D3bg4wvY6r3R5FGv3ZbY9guen/
f0TZoavUOKbJiUWTg1qOsLSutj/YWh48sbEh1ZDUlZwwUiMq2LYF+e1hq0xmSFG0
zwIJdlQhtjm9golbfGOlCJRQAeVXuaXRq3LkN9KqjyuaBCXcJFjA3dNDVFcDHVb8
WlaWYzvOs3fgSLwq7duWeb85Q0foanuJsYEu4d2hhOoA1jI2SmmgAWlPPDJTsqiO
AcHapP+4xGBm6bj0IUXH
=0li3
-END PGP SIGNATURE-

Re: postfix stopped relaying after client changed IP address

[Tom Hendrikx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/29/2013 11:43 AM, M. Fioretti wrote:
 
 which looks like postfix on the SERVER was not aware that now 
 2.39.122.159 IS in mynetworks. Why? Any help to figure out what is 
 happening is


 mynetworks = 127.0.0.0/8, 212.48.186.219, 2.39.122.59

It isn't in mynetworks. Fix the typo.

- - --
Tom
- -BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRB7BwAAoJEJPfMZ19VO/12u4QAJda6Mx4GgO/c5Z9Cf4PaAxa
oQGyiHO3Xo1esw4TAZADw91lPgdf1s65k+diYgxQydg8SGNITQEholFcuYTkdZqa
RPZzABkSYRds34+EAShR5+gknoKo5P8aprTQQv/Zs9XX9E/P6cxMfmuz6dnRKRTx
jIM28iESie3qVl+vOV8pl/aZhG5pIs3lvaylbKng3lkHe+SBFWhblY33RTE1AkNl
7mBRRVL9PoC+HKUfqsZpFbmqD3r8vF+k+OVDVZN1BzCj6SacLNLJwyZto88BZh5Z
9Sz0fY6LaKjdfTfJwCBsVUpd4SL6JYO8HO65vG3H6QYa94zvEI0k7VLD5XHQ/rXa
pUa9O5sK3jyY63X/2Pb1DYw06ER5SQCffF31VcCsSl7BPvXUlyyn1QJ6UGK+ffgI
MgMhtygjuHUrQCW3hCJVEPyf61fJTM89ayFHdUrU4IYWYv5LB8QX2Ni32foc1QEh
1IqP9C+hTmjasEzjsJjfrlpEYhehj0Io9IS4N86wMmsSdVCVLFWuX2qWDhWQLTG8
BGKiWWcFmH08++ZsuttNb3BL18g1asR5Dxzx02UPl+QOwwY0DYA8/eAzDGCWkywS
/ZFKwGcPvOGfP3bsPUUAIICa2vw8szSTaRoelQhkkbsT4L9LtlYrcJyx0f/iCPfb
zdQPtoP2jFtF+heQXOT/
=NdW9
- -END PGP SIGNATURE-
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRB7CSAAoJEJPfMZ19VO/1fEkP/j3UA+qYzuQfedkBflcqpDEm
u0s9d4DCSIB5+OOFQxkNCGUt3K44Q3FgVfop1s6R3EFhDvWTtcP9BRVujMClI3hw
H+fHnBX42vuVvlw0WDIkzL/6jRIHT2HhfDjZ734nebNHJKYrXr5Lh1YoGGmJ9ewR
fZjv3u6JUzZHNrW+bC089Qb6t8r9DjSGPrDw/wy4B7fmyLkausJ32ys9kpT4xFok
r2tuGP0nSB5VP3f+lWdeMlESW2AZwHLFd/7lMxt/DWK43FRY8O/vn9Pbbej1STp1
7Qk9QzZW/Q3poEy74sUpGvh19AjqhhqaQrNNlz16Ecum2EBy5IVmgOg2Bbqx6XPM
qVMD9h0dzj8jBJzE5r8wIhpj2LkifuJ0e5UJztcBSGltnv7jgBXP4vTc4BV/j5Cw
sZZlurrJ7bx07G4f5nTU2lk3F2+vYDwRpQUc4tqISCHmiU2Ay7WhaIV8jIe4MFMp
IinSXt/bFpd4wxITIajbn2F9+3tHCu9bUelACuYiK8unf47zG7Q6jqDOTG9MQ4P0
kb2zcnn92aXAReX7MS8oigJGaIHb313UktbnffPsBnwfPUO8Ayrh6uoHkzXnbGOK
Z0L9TlEqhCW/87BqcminqTcZRHI/uoDOST213cXZ3RwcQ/rPOLzOr84tE7onP7pE
YR3J1SQg0XLCYZJPd56f
=Msvh
-END PGP SIGNATURE-

Re: Learning how to respecth REPLY-TO headers

[Tom Hendrikx]

On 12-01-13 15:59, Reindl Harald wrote:
 
 but as said - there are a lot of mailing-lists out there which are
 configured by morons where this all does not work as it should or
 is destroyed because many users on other lists are doing permanently
 reply-all and if your server is configured like mine to supress
 duplicates because of this there are good chances that you get only
 the personal copy without list-headers at all

You don't want to suppress duplicates, you want the suppress the
unwanted copy. This is easy in most cases: make the mailing list
software not suppress duplicates, then use the following sieve recipe to
filter all duplicates:

if header :contains List-Post postfix-users@postfix.org {
  fileinto Postfix;
  stop;
} elsif address :is [To, Cc] postfix-users@postfix.org {
  fileinto Duplicates;
  stop;
}

Then use reply-to-list for all mailing lists. Haven't found one that
didn't work.

NB The first line, which detects a mailing list copy, might need
tweaking depending on the mailing list software. But each mailing list
is easy to identify based on some kind of header (combination).

--
Tom



signature.asc
Description: OpenPGP digital signature

Re: using cidr notation in client_access

[Tom Hendrikx]

On 12-01-13 17:39, LEVAI Daniel wrote:
 On szo, jan 12, 2013 at 14:11:12 +0100, Bastian Blank wrote:
 On Sat, Jan 12, 2013 at 01:51:26PM +0100, LEVAI Daniel wrote:
 How should I put this... My question is not in regards to how to store
 IP networks (w/ CIDR postfix) in PostgreSQL; this is somewhat given.

 PostgreSQL handles CIDR with some special functions and operators. See
 http://www.postgresql.org/docs/9.2/interactive/functions-net.html
 
 The type in PostgreSQL is irrelevant. Ignore it. That is not part of the
 question. It is just a string that Postfix queries. For example
 currently (when querying single IP addresses for check_client_access)
 the column in question is a varchar...
 

It is relevant. client_client_access is an access table. Postfix does
not query the table for an ip adress, it wants an OK reply for the
queried IP address. Read http://www.postfix.org/access.5.html

If you configure postfix with a query that checks if the ip address is
in the cidr mask in the database, you're done:

SELECT 'OK' FROM client_access_table WHERE inet '%s'  inet
client_access_column

I'm not sure if you can cast a varchar column to inet type at query
time. If not, you need to do some more database tricks.

--
Tom

Re: MX vs A records

[Tom Hendrikx]

On 10/17/12 10:05 AM, Tom Kinghorn wrote:
 On 11/10/2012 14:48, Wietse Venema wrote:
 Tom Kinghorn:
 check_sender_ns_access type:table
 Search the specified access(5) database for the DNS servers for
 the MAIL FROM address, and execute the corresponding action.
 Note: a result of OK is not allowed for safety reasons.
 Instead, use DUNNO in order to exclude specific hosts from
 blacklists. This feature is available in Postfix 2.1 and later.

 Use this only for known-bad providers.

 Wietse


 I have added this but it is not working on my setup.
 All mail to the domains gets queued.
 
 setup is as follows:
 
 smtpd_recipient_restrictions =
 check_recipient_access hash:/etc/postfix/recipient_access_whitelist
 check_recipient_access hash:/etc/postfix/recipient_access_blacklist
 check_recipient_ns_access hash:/etc/postfix/recipient_ns_host
 ...

You're testing NS records for the recipient address here, not the sender.

 i tested using ad...@cpf.co.za
 
 cpf.co.za is hosted at sedoparking.com
 
 in the recipient_ns_host file I have
 
 sedoparking.comREJECTRecipient hosted at sedoparking.com
 
 thanks
 Tom
 

Re: Mapping one domain to another (mysql)

[Tom Hendrikx]

On 8/7/12 8:58 PM, email builder wrote:
 Probably the best lesson to learn from postfixadmin is: you can
 have
 
 more than one lookup table in postfix per main.cf directive. 
 Postfixadmin uses 2 separate queries for regular aliases and 
 domain aliases.
 
 from main.cf: virtual_alias_maps =
 /etc/postfix/mysql_virtual_alias_maps.cf 
 /etc/postfix/virtual_alias_domain_maps.cf
 
 where each file contains a simple db query. Makes it much easier
 to write the correct query, on the expense of some more db load.
 
 Thanks Tom for making it more clear.
 
 However, if you split to two queries, you still need a complex
 query for the mapped domain. In my example, still like:
 
 query = select if ('%d' = 'example-2.com', IFNULL((select dest from
 aliases where addr = '%u...@example.com'), (select addr from users 
 where addr = '%u...@example.com')), NULL)
 
 I've found that in conjunction with a 2nd query (the original
 normal one), everything seems to work as expected (including
 aliases with only local parts like postmaster)
 
 But I'm still unsure if this kind of query is correct, if I'm on
 the right track. Can anyone tell me if there's a better way to do
 it?
 
 Where are all those examples that are supposedly posted on this
 list previously?
 
 Bump - surely there's someone out there who has done this and can
 tell me if the kind of query above is either misguided or
 approximately what is needed to achieve this feature.
 
 ie, Do I really have to query the alias table AND the account table?
 
 
 People have said on this list that other examples have been posted,
 but I can't find them.  Can someone please help?
 

You have been pointed to postfixadmin before, which has all of this
builtin. Did you check their documentation? Every existing db-based
postfix adminsitration suite should have an example for you.

My query for alias domains on postgres, using postfixadmin database model:

query = SELECT goto FROM postfix_alias AS alias, postfix_alias_domain AS
alias_domain WHERE alias_domain.alias_domain = '%d' AND alias.address =
'%u' || '@' || alias_domain.target_domain AND alias.active = '1' AND
alias_domain.active = '1'

Definitely less hurting the head than your query this early in the
morning, imho.

--
Tom

Re: Mapping one domain to another (mysql)

[Tom Hendrikx]

On 8/8/12 11:27 AM, email builder wrote:
 
 query = select if ('%d' = 'example-2.com',
 
 IFNULL((select dest from aliases where addr =
 '%u...@example.com'), (select addr from users where addr =
 '%u...@example.com')), NULL)
 
 I've found that in conjunction with a 2nd query (the original 
 normal one), everything seems to work as expected (including 
 aliases with only local parts like postmaster)
 
 But I'm still unsure if this kind of query is correct, if I'm 
 on the right track. Can anyone tell me if there's a better way
 to do it?
 
 Where are all those examples that are supposedly posted on
 this list previously?
 
 You have been pointed to postfixadmin before, which has all of
 this builtin. Did you check their documentation? Every existing
 db-based postfix adminsitration suite should have an example for
 you.
 
 Sorry, I hoped not to have to learn a whole new tool when it was said
 there were already examples posted to this list. I'll try to take a
 look and see how easy it is to pick up parts like this
 
 My query for alias domains on postgres, using postfixadmin database
 model:
 
 query = SELECT goto FROM postfix_alias AS alias,
 postfix_alias_domain AS alias_domain WHERE
 alias_domain.alias_domain = '%d' AND alias.address = '%u' || '@' ||
 alias_domain.target_domain AND alias.active = '1' AND 
 alias_domain.active = '1'
 
 Definitely less hurting the head than your query this early in the 
 morning, imho.
 
 Beauty is in the eye of the beholder I guess. 

This is not beauty, this is KISS. ;)

I also gave pseudocode
 and after staring at your query, it does part of what mine does, but
 I have a question why it does not do the other part.
 
 What my tests have shown to work is:
 
 0) if %d isn't the aliased domain example-2.com then forget it 
 1) Look in alias table to see if there is an alias for user in the
 target/primary domain example.com, if there is, return it 
 2) If there was not an alias, we must look in the account table to
 find if there is a real account address for user in the target/primary
 domain example.com, if there is, return it 
 3) otherwise, return NULL so postfix can reject the address

pfa has this covered by adding a record in the alias table for both
aliases (b...@example.com-a...@example.com) and mailboxes
(a...@example.com-a...@example.com). This means that a list of all mail
addresses (aliases and mailboxes) are available in alias.address, and
that a single query on that table is enough to check all variants.

If you don't like that design (I don't, but I have other things to worry
about), write a difficult query or again, split the work over separate
lookups: one for aliases in alias domains, and one for accounts in alias
domains.

--
Tom

Re: Mapping one domain to another (mysql)

[Tom Hendrikx]

On 8/6/12 2:28 PM, Benny Pedersen wrote:
 Den 2012-08-06 12:03, email builder skrev:
 
 This causes a bounce instead of reject. Do I have to add a clause for
 this to my query? I start to feel like I'm doing things Postfix should
 be doing. There must be a more simple way to do this?
 
 postfixadmin have domain-alias support fits 100% to subject, makes sense
 if dns data is templated same way
 

Probably the best lesson to learn from postfixadmin is: you can have
more than one lookup table in postfix per main.cf directive.
Postfixadmin uses 2 separate queries for regular aliases and domain
aliases.

from main.cf:
virtual_alias_maps = /etc/postfix/mysql_virtual_alias_maps.cf
/etc/postfix/virtual_alias_domain_maps.cf

where each file contains a simple db query. Makes it much easier to
write the correct query, on the expense of some more db load.

--
Tom

Re: RV: problems again

[Tom Hendrikx]

On 7/19/12 10:52 AM, Tomas Garijo (Click) wrote:
  
 
 Hi to all I am Thomas.
 
 Here I have the same problem 
 
 I have installed a new server this server ip other I is not a gateway,
 not connect with Exchange, is a SMTP Server with mail box in it, I send
 mail via roundcube
 
 I sure my DNS That it's ok, because i pass test for this. But the
 mistake is again
 
snip
 Jul 19 08:09:55 smtp3 postfix/qmgr[24256]: 1425F1C82FF: from=test@e-
 surland.com, size=1473, nrcpt=1 (queue active)
snip
 Jul 19 08:10:13 smtp3 postfix/smtp[24368]: 1425F1C82FF:
 to=tor...@torbus.com, relay=mx.torbus.com[62.149.128.72]:25,
 delay=18, delays=0.06/0.03/0.13/18, dsn=5.1.0, status=bounced (host
 mx.torbus.com[62.149.128.72] said: 550 5.1.0 c8951j03N1pFjQ201895pn
 dominio non valido / invalid domain (in reply to MAIL FROM command))
snip

When testing this with by hand, you get the same result:

$ telnet 62.149.128.72 25
Trying 62.149.128.72...
Connected to mxd4.aruba.it.
Escape character is '^]'.
220 mxcmd03.ad.aruba.it bizsmtp ESMTP server ready
HELO me
250 mxcmd03.ad.aruba.it hello [212.79.224.10], pleased to meet you
MAIL FROM: t...@e-surland.com
550 5.1.0 c9211j03M0E4mr00192RZ2 dominio non valido / invalid domain
quit
221 2.0.0 mxcmd03.ad.aruba.it bizsmtp closing connection
Connection closed by foreign host.

The answer to the MAIL FROM command takes very long, which indicates (to
me at least) that the receiving machine has an issue with resolving the
domain (e-surland.com). This does not happen when you send a MAIL FROM:
some...@gmail.com, so it seems dependant on your domain.

The postmaster at aruba.it has to check why that is happening: I see no
issues with the dns entries for e-surland.com. You cannot give answers
about the remote system yourself. If your client is important to you,
and the postmaster mail address is unreachable, make a phone call or use
their website.

This issue is completely unrelated to postfix now.

--
Tom

Re: Exploring conditional local log and external firewall control. Best practices?

[Tom Hendrikx]

On 02-05-12 19:53, kar...@mailcan.com wrote:
 
 My recently installed Postfix works as I'd hoped; I moved it into full
 production as our corporate server yesterday.
 
 There's one annoyance, and I admit that's all it is, that I'd like to
 get rid of.  *Noisy* pests.  They irritate me.
 
 I'm interested in what others do in similar circumstance.
 
 My 'smtpd_recipient_restrictions' includes checks against DNSBLs, e.g.
 spamhaus.
 
 The typical log pattern for a successful block is 5-10 of these:
 
   May  2 08:13:26 liam postfix/smtpd[17563]: NOQUEUE: reject: RCPT
   from 206.pool85-50-110.dynamic.orange.es[85.50.110.206]: 554
   5.7.1 Service unavailable; Client host [85.50.110.206] blocked
   using zen.spamhaus.org;
   http://www.spamhaus.org/query/bl?ip=85.50.110.206;
   from=hyphenates...@financial-tracking.com to=@..
   proto=ESMTP helo=livebox
 
 within 5 minutes, then another round or few every 4-12 hourse for a
 couple of days.  I'll end up with 10-100 log entries effectively
 documenting the fact that each pest is a pest.
 
 Postfix does what it's supposed to, and blocks them.
 
 I'd like to do two things:
 
 (1) limit log entries for these items with a logical condition:
 
   If this connection rejection has been previously attempted and
   rejected more than Z times within the last YY minutes, then
   reject as usual, but do not bother to log for the next 
   minutes.  Just reject silently.
 
 (2) communicate with a firewall on another box to act according to
 similar logic:
 
   If a connection attempt has been made and rejected more than ZZ
   times within the last  minutes, then add the offending IP to
   an IPTABLES firewall rule on another box
 
 
 I suspect (1) is doable in Postfix configutation, but I haven't noticed
 the right parameter yet.  Is it 'in' Postfix?
 
 For (2) I've starting looking at Fail2Ban.  Seems like it might work. 
 Is there something more native to Postfix that's available?  Or a better
 recommendation?
 

I do this with fail2ban on postscreen rejects, works like a charm (on
the same box).

--
Tom

Re: need some OT help

[Tom Hendrikx]

On 02-05-12 22:45, ghe wrote:

 
 I've asked on several lists, googled, and read books. I can't figure out
 what's going on. I thought the lack of rhost= indicated one of my monit
 monitors. So I turned them all off, and the entries came right in.
 

Sorry for being an arse, but I fail to see why you don't simply follow
up on my advise (and report back) over at [sdlu] about this, or simply
get on-topic and ask on the dovecot mailinglist...

--
Tom

Re: Autoresponse for Postfix problem

[Tom Hendrikx]

On 13-04-12 20:24, J Gao wrote:
 
 We have a Postfix mail server (CentOS 5.7, Postfix, Courier, Virtual
 Domain, MailScanner) and I want setup the autoresponder for Postifx.
 
 I followed the instruction on
 http://nefaria.com/project_index/autoresponse/
 
 I looked the maillog and I found that the filter override seems not
 working. The mail doesn't handle over to the autoresponder, it always
 goes to relay=virtual
 
 Here is the maillog:
 ===
 Apr 13 11:10:51 zeta postfix/smtpd[26079]: 4F5108031:
 client=unknown[24.207.43.101], sasl_method=PLAIN,
 sasl_username=j...@veecall.com

The message arrives from an sasl authenticated client...


 And mu master.cf:
 ==
 # service type  private unpriv  chroot  wakeup  maxproc command + args
 #   (yes)   (yes)   (yes)   (never) (100)
 #
 ==
 smtp  inet  n   -   n   -   -   smtpd
-o content_filter=autoresponder:dummy
 submission inet n   -   n   -   -   smtpd
 #  -o smtpd_enforce_tls=yes
   -o smtpd_sasl_auth_enable=yes
   -o smtpd_client_restrictions=permit_sasl_authenticated,reject

Only submission seems to have sasl enabled, which you are using.
But you seem to have the autoresponder only on the smtpd interface, not
on the submission interface.


Kind regards,
Tom

Re: Autoresponse for Postfix problem

[Tom Hendrikx]

On 13-04-12 20:47, J Gao wrote:
 On 12-04-13 11:35 AM, Tom Hendrikx wrote:
 On 13-04-12 20:24, J Gao wrote:
 We have a Postfix mail server (CentOS 5.7, Postfix, Courier, Virtual
 Domain, MailScanner) and I want setup the autoresponder for Postifx.

 I followed the instruction on
 http://nefaria.com/project_index/autoresponse/

 I looked the maillog and I found that the filter override seems not
 working. The mail doesn't handle over to the autoresponder, it always
 goes to relay=virtual

 Here is the maillog:
 ===
 Apr 13 11:10:51 zeta postfix/smtpd[26079]: 4F5108031:
 client=unknown[24.207.43.101], sasl_method=PLAIN,
 sasl_username=j...@veecall.com
 The message arrives from an sasl authenticated client...
 Yes, this is required by the autoresponse perl script.
 From: http://nefaria.com/project_index/autoresponse/
 For security reasons, SASL authentication is required in order to
 configure autoresponses via e-mail
 

 And mu master.cf:
 ==
 # service type  private unpriv  chroot  wakeup  maxproc command + args
 #   (yes)   (yes)   (yes)   (never) (100)
 #
 ==
 smtp  inet  n   -   n   -   -   smtpd
-o content_filter=autoresponder:dummy
 submission inet n   -   n   -   -   smtpd
 #  -o smtpd_enforce_tls=yes
   -o smtpd_sasl_auth_enable=yes
   -o smtpd_client_restrictions=permit_sasl_authenticated,reject
 Only submission seems to have sasl enabled, which you are using.
 But you seem to have the autoresponder only on the smtpd interface, not
 on the submission interface.

 Sorry I am still learning Postfix. So do you mean I should add the
 filter to submission as well?
 
 smtp  inet  n   -   n   -   -   smtpd
-o content_filter=autoresponder:dummy
 submission inet n   -   n   -   -   smtpd
 #  -o smtpd_enforce_tls=yes
   -o smtpd_sasl_auth_enable=yes
   -o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o content_filter=autoresponder:dummy
 

If SASL is required, you should not add it to the smtp line since that
does not support sasl (depends on your main.cf which you did not show)
but only to submission.

Note that Reindls point is true: anyone with a valid sasl account would
be able to activate an autoresponder for any other user. If a web gui is
the right solution depends on your use case, but issues will arise
without more restrictions.

As autoresponder seems to require the envelope_sender to be the same as
the one you're configuring autoresponder for, this might be a nice job
for reject_sender_login_mismatch. See
http://www.postfix.org/SASL_README.html#server_sasl_authz

--
Tom

Re: postfix REGEX bug ???

[Tom Hendrikx]

On 29/03/12 10:51, Женя wrote:
 I'm using postfix (2.7.0 on Ubuntu Linux 10.04.3) as mail relay and
 antispam filter. It's set up and works perfectly except one small
 bug. I use smtpd_client_restrictions to filter SMTP clents as
 following:
 
 smtpd_client_restrictions = permit_mynetworks, 
 reject_unknown_client_hostname, check_client_access
 regexp:/etc/postfix/client_access
 
 And /etc/postfix/client_access with number of regex rules like: 
 /google\.com/   OK /mail\.ru/ OK .. 
 /schweiz029\.startdedicated\.com/   REJECT /rusguru/
 REJECT /mail\.agere\.pt/   REJECT /relay\.tmsoft\-ltd\.com/
 REJECT
 
 
 This setup works like designed, filtering all clients successfully
 except ONE (/rusguru/ expression):

 
 As everyone can see postfix does not proper match regex expression.
 I've tried first full domain regex like /rusguru\.ru/, shorted to
 /rusguru/ only - no success.

Hi,

Your regexes aren't terminated, which means that /mail\.ru/ does also
match 'mail.rusguru.ru'. If you OK that as per your example, then that
is your issue: you let them in yourselves...

--
Tom

Re: AW: forcing MX lookups

[Tom Hendrikx]

On 21-02-12 20:06, Ed W wrote:
 On 16/02/2012 23:07, Tom Hendrikx wrote:
 On 16-02-12 23:52, Dipl.-Ing. Juergen Ladstaetter wrote:
 Thank you both very much. That input was very good and I might
 rethink the
 strategy we're aiming at. Probably active DNS checks and periodic
 re-checks
 are better to ensure some security. Thanks guys

 Checking DNS at input time would still suffice.

 You simply require that domains entered have their MXen pointing to a
 predefined set of hosts (your cluster). They might change their own MX
 records later on (which will only harm the customer), but ibm.com will
 never point to your MXen to your cluster, so no customer can ever
 enter it.

 As long as you don't allow changing the domain itself without a
 re-check, no customer will ever be able to configure a domain that has
 MX records not controlled by that same customer.

 Shops that do hosted exchange etc (google, outlook.com) ask you to
 (temporarily) add some unique key/identifier to your DNS zone on order
 to prove that you actually own the zone (and the MX records). Same
 principle, but a bit more work for the customer.

 -Ursprüngliche Nachricht-
 Von: owner-postfix-us...@postfix.org
 [mailto:owner-postfix-us...@postfix.org] Im Auftrag von /dev/rob0
 Gesendet: Thursday, February 16, 2012 3:38 PM
 An: postfix-users@postfix.org
 Betreff: Re: forcing MX lookups

 On Thu, Feb 16, 2012 at 03:20:30PM -0500, Michael Orlitzky wrote:
 On 02/16/2012 12:13 PM, Dipl.-Ing. Juergen Ladstaetter wrote:
 yet. Is there any way to configure postfix to always make MX record
 DNS lookups, or is the only way through a second postfix instance
 that has no localdomains specified?
 Even with two instances you could have problems.

 For example, your users might have aliases that get expanded on the
 incoming instance, where the maps are controlled by customers. If one
 of your customers sets up example.com, and has u...@example.com
 aliased to u...@example.net hosted elsewhere, they could be open to
 another customer stealing the example.net mail.
 If there is a way to force all alias expansion to go through the clean
 instance, this might work. Only thing I can think of is to append a
 domain
 component to all such names as used in aliasing, stripping it off on
 the way
 out. Then if it's valid, the clean
 relayhost would pass it right back.

 u...@example.comu...@example.net.Juergen

 Maybe either generic(5) maps on the dirty instance, or canonical(5)
 on the
 clean one, could strip this out and send it properly.

 One instance per customer is /probably/ safe, but I wouldn't swear to
 it without some more thought.
 At least in that case they'd only have themselves to blame. :)

 I would also consider periodic automated DNS checks which would
 disable any
 domain where DNS points elsewhere. (Or at least alert administrators to
 check on it.)
 
 The alias expansion suggestion above also highlights how/why this is
 quite a challenging problem if you can only rely on polling DNS entries
 that you don't control to see if some twit changed them on you... Also
 the dual instance fix is an imperfect solution... Ideally we would have
 support from the MTA itself..

 I think this is a general problem for any mail admin who needs to
 allow (untrusted) customers to dynamically update the list of domains
 hosted on a given machine (ie where the customer controls the DNS,
 not us).  I have the same problem and don't have a clean solution.  I
 suspect that the folks arguing in favour of trying to make this
 solely a web application problem don't have such a customer base?


I don't run a setup like this, but deal with the DNS verification part
of it on a daily basis. I fail to see the real issue here: if a customer
actually owns the domain, and he changes the MX records to somewhere
else, he'll only scatter his mail delivery (i.e. local mail on your
platform, other mail on the new MXen), but this does not harm you, only
the customer. Whether the customer is fraudulent or not, he can only
influence deliverability of domains he actually added by himself, or
that he owns in DNS.

The single challenge is that you need to verify that the customer can
only add a domain that he actually owns, in order to make sure that no
customer can steal mail for remote destinations that aren't his. This
last part is relatively easy to solve by creating a procedure to verify
that the customer is the owner of the domain in DNS, by requiring him to
add a specific key to the zone for ownership verification. Simply said:
Google [1] and many others have already solved this issue, I don't see
why your situation differs from theirs.

Also I fail to see how a fraudulent customer would be able to steal mail
for example.net as described in the alias example, if he's not able to
prove that he owns the example.net zone in DNS (thus cannot add the
example.net zone to your localdomains). Please educate me.

[1] http://support.google.com/a/bin/answer.py?hl=enanswer=183895

Re: AW: forcing MX lookups

[Tom Hendrikx]

On 16-02-12 23:52, Dipl.-Ing. Juergen Ladstaetter wrote:
 Thank you both very much. That input was very good and I might rethink the
 strategy we're aiming at. Probably active DNS checks and periodic re-checks
 are better to ensure some security. Thanks guys
 

Checking DNS at input time would still suffice.

You simply require that domains entered have their MXen pointing to a
predefined set of hosts (your cluster). They might change their own MX
records later on (which will only harm the customer), but ibm.com will
never point to your MXen to your cluster, so no customer can ever enter it.

As long as you don't allow changing the domain itself without a
re-check, no customer will ever be able to configure a domain that has
MX records not controlled by that same customer.

Shops that do hosted exchange etc (google, outlook.com) ask you to
(temporarily) add some unique key/identifier to your DNS zone on order
to prove that you actually own the zone (and the MX records). Same
principle, but a bit more work for the customer.

 
 -Ursprüngliche Nachricht-
 Von: owner-postfix-us...@postfix.org
 [mailto:owner-postfix-us...@postfix.org] Im Auftrag von /dev/rob0
 Gesendet: Thursday, February 16, 2012 3:38 PM
 An: postfix-users@postfix.org
 Betreff: Re: forcing MX lookups
 
 On Thu, Feb 16, 2012 at 03:20:30PM -0500, Michael Orlitzky wrote:
 On 02/16/2012 12:13 PM, Dipl.-Ing. Juergen Ladstaetter wrote:

 yet. Is there any way to configure postfix to always make MX record 
 DNS lookups, or is the only way through a second postfix instance 
 that has no localdomains specified?

 Even with two instances you could have problems.

 For example, your users might have aliases that get expanded on the 
 incoming instance, where the maps are controlled by customers. If one 
 of your customers sets up example.com, and has u...@example.com 
 aliased to u...@example.net hosted elsewhere, they could be open to 
 another customer stealing the example.net mail.
 
 If there is a way to force all alias expansion to go through the clean
 instance, this might work. Only thing I can think of is to append a domain
 component to all such names as used in aliasing, stripping it off on the way
 out. Then if it's valid, the clean 
 relayhost would pass it right back.
 
 u...@example.com  u...@example.net.Juergen
 
 Maybe either generic(5) maps on the dirty instance, or canonical(5) on the
 clean one, could strip this out and send it properly.
 
 One instance per customer is /probably/ safe, but I wouldn't swear to 
 it without some more thought.
 
 At least in that case they'd only have themselves to blame. :)
 
 I would also consider periodic automated DNS checks which would disable any
 domain where DNS points elsewhere. (Or at least alert administrators to
 check on it.)
 --
   http://rob0.nodns4.us/ -- system administration and consulting
   Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
 

Re: Postfix MX selection

[Tom Hendrikx]

On 12/29/2011 01:00 PM, Stan Hoeppner wrote:

On 12/29/2011 5:23 AM, Thomas Bange wrote:

Hi,

I have a mail stuck in my mail queue. The Mail should be delivered to
some.u...@some-domain.de.

Looking up MX records for the domain gives me:

# host -t mx some-domain.de
some-domain.de mail is handled by 100 relay2.netnames.net.
some-domain.de mail is handled by 10 relay1.netnames.net.

Postfix is always attempting to deliver the mail through
relay2.netnames.net, which gives the following error:

host relay2.netnames.net[212.53.64.44] said: 451 lowest numbered MX
record points to local host (in reply to RCPT TO command)

The server seems to have a config problem, but why does Postfix tries to
deliver the mail through relay2.netnames.net instead of
relay1.netnames.net?


This is not a Postfix problem.  You know how to use Google yes?

Given there is definitely a DNS configuration problem on the remote end,
do not assume Postfix is doing something incorrect by attempting
delivery to the priority 10 MX host.




If it's not a resolver cache issue you need to contact the
administrator(s) of the remote systems(s) and inform them of the problem.



The valid Postfix related question is why it doesn't try to use 
relay1.netnames.net for delivery when relay2.netnames.net keeps 
returning 451s.


$ telnet relay1.netnames.net 25
Trying 62.128.158.226...
telnet: Unable to connect to remote host: Connection refused

Answer: relay1 is not available, which should be logged by postfix too, 
but the OP missed it somehow.


--
Tom

Re: Unable to send e-mail

[Tom Hendrikx]

On 19/10/11 15:30, Tolga wrote:
 
 
 On 10/19/2011 04:01 PM, Reindl Harald wrote:

 Am 19.10.2011 14:57, schrieb Tolga:
 Oct 19 15:40:01 vps postfix/pickup[3517]: 5DBFA4100B2B: uid=1005
 from=iegg
 Oct 19 15:40:01 vps postfix/cleanup[3575]: 5DBFA4100B2B:
 message-id=20111019124001.5dbfa4100...@mail.bilgisayarciniz.org
 Oct 19 15:40:01 vps postfix/qmgr[5859]: 5DBFA4100B2B:
 from=i...@vps.ozses.net, size=652, nrcpt=1 (queue active)
 Oct 19 15:40:01 vps postfix/smtp[3577]: 5DBFA4100B2B:
 to=i...@vps.ozses.net, orig_to=iegg, relay=none,
 delay=0.04, delays=0.02/0.01/0.01/0, dsn=5.4.4, status=bounced (Host
 or domain name not found. Name service error
 for name=vps.ozses.net type=A: Host not found)
 Oct 19 15:40:01 vps postfix/cleanup[3575]: 66B774100B2C:
 message-id=20111019124001.66b774100...@mail.bilgisayarciniz.org
 Oct 19 15:40:01 vps postfix/qmgr[5859]: 66B774100B2C: from=,
 size=2672, nrcpt=1 (queue active)
 Oct 19 15:40:01 vps postfix/bounce[3579]: 5DBFA4100B2B: sender
 non-delivery notification: 66B774100B2C
 Oct 19 15:40:01 vps postfix/qmgr[5859]: 5DBFA4100B2B: removed
 Oct 19 15:40:01 vps postfix/smtp[3577]: 66B774100B2C:
 to=i...@vps.ozses.net, relay=none, delay=0, delays=0/0/0/0,
 dsn=5.4.4, status=bounced (Host or domain name not found. Name
 service error for name=vps.ozses.net type=A: Host
 not found)
 Oct 19 15:40:01 vps postfix/qmgr[5859]: 66B774100B2C: removed
 what do you expect?
 vps.ozses.net != ozses.net and has no MX or A-records

 Sorry, those were the logs of another transaction (didn't look closely
 enough :() For the postfixadmin transaction, I have no logs. Is this
 even possible?
 

Postfixadmin will try to send the mail using the mail() function in
postfix. This command should work in the first place: check your PHP logs.

Most likely (but depending on your setup in php) this will handoff the
mail to the sendmail(1) binary on the webserver hosting postfixadmin.
This will try to send the message to the recipient: the mailaccount you
just created. If this message never arrives on your postfix mailserver
because something is wrong, there will be no postfix logging.

So: to check why postfixadmin cannot send the e-mail, check the error
logging of php/apache until you find an error line telling you why the
message could not be sent by PHP. This is not a postfix-related issue
until the message hits your postfix install.


-- 
Regards,
Tom

Re: Using Spamassassin as content filter

[Tom Hendrikx]

On 19-10-11 17:33, Daniele Nicolodi wrote:
 On 19/10/11 16:01, Kris Deugau wrote:
 Daniele Nicolodi wrote:
 Sieve can not call external programs, therefore I do not know ho to hook
 Spamassassin there, and, furthermore, I would like to avoid to have to
 setup things for each user.

 O_o  News to me.  Maybe there's some option to do this in dovecot-lda? 
 Is there a global sieve configuration similar to /etc/procmailrc?  I 
 don't use either so I can't really suggest anything else that wouldn't 
 be a big change in your mail processing.
 
 This is actually a selling point for Sieve: you can make untrusted users
 to upload their filtering rules, without worring about security.
 
 Dovecot sieve implementation have the possibility to call some global
 filtering rules, but those can not pipe the received messages through
 external programs, similarly to the user defined ones.
 that allows pipe 

Actually, there is an experimental extension for dovecot sieve that
allows piping to external commands, but with a quite secure design
(sysadmin controls which commands are available to the pipe extension).
It works quite nice in the current state, and will probably be included
some day by the dovecot sieve implementation.

See http://wiki2.dovecot.org/Pigeonhole/Sieve/Plugins/Pipe

Mailutils sieve also has a pipe implementation, which I did not test but
looks (from the documentation) less secure because it allows the user to
call arbitrary commands. I never checked courier or others.

Anyway, the administrator can always simply remove support for the
extension, something that probably lacks when using procmail.

You'd still be better off feeding messages to SA from the MTA, and let
sieve just move messages around based on added headers.

--
Tom

Re: Using Spamassassin as content filter

[Tom Hendrikx]

On 19-10-11 18:54, Daniele Nicolodi wrote:
 On 19/10/11 18:46, Tom Hendrikx wrote:
 Actually, there is an experimental extension for dovecot sieve that
 allows piping to external commands, but with a quite secure design
 (sysadmin controls which commands are available to the pipe extension).
 It works quite nice in the current state, and will probably be included
 some day by the dovecot sieve implementation.

 See http://wiki2.dovecot.org/Pigeonhole/Sieve/Plugins/Pipe
 
 Nice to know.
 
 You'd still be better off feeding messages to SA from the MTA, and let
 sieve just move messages around based on added headers.
 
 I agree and that's exactly my current solution, but I have some
 questions regarding how I'm doing that. Without repeating myself, can
 you please have a look at my configuration in the mail that originated
 this thread and comment on my solution?

I don't use SA myself so I have no experience with integrating it with
postfix, but some slacking around on the spamasasin website led me to
http://wiki.apache.org/spamassassin/IntegratedSpamdInPostfix, whose
first lines clearly mention the flaws you're system will run into
(generate backscatter, for instance)

My previous attempts in setting up a mailsystem that uses all kinds of
bells and whistles, but also tries to do everything on the smallest
scale possible (such as running content filters under system user
accounts), always failed miserable. In the end I implemented an
ISP-style setup even though my setup is only used by three persons and a
cat. I suggest you try the spampd or the amavisd-new approach.

--
Regards,
Tom

Re: Relay transport works, then stops

[Tom Hendrikx]

On 26/08/11 22:16, lance raymond wrote:
 
 My transport file looks like this; (one example)
 members...@domain.com mailto:members...@domain.com
 smtp:[ASPMX.L.GOOGLE.COM http://ASPMX.L.GOOGLE.COM]:25
 
 When postfix was started and happy, an example looked like this;
 
 pwsdata postfix/smtp[840]: A0FAD7E22C: to=members...@domain.com
 mailto:members...@domain.com, relay=ASPMX.L.GOOGLE.COM
 http://ASPMX.L.GOOGLE.COM[74.125.113.27]:25, delay=1.5,
 delays=0.07/0.01/0.14/1.3, dsn=2.0.0, status=sent (250 2.0.0 OK
 1313600883 s8si3016648vdh.46)
 
 I got a call saying mail hasn't been recieved to support or membership
 which is odd, and when I look I see the following;
 
 12:20:30 pwsdata postfix/pipe[31348]: E57127E232:
 to=members...@domain.com mailto:members...@domain.com,
 relay=dovecot, delay=0.27, delays=0.17/0.01/0/0.1, dsn=2.0.0,
 status=sent (delivered via dovecot service)
 

The message that goes to the google transport enters postfix via smtp,
the failing one via pipe (i.e. sendmail(1) command line util on the host).

My crystal ball says that your transport map is only applied to smtp
traffic, but since you forgot to include postconf -n, we can only guess.

ow, and please lose the html mail.

--
Tom

Re: Postfix rejecting all incoming emails sent from outside localhost

[Tom Hendrikx]

On 30/07/11 12:29, Miguel Guedes wrote:
 Hi,
 
 I've recently followed a guide I found online [1] and installed Postfix and 
 Courier on my server machine. I can send emails from the server to any email 
 address but unfortunately I can only receive emails sent from the server - 
 it's only accepting emails sent locally from the host. In other words, if I 
 try sending myself an email from, say, Gmail, it is rejected and an error 
 email generated (see below.)
 
 /etc/postfix/main.cf: http://pastebin.com/gETbUt1C
 Error email generated: http://pastebin.com/JnJbvpkT

Please use postconf -n to show your configuration, as per the welcome
message of this mailing list.

Apart from that, my first guess is that gmail is talking to another
machine, especially since you state that there are no logs generated
when sending from gmail. Please review your MX records, we can't do that
since you obfuscated your domains.

--
Tom

Re: Accepting only bona fide plus addresses

[Tom Hendrikx]

On 27/04/11 18:52, Jerry wrote:
 I am in the process of setting up a mail system with plus addressing.
 Presently it is using Dovecot with sieve to filter the mail. What I
 want to do is limit the number of plus addresses that are accepted.
 
 Example:
 
 Employees: Tom, Joe, Jane
 
 An email to either sa...@example.com or sales+...@example.com should
 both be accepted.
 
 However, sales+fr...@example.com should not be accepted.
 
 My question is how to most efficiently implement this sort of setup
 within Postfix? Do I need a milter to accomplish this?
 

If you want a limited set of recipient email addresses, you should not
use plus addressing. The correct solution to your problem is to create
regular aliases to sales@ named after the person:

sales-...@example.org - sa...@example.org
sales-j...@example.org - sa...@example.org


-- 

Regards,
Tom

Re: Problems with postfix while sending emails

[Tom Hendrikx]

On 15/03/11 15:10, Wietse Venema wrote:
 Rafael Azevedo:
 [ Charset ISO-8859-1 unsupported, converting... ]
 Hi Wietse!

 Thanks again for helping me!

 Here is the postfix log:

 # SLOW DOMAIN
 Mar 15 10:37:46 mxcluster postfix/smtpd[22804]: connect from
 srv01.iagentemail.com.br[189.38.86.124]
 Mar 15 10:37:46 mxcluster postfix/smtpd[22804]: 70E82E42D0: client=
 srv01.iagentemail.com.br[189.38.86.124]
 Mar 15 10:37:46 mxcluster postfix/cleanup[21751]: 70E82E42D0: message-id=
 8d3ee53c5d281ab3dae9471182931...@iagentemail.com.br
 Mar 15 10:37:46 mxcluster dkim-filter[4513]: 70E82E42D0 DKIM-Signature
 header added
 Mar 15 10:37:47 mxcluster postfix/qmgr[27773]: 70E82E42D0: from=
 reto...@iagentemail.com.br, size=629, nrcpt=2 (queue active)
 Mar 15 10:37:47 mxcluster postfix/smtp[23002]: 70E82E42D0: host
 mx2.iagente.com.br[189.38.95.92] said: 450 4.7.1 Client host rejected:
 cannot find your hostname, [187.1.133.20] (in reply to RCPT TO command)
 Mar 15 10:37:47 mxcluster postfix/smtpd[22804]: lost connection after RSET
 from srv01.iagentemail.com.br[189.38.86.124]
 Mar 15 10:37:47 mxcluster postfix/smtpd[22804]: disconnect from
 srv01.iagentemail.com.br[189.38.86.124]
 
 The above message is rejected because 187.1.133.20 has no PTR record.

There are 2 nameservers listed in DNS that should have PTR records for
133.1.187.in-addr.arpa, both of these have 2 ip-addresses, resulting in
4 DNS servers to check. Two of these return correct data,  the other two
return no PTR record, and a strange looking SOA, for that matter.

$ dig ns 133.1.187.in-addr.arpa

;  DiG 9.7.1-P2  ns 133.1.187.in-addr.arpa
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 34523
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 4

;; QUESTION SECTION:
;133.1.187.in-addr.arpa.IN  NS

;; ANSWER SECTION:
133.1.187.in-addr.arpa. 5234IN  NS  ns1.dns2.com.br.
133.1.187.in-addr.arpa. 5234IN  NS  ns2.dns2.com.br.

;; ADDITIONAL SECTION:
ns1.dns2.com.br.84434   IN  A   187.1.143.64
ns1.dns2.com.br.84434   IN  A   189.38.86.79
ns2.dns2.com.br.84434   IN  A   187.1.143.65
ns2.dns2.com.br.84434   IN  A   189.38.86.80

$ dig +short -x 187.1.133.20 @189.38.86.79
mxcluster.iagentemail.com.br.
= OK

$ dig +short -x 187.1.133.20 @187.1.143.64
= No PTR, this is your problem

$ dig +short soa 133.1.187.in-addr.arpa @187.1.143.64
cyrus.webpro.com.br. raffus.gmail.com. 1299803423 10800 3600 604800 10800
= Google mailbox as hostmaster address?

I think the person maintaining the DNS address space of *your
mailserver* made a typo or a config error somewhere.

Regards,
Tom



signature.asc
Description: OpenPGP digital signature

Re: [Q] smtpd: warning: n.n.n.n: address not listed for hostname smtp.academicjobseu.com

[Tom Hendrikx]

On 15/02/11 13:18, J4K wrote:
 
 Hi,
 
 I just watched an IP address fail to be correctly resolved back to
 the A record.  I could resolve the IP with the the same DNS on the same
 server myself.
 
 These connection from a server is recorded by postfix as unknown for
 212.89.81.105, yet an nslookup on this IP resolves back to the correct
 address:-
 
 Non-authoritative answer:
 105.81.89.212.in-addr.arpaname = smtp.academicjobseu.com.
 

But the other way round, there is a mismatch:

$ dig +short smtp.academicjobseu.com
212.89.81.106

The owner of the MX will need to fix this to prevent the error.

 
 Feb 15 13:06:26 logout postfix/smtpd[111]: warning: 212.89.81.105:
 address not listed for hostname smtp.academicjobseu.com
 Feb 15 13:06:26 logout postfix/smtpd[111]: connect from
 unknown[212.89.81.105]
 Feb 15 13:06:29 logout postfix/smtpd[111]: 3E42B81E81:
 client=unknown[212.89.81.105]
 Feb 15 13:06:34 logout dkim-filter[222]: 3E42B81E81: no signature data
 Feb 15 13:06:34 logout postfix/qmgr[111]: 3E42B81E81:
 from=ag...@smtp.academicjobseu.com
 mailto:ag...@smtp.academicjobseu.com, size=, nrcpt=1 (queue active)
 Feb 15 13:06:34 logout postfix/smtpd[111]: disconnect from
 unknown[212.89.81.105]
 
 Is there something that I missed in the postfix configuration? 
 
 Best wishes, S




signature.asc
Description: OpenPGP digital signature

Re: Reject unencrypted messages

[Tom Hendrikx]

On 06/01/11 20:06, IT geek 31 wrote:
 I am talking about the mail content, and I'm using S/MIME.
 
 Yes, I'm sure the accountant will never send me unencrypted mail.
 
 Thanks,
 
 
 
 On 6 January 2011 14:25, Ansgar Wiechers li...@planetcobalt.net wrote:
 On 2011-01-06 IT geek 31 wrote:
 My accountant and I both have digital certificates and most of the
 time encrypt our mails.  But he often forgets, meaning sensitive
 information is sent in plaintext.

 Is there any way to instruct Postfix to reject his mail unless it is
 encrypted?

As soon as the unencrypted e-mail is sent by the accountant, your
sensitive information might already be sniffed, somewhere between the
MUA/MTA of your account and the MTA you control. You could use a setup
like this to teach your accountant better manners, but your information
is out on streets none the less.

Seems like you are solving the wrong problem here.

--
Regards,
Tom



signature.asc
Description: OpenPGP digital signature

Temporarily disable mail acceptance

[Tom Hendrikx]

Hi,

To do some maintenance work, I need to temporarily disable mail
acceptance in my postfix MX. I'm curious what is the best way to do
this. The 2 (obvious) options I came up with:

1) stop listening on tcp/25, f.i. by firewall adjustment
2) adding some access check in smtpd_mumble_restrictions that returns
DEFER for all transactions that would otherwise be accepted.

There is no backup/fallback/secondary MX that comes into play when I
start fumbling with this one. Is any of the above methods preferable?

-- 
Regards,
Tom



signature.asc
Description: OpenPGP digital signature

Re: Negation in header_checks doesn't work as expected?

[Tom Hendrikx]

On 14/07/10 06:11, Hendra . wrote:
 Hi All,
 
 I'm new to postfix as well as to this mailing list, so I apologize in
 advance for any blunder ;)
 
 Need some expert advice on what I'm trying to achieve but encountered
 a major roadblock so far.
 I need a mail server with a catch-all address but limit the recipient
 pattern to -keyw...@example.com, and forward it to an existing
 local account.
 The -keyw...@example.com is an auto-generated address by another
 application so these addresses will not be available as a lookup/map
 table to postfix.
 So far the postfix server I've setup can already accept the catch-all
 address and forward it the local account as intended, however I want
 to reject those that
 do not match the -keyword pattern, even existing for existing
 account that doesn't have the keyword in the name.
 I've tried using the regexp in header_checks, but as soon as I added
 the negation, it doesn't work as expected.
 For example:
 
 !/^To: (.*)-keyword@(.*)$/ REJECT   = all mails get rejected
 
 Any help?
 
 H
 

It looks like this could be solved more easily with a recipient
delimiter and maybe some minor changes on the address generation side to
deliver mail to keyword+...@example.com to mailbox keyw...@example.com
automatically.

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

Regards,
Tom

Re: fail2ban for spamtraps

[Tom Hendrikx]

On 23/06/10 16:28, Phil Howard wrote:
 On Tue, Jun 22, 2010 at 16:46, Michael Orlitzky mich...@orlitzky.com wrote:
 
 A word of caution: don't assume that everyone browses the web using a
 graphical web browser. People still browse from the command line, and more
 importantly, screen readers for the disabled. If you're going to hide an
 address, make sure that there is some indication (for humans) that the
 address should not be contacted under any circumstances.
 
 Good point.  I was thinking that for these, the dummy addresses would
 just not be sent out.  No harm of spammers are doing scans using these
 methods, too.  So I'm thinking just output those addresses when the
 conditions are such that it appears to be graphical browsing, under
 the theory that spammers would likely be attempting to look like that,
 too.
 

Actually, when using a visual browser, people still can use their own
colouring (again, the visually impaired). What you are suggesting is
generating browser-specific output. This practise has been tried,
tested, and discarded in webdesign country for some years now (we're
getting OT here) as it does not work for all audiences, and in general
creates an unmaintainable mess.

If you want spam traps advertised, there are numerous better ways.
Adding a clear (The following e-mail address is solely targetted at
catching mail abuse, do not use it for mail interaction:
foo...@example.com) or more cryptic message (The trapper recommends
today: foo...@example.com) to the e-mail address will stop humans from
using it, but harvesters will still pick it up.

Keep in mind: automated harvesters can impersonate regular people (or
browsers), but they cannot think like one.

-- 
Regards,
Tom



signature.asc
Description: OpenPGP digital signature

Re: Stopping spam from a specifig subnet (relayed through a freemail provider)

[Tom Hendrikx]

On 06/05/10 10:58, Louis-David Mitterrand wrote:
 On Wed, May 05, 2010 at 01:44:54PM -0400, Brian Evans - Postfix List wrote:
 
 You could try this in /etc/postfis/header_checks

 if 
 /^(Received|X-((Origin(ating)?|Client|MDRemote|Sender)-?IP|(Client|Remote_)Addr|PHP-Script)):/
 if 
 !/^(X-Original-)?To:[...@]*(africanspamlover1|africanspamlover2|etc..)@/
 /\b(41\.1(6\d|7[0-5])\.\d+\.\d+)\b/ REJECT african spam rule 1
 /\b(41\.3(6\d|7[0-5])\.\d+\.\d+)\b/ REJECT african spam rule 2
 .. and all other rules ...
 endif
 endif

 This will not work.
 Postfix analyzes headers one at a time.
 You cannot check multiple headers at once in header_checks.
 You need a milter or other filter to do that.
 
 Could this be entered as a postfix wishlist item then? A 'm' flag to
 pcre_table that would match on the whole headers (instead of
 line-by-line), akin to Perl's 'm' regexp flag:
 
   m   Treat string as multiple lines.  That is, change ^ and $ from
   matching the start or end of the string to matching the start or
   end of any line anywhere within the string.
 
 It would be very powerful, yet retain the ability to match on any
 individual header line with ^ and $ anchors.
 

Hi,

I think that postfwd can do all of this already, working as a policy
daemon. See http://www.postfwd.org/

No need to complicate postfix any further: it is an MTA, and should
concentrate on mail delivery. There is a reason that you can hook up a
myriad of external tools into postfix.

--
Regards,
Tom

Re: Outgoing Approval Queue - Yes This is a Dumb Idea

[Tom Hendrikx]

Zachary Burns wrote:
 I have a company controller that loves to micro-manage people and
 unfortunately loves to do it with software instead of dealing with the
 people problem...but anyway I'm getting off on a rant
 
 Is there a way to have postfix queue outgoing mail until he reviews it and
 if it's valid release the email and send it as normal.  I can write a web
 interface to have him allow/deny messages in the queue, but wanted to even
 know if I'm barking up the wrong tree.
 
 If he wants to sit there all day approving/denying messages that's fine with
 me (but I think it's a waste - just fire the employees!  There's plenty of
 good people out there that would love a job now-a-days).
 
 Zack
 

Hi,

As you said, ranting about the initial idea is food for a separate
thread. The issue you want to resolve, sounds a lot like mailing list
software with posting approval.

I'm not sure if existing mailing list software has the option to send to
arbitrary recipients (ignoring the 'list' concept), or can be hacked
easily into doing what you need. Setting up postfix into pushing all the
e-mail from 'monitored employees' to the mailing list software seems
trivial to me.

--
Regards,
Tom

Re: Mail to wildcard MX records doesn't work from Yahoo Mail, but fine from other addresses

[Tom Hendrikx]

Bob Eastbrook wrote:

 NOQUEUE: reject: RCPT from
 web81307.mail.mud.yahoo.com[68.142.199.123]: 554 5.7.1
 b...@myapp.appspot.com: Relay access denied;
 from=a-yahoo-u...@yahoo.com to=b...@myapp.appspot.com proto=SMTP
 helo=web81307.mail.mud.yahoo.com
 

This says that the yahoo user tries to send mail addressed to
b...@myapp.appspot.com, not to b...@example.org.

Your mail server is not configured to accept mail for that domain (but
DNS records point to it), so either:
- do not send mail to *...@myapp.appspot.com
- add myapp.appspot.com to $mydestination

Regards,
Tom

Re: Sending email from a pool of IP addresses

[Tom Hendrikx]

David Michard wrote:
 we are having more and more problems with
 very conservative SMTP servers enforcing a low number of simultaneous
 connections from a single IP address. Our subscribers wish to receive
 their email as soon as possible so delaying the email for a few hours
 is not an option.

So actually you are trying to solve the other mail servers trouble. Did
you contact (some of) them to get you whitelisted?

 Is it possible to tell postfix to randomly select an IP address, and
 associated hostname (as many smtp servers perform RDNS lookups and
 compare it to the HELO/EHLO greeting) when sending an email ?
 That would be very helpful.

It seems to me that
http://www.mailinglistarchive.com/postfix-users@postfix.org/msg57399.html
contains a recipe that solves your problem, only missing a 5-line perl
policyd that returns a random transport.

--
Regards,
Tom

Re: OT: Alternative for Spamassassin

[Tom Hendrikx]

Michael Reck wrote:

 I`m looking for a SA replacement in an large scale enviroment.
 DSPAM seems to use filesystem (--with-userdir=) for various functions
 which is not what i want. dspam also needs per user activation.

Your assumptions about Dspam are wrong. Using --with-userdir is
optional, and Dspam can do Optin/Optout, but this is configurable, ad
depending on your setup there is no work penalty for adding new users.

 Anything except Mailstorage is placed in DB and i don`t want to change
 this.

Dspam can do this with an SQL backend

 - Support for 80k+ Users, Multiple node cluster

I have no experience with this kind of userbase, but some ppl on the
dspam mailing list have ISP-sized setups running.

 Any ideas ?

Give DSPAM a second look :)

-- 
Regards,
Tom



signature.asc
Description: OpenPGP digital signature

connections from ipv4 localhost logged as unknown[127.0.0.1]

[Tom Hendrikx]

Hi,

After setting up postfix up on a ipv4/ipv6 dualstack machine I'm seeing
the following issue: connections on 127.0.0.1 (where my content_filter
re-injects mail) are logged as:

010-01-13T22:51:07+01:00 meredith-vmail postfix/smtpd[4772]: warning:
127.0.0.1: address not listed for hostname ip6-localhost
2010-01-13T22:51:07+01:00 meredith-vmail postfix/smtpd[4772]: connect
from unknown[127.0.0.1]

After some time reading google and debugging this is what I found out:
- /etc/hosts contains the following stuff regarding localhost (in the
specified order):
::1 ip6-localhost ip6-loopback
127.0.0.1 localhost

- The test utils in auxiliary/name-addr-test show the same behaviour as
postfix itself:
./getnameinfo 127.0.0.1
Hostname:   ip6-localhost
Address:127.0.0.1
./gethostbyaddr 127.0.0.1
Hostname:   ip6-localhost
Aliases:ip6-loopback
Addresses:  127.0.0.1

- After some tests, I can (temporarily) fix this in 3 ways:
1) Changing postfix's main.cf to use only ipv4 (comment
inet_protocols=all + restart)
2) Removing  the line for ::1 in /etc/hosts
3) Change the order of /etc/hosts, placing the line for ::1 below 127.0.0.1

All of the above on Gentoo Linux, 2.6.27-openvz-briullov.1-r4 kernel,
Postfix 2.6.5 and glibc 2.10 (also tested with 2.9). Postconf -n looks
like this:

command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = //usr/lib/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
home_mailbox = .maildir/
html_directory = /usr/share/doc/postfix-2.6.5/html
inet_protocols = all
local_recipient_maps = $alias_maps
mail_owner = postfix
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
mydomain = whyscream.net
myhostname = a.mx.whyscream.net
mynetworks = cidr:/etc/postfix/mynetworks
myorigin = $myhostname
newaliases_path = /usr/bin/newaliases
proxy_interfaces = 217.149.194.147
proxy_read_maps = $virtual_mailbox_domains, $virtual_mailbox_maps,
$virtual_alias_maps
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.6.5/readme
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks reject_non_fqdn_hostname
   reject_invalid_hostname permit
smtpd_recipient_restrictions = permit_mynetworks
reject_unauth_destination   reject_non_fqdn_sender
reject_non_fqdn_recipient   reject_unknown_sender_domain
reject_unknown_recipient_domain reject_unauth_pipelining
check_client_access hash:/etc/postfix/access_whitelist
check_policy_service unix:private/postgrey   permit
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_tls_cert_file = /etc/ssl/postfix/a.mx.whyscream.net-cert.pem
smtpd_tls_key_file = /etc/ssl/postfix/a.mx.whyscream.net-key.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom
unknown_local_recipient_reject_code = 550
virtual_alias_maps =
proxy:pgsql:/etc/postfix/pgsql/virtual_alias_maps.conf
proxy:pgsql:/etc/postfix/pgsql/virtual_alias_domain_maps.conf
proxy:pgsql:/etc/postfix/pgsql/virtual_alias_domain_catchall_maps.conf
virtual_gid_maps = static:12
virtual_mailbox_base = /var/spool/vmail
virtual_mailbox_domains =
proxy:pgsql:/etc/postfix/pgsql/virtual_mailbox_domains.conf
virtual_mailbox_maps =
proxy:pgsql:/etc/postfix/pgsql/virtual_mailbox_maps.conf
pgsql:/etc/postfix/pgsql/virtual_alias_domain_mailbox_maps.conf
virtual_minimum_uid = 100
virtual_transport = dovecot
virtual_uid_maps = static:251

I've also read this (famous/dreaded) bug:
http://sourceware.org/bugzilla/show_bug.cgi?id=4980 which seems related,
but since I'm well past glibc 2.7, I'd expect not to bitten by that one.
However I'm no expert on the subject and I have no idea how the fix as
mentioned in bug looks like.

Now my question is: is this the place where you'd say your glibc is
broken, talk to your os vendor or could there some other issue that I
overlooked?


-- 
Regards,
Tom



signature.asc
Description: OpenPGP digital signature

Re: connections from ipv4 localhost logged as unknown[127.0.0.1]

[Tom Hendrikx]

Wietse Venema wrote:
 Tom Hendrikx:
 Hi,

 After setting up postfix up on a ipv4/ipv6 dualstack machine I'm seeing
 the following issue: connections on 127.0.0.1 (where my content_filter
 re-injects mail) are logged as:

 010-01-13T22:51:07+01:00 meredith-vmail postfix/smtpd[4772]: warning:
 127.0.0.1: address not listed for hostname ip6-localhost
 
 Given the client IP address 127.0.0.1, Postfix gets the name
 ip6-localhost, but that name does have the address 127.0.0.1.
 
 After some time reading google and debugging this is what I found out:
 - /etc/hosts contains the following stuff regarding localhost (in the
 specified order):
 ::1 ip6-localhost ip6-loopback
 127.0.0.1 localhost
 
 And indeed. Name ip6-localhost does not list address 127.0.0.1.
 
 Somewhere, you have a mapping from 127.0.0.1 that returns ip6-localhost,
 and that mapping is screwing things up, because 127.0.0.1 is not
 listed as an address for ip6-localhost.
 

I got as far as this conclusion too, which got me checking for the
contents of /etc/hosts. Since I can influence the lookup results easily
by shuffling the contents of /etc/hosts, can I conclude that this is an
issue with my glibc?

Example: changing the contents of the hosts file to:
::1 ip6-foobar ip6-localhost ip6-loopback
127.0.0.1 localhost

yields the following result:
postfix/smtpd[5128]: warning: 127.0.0.1: address not listed for hostname
ip6-foobar

-- 
Regards,
Tom



signature.asc
Description: OpenPGP digital signature