Re: Solving reverse DNS problem with Postfix configuration?

[Kris Deugau]

lists wrote:

FWIW my VPS only allows one reverse pointer. I host multiple domains so only 
one reverse pointer will match. My mail does not get bounced for that.

And before someone posts you can have more than one reverse pointer per IP the 
VPS (Digital Ocean) says it can't be done.


Multiple PTR records for a single IP are entirely possible - *if* the 
DNS management tool allows.  If DO says they "can't", it's a limitation 
of their DNS management tool.


It's usually not worth the effort, and may cause more problems that it 
solves.  Just set the PTR to the system's fully-qualified hostname and 
all but the pickiest of third-party mail systems will be happy.


-kgd

Re: Transport based on domain?

[Kris Deugau]

Alex wrote:

Hi,
I have postfix-3.5.10 configured as a multi-instance along with
amavisd for spam filtering. Amavis is limited in its ability to create
different filtering policies for individual domains,


Unless a lot of functionality has been dropped since I last took a dive 
in the Amavis docs it should support policies down to per-user 
granularity.  Look for "filter banks" (IIRC).


I can't help much further since I don't use it myself, but I'm pretty 
sure you're going to a lot of trouble to work around a non-problem.


-kgd

Re: https://www.postfix.org/ in trouble

[Kris Deugau]

raf wrote:

Being flippant, it would protect against a
man-in-the-middle-attack where someone tricks you into
reading false online documentation. :-)


Why bother?  Most of us can misread the docs perfectly well all on our 
own...  


-kgd

OT: maildir usage profiles (Re: feature request: improve vague/incorrect error message)

[Kris Deugau]

Jim wrote:

On Tue, Nov 16, 2021 at 11:41 (-0500), Kris Deugau wrote:


Jim wrote:

On Mon, Nov 15, 2021 at 12:25 (-0500), Wietse Venema wrote:



Instead, use Maildir format with one message per file,



I thought about that once, but I decided I have too many e-mail
messages for that.  (I don't want to run out of inodes, nor do I want to
make file accesses too slow because of the number of files in the
directory.)



I converted "local"[*] storage from mbox to maildir a number of
years ago - IIRC I was starting to see performance issues with mbox
in part due to the way I manage my mail and in part simply due to
the number of messages I keep around.



This account has ~13G of mail on my PC, with over 100K messages each
in two folders, several in the tens of thousands, and most dedicated
mailing list folders holding somewhere between about 5K and 8K
messages each.


Thanks for the specifics.


The only performance issues I have are:



a) something sucks in the the IMAP protocol such that my mail client keeps
having to create a new connection and reauthenticate - it's not strictly a
timeout, because it's not on anything remotely resembling a predictable
timing


At first glance I wouldn't see that related to mbox vs. maildir, but
I've been surprised before.


Hard to tell, since I converted to maildir long before I had this much 
mail sitting around.  IIRC I was at ~20K messages in the biggest folders 
at the time.  I converted more for convenience in doing "grep -r |xargs 
rm"-ish things - can't really do that with mbox folders.


I also have the same needs-to-log-in-again-for-no-good-reason issue 
using Thunderbird against a role account on a central mail platform with 
"many" - but quite a bit fewer - messages, so my money is definitely on 
some weird corner case in the IMAP protocol.





Local storage is ext4 on a SATA SSD, although I wouldn't expect a noticeable
performance difference if it were on a conventional hard drive.


I am surprised that accessing files in a directory with 100K entries
is not slow, since (according to what I read) ext4 stores entries in
an "almost linear" list, and thus to find a director entry you might
have to chew through (on average) 50K entries.  Of course, file system
caching will speed things up immensely, assuming one has enough RAM
(given the other activity on the system) to keep the contents of those
maildirs (that is, the directory contents, not the contents of the
files) in RAM.


That could well be at the root of some of my issues, but the whole-file 
rewrites needed for mbox would be worse IMO.  Aside from whatever 
strange state Seamonkey gets itself into after running for several weeks 
I'm not seeing any other slowdowns.  Dovecot seems to be quite happy to 
manage all that baggage - TBH some of Dovecot's indexing may be helping 
out there by avoiding having to re-read the filesystem's entire 
directory index very often.


I do also have 32G of physical RAM, and top reports 17G of that is in 
use for cache...



[*] Due to some legacy mail flow that would be painful to convert, I
pull mail with fetchmail, deliver locally with procmail (sorry),
then expose it to my mail client with a local Dovecot instance.


Again, thanks for your specifics.  Maybe I should give maildir a try
some time and see what happens.  (Or maybe I should just delete a bunch
of email and forget that I ever got it.)


I haven't used actual client-local mail folders for much in a LONG time; 
 both Seamonkey and Thunderbird default to mbox-ish files IIRC, 
(although TB at least has an option to use a maildir-ish format).


-kgd

Re: feature request: improve vague/incorrect error message

[Kris Deugau]

Jim wrote:

On Mon, Nov 15, 2021 at 12:25 (-0500), Wietse Venema wrote:

Finally, if you want to keep lots of mail around, don't keep
everything in one huge mailbox file.


I actually have a bunch of huge mailbox files ;-)
(Yeah, way too much email.)


Instead, use Maildir format with one message per file,


I thought about that once, but I decided I have too many e-mail
messages for that.  (I don't want to run out of inodes, nor do I want to
make file accesses too slow because of the number of files in the
directory.)


I converted "local"[*] storage from mbox to maildir a number of years 
ago - IIRC I was starting to see performance issues with mbox in part 
due to the way I manage my mail and in part simply due to the number of 
messages I keep around.


This account has ~13G of mail on my PC, with over 100K messages each in 
two folders, several in the tens of thousands, and most dedicated 
mailing list folders holding somewhere between about 5K and 8K messages 
each.


The only performance issues I have are:

a) something sucks in the the IMAP protocol such that my mail client 
keeps having to create a new connection and reauthenticate - it's not 
strictly a timeout, because it's not on anything remotely resembling a 
predictable timing


b) Seamonkey has a subtle polling issue probably at least partly related 
to a) that (eventually) causes it to such up gobs of RAM, get slow, and 
crash on a certain action.  This usually takes a couple of weeks.


Local storage is ext4 on a SATA SSD, although I wouldn't expect a 
noticeable performance difference if it were on a conventional hard drive.


-kgd

[*]  Due to some legacy mail flow that would be painful to convert, I 
pull mail with fetchmail, deliver locally with procmail (sorry), then 
expose it to my mail client with a local Dovecot instance.

Re: Clarify reject_* for smtpd_helo_restrictions

[Kris Deugau]

post...@ptld.com wrote:

> Please RTFM Postfix documentation. If it does not mention IP addresses
> then it does not use the IP addres,

I did read the manual which says:
"Reject the request when the HELO or EHLO hostname has no DNS A or MX
record."


Good. Does it mention IP addresses? No it doesn't. Therefore
it doesn't use them.


Our brains obviously work different. You keep saying it doesn't mention 
IP addresses when it clearly says "DNS A record". A DNS A records *IS* 
an IP address so the manual DOES mention IP addresses. I would like to 
understand your way of thinking, how is that not mentioning IP addresses 
to you?


It (potentially) *retrieves* an IP address, but it does not *use* the IP 
address.


To put it another way, the *contents* of the DNS lookup(s) are 
irrelevant, only whether the lookup returned a value or NXDOMAIN.


Other restrictions may use that resulting IP at other points in the 
processing.


-kgd

Re: How do I integrate Postfix MTA/SMTP Server with Cybonet PineApp Secure Email Gateway?

[Kris Deugau]

Turritopsis Dohrnii Teo En Ming wrote:

I have asked this question in iRedMail support forums but nobody knows
the answer.

I have sent an email to Cybonet Technical Support but received no replies.

My Postfix (+Amavisd) Linux mail server was installed and configured
automatically using iRedMail version 1.4.0 on Ubuntu 18.04.5 LTS.


IIRC iRedMail is a packaged "mail appliance" system build on mostly open 
source mail components like Postfix.  It mainly provides a configuration 
layer on top of several tools for quickly standing up a working mail 
system.  If I had to quickly set up a full-featured small to low 
mid-scale mail system, to hand off to someone with limited experience 
diving deep into mail system administration, it's the sort of system I'd 
look at.


If the PineApp you're looking at is the same one I had a...  certain 
experience with... trying to extract customer mail data from a number of 
years ago, it is a highly vendor-lockin black box that you do not modify 
aside from the configuration knobs in the web UI.  It worked tolerably 
well while running, but you have exactly zero access to its operating 
internals - it's all buried in an encrypted loopback image which the end 
administrator is explicitly and specifically denied access to by PineApp.


It was so locked down I had to contact PineApp support to *update the 
SSL cert for mail and web services*.  Even Microsoft Exchange internals 
are easier to inspect, I think.  (I suspect given time it would be 
possible to deconstruct and access this loopback image, since it didn't 
appear to require any hardware keys or a startup password or some kind 
of remote license check when rebooted.  But it would be a gigantic 
headache, and just given that it's set up this way at all is a big "None 
of your business" sign.)



I want to integrate Postfix (+Amavisd) with Cybonet PineApp Secure
Email Gateway. Has anybody done this before?

I can't seem to find any good, well written and detailed documentation
on how to INTEGRATE Postfix with PineApp. The only documention I can
find are those on how to install PineApp on a bare metal physical
machine, Hyper-V or VMware, nothing about integration at all.


Assuming the one I crossed paths with is the same platform you're 
looking at, the short answer is "you don't", unless you mean setting a 
smarthost for the PineApp appliance, or set up a separate (virtual?) 
machine as a MX host that immediately relays to the PineApp appliance. 
You simply do not make any changes to its internals, period, and you 
don't make any configuration changes not exposed by its web UI.


Aside from my experience, reading their site it looks like this is 
basically intended as an inbound MX filter relay - a system that sits in 
front of your primary mail host, and does your mail filter processing 
before handing the "clean" mail to your mail host.  Most such platforms 
don't allow modifications aside from whatever configuration they've 
exposed in a web UI.


-kgd

Re: Certificate Postfix.org missing?

[Kris Deugau]

Sven Schwedas wrote:

On 23.04.21 08:36, Nicky Thomassen wrote:
But there is no need for that on a read-only site like Postfix'. In my 
opinion,

anyway.


It's only a read-only site as long as there's no man in the middle 
attack injecting malicious code into the connection. There's too few 
people who disable things like Javascript by default, and that battle is 
well and truly lost as far as the general public is concerned, so we 
need defence in depth measures to protect people from their own laziness.


This.

It's not just inserting malicious JS;  some of the big US providers have 
inserted ads (or overridden a site's existing ad slots, effectively 
stealing such revenue as may or may not have been made by the visited 
site), and did so at the pure HTML content level.  HTTPS at least 
protects the end user against their own ISP or any other unethical 
fingers with access to the connection path.


Dedicated tin-foil-hat-wearers can no doubt spin off far more sinister 
possibilities for this kind of in-flight alteration of web content.


-kgd

Re: why people connect clamav as milter in main.cf and smapassassin in master.cf?

[Kris Deugau]

Marek Kozlowski wrote:

:-)

I know that clamav and spamassassin are out of scope of this list. But 
my question is more postfix-related. Most systems and Linux distros have 
tutorials on postfix, spamassassin and clamav. In most of I've read the 
recommended way of connecting clamav is via smtpd_milters in main.cf. 
But spamassassin in those tutorial is not connected that way but a 
master.cf entry is defined and a "-o content_filter=that_entry" for smtp 
service is added. If so many people do that there must be some reason 
for it. I'm wondering: what is the reason? what's the difference?


I would say the main reason for the difference is that the core 
SpamAssassin project itself doesn't have a milter component, so there's 
no way to use that method to link it in, whereas ClamAV doesn't really 
have a content-filter-compatible mode that I recall where it can pass 
through complete messages with optional flagging - but it does natively 
include a milter component.


Personally I'd rather call both from a secondary glue layer for more 
flexibility (especially for certain ClamAV tests that are valuable but 
which I don't trust as absolute go/no-go results).  My own favoured tool 
is MIMEDefang since it can express complex filtering policies based on 
results from multiple tools like SpamAssassin or ClamAV plus anything 
you can code up in Perl.  For inbound mail I prefer to push SpamAssassin 
out to the final delivery for more flexible per-user handling as well as 
integrating it with mail sorting.


-kgd

Re: Using header_checks to file mail into junk folder

[Kris Deugau]

Christopher Walker wrote:


I'm really hoping to get messages
into a user's Junk folder without using IMAP sieve.


I'm curious why;  on-delivery message sorting like this is pretty much 
what sieve is *for*...


-kgd

OT: syslog output files (Re: 'Send only' postfix configuration works on Ubuntu but not on Rasberry Pi - missing TLS library?)

[Kris Deugau]

Chris Green wrote:

While I'm about it why am I getting identical mail.log and mail.info
files created in /var/log on the Pi?


It's not inherently Pi-specific.

The root cause is some wise-guy upstream package maintainer who has 
(mis?)configured (r)syslog to output multiple log files for different 
priority messages sent to the MAIL facilty by default.  Whether this is 
actually useful is entirely a matter of opinion.


One of the first things I do in a new Debian install is to revert this 
to the standard single file.  Personally I have yet to find a use case 
where this split would be useful, notwithstanding the packager's 
comments in the rsyslog configuration.


-kgd

Re: Mail server without MX record.

[Kris Deugau]

Jason Long wrote:

Thank you.
Can you tell me how can I setup my Postfix server with A record


You just add an A record with a suitable name for your server.  There's 
nothing Postfix-specific about this.



Or how can I change the DNS server two support two MX records?


I'm not aware of any DNS server software that limits the number of MX 
records.


I *have* met all too many DNS management tools that make bad assumptions 
about things like this.


You should talk to your IT support and/or hosting provider, because both 
of these are specific to however your DNS records are managed, and 
neither has anything to do with Postfix configuration.


-kgd

Re: Send only configuration best practices?

[Kris Deugau]

Bob Proulx wrote:


The problem is *other* sites.  I am starting to get a trickle of
complaints from people who are not receiving password reset emails.
And the problem seems to be other sites that are requiring that
senders have MX records, and the rest of the associated incoming mail
server set up for it.  Which I am well equipment to deal with but
would rather not since not is simpler.



webservice.example.org. IN  MX 0 .

?

Or just publish the server as a normal MX record, and just don't set up 
any actual handling for inbound mail (ie, configure Postfix to not 
listen on the public IP, and/or block port 25 inbound in the firewall).


Sites insisting on having an MX record for the sending FQDN (or worse, 
the rDNS name) are likely to reject this too, but if they're that 
insistent on having a return channel you're likely going to end up in 
their separate local blocklist sooner or later anyway.


If the server is a subdomain, point the MX record to the primary 
domain's MX, and configure it or not for the subdomain.


The problem with sites that take a strict line like this is that they 
WILL reject a certain amount of legitimate mail, and in the long run the 
only fix is to convince them that they need to relax their restrictions. 
 Over time this will happen naturally;  either they bend to pressure 
from their users to let in mail that their users want to receive, or 
they lose the users whose mail they refused to let through.


-kgd

Re: Forwarding best practices

[Kris Deugau]

Bob Proulx wrote:


No matter what you do on your end there is no way to guarentee that
the large mailbox providers will accept the forwarded messages.


FTFY. :(


Because at any point in time any of those users might click "Spam" on
the message.  And there is no way you can prevent this.  It's a human
problem of human training.


It's not even about forwarded mail, or spam.

I'm plugged in to Microsoft's "Junk Mail Reporting Program" for mail 
coming from both our outbound cluster and forwarded from our MX cluster.


End users on Hotmail/Outlook.com routinely mark *legitimate direct 
messages in ongoing conversations* as spam.  They report *legitimate 
government communications about something they've asked a government 
office about*.  They flag *mail from their lawyer*.


I can only guess that the "Mark as spam" button looks a lot like a 
"Delete" symbol of some kind, or I have to give up all hope of 
intelligence on the part of end users.



My experience is that if it is Microsoft that they will allow one free
black eye for you.  I contact them and say, hey, what's the data for
this so I can improve things?  What message do you have in the corpus
of evidence for me?  I want to figure out what is happening and stop
it.  They write me back and say, "Don't talk to me you spammer.  We
will show you nothing.  But we will delist you this one time."
Obviously this is a paraphrase from memory.

Now delisted things work okay again for a while.  Then for reasons I
have no idea there suddenly Microsoft rejects all mail again.  I try
the official contact channels.  Now they go, "Don't talk to me you
spammer, you are a repeat offender, we are not going to show you
anything, and we are not talking to you again."  Paraphrasing again.


Or they refer you to their rules for "bulk senders", which are variously 
inapplicable or utterly irrelevant for both forwarded mail and ISP-type 
outbound relay mail flow.



I have yet to see any evidence from Microsoft as to what messages they
think are worthy of being IP blocked regardless of my attempts to
communicate with them.


If you can get recognized as a suitable contact for your outbound IPs 
with Microsoft's SNDS and JMRP you can start seeing (some of?) the mail 
marked as spam.  It's helped us locate low-volume compromised accounts 
now and then.


If you get IP-blocked, you're sending/forwarding "too much spam" 
(whatever that means), and in the end it may just come down to telling 
your users they can't forward mail to Hotmail accounts any more as a 
matter of policy.


  Therefore I have no way to improve processes

on my system.  I am thinking one of my users is forwarding and then
reporting messages as spam.  But without data I can't be sure.
Without data I have nothing to grip upon.  I don't know anything firm
about who or what.  Eventually I am forced to route Microsoft
destinations through a different IP address to avoid the IP block.
They have the might and I do not.


Sometimes it seems like they're blocking because it's a day ending in y.

-kgd

Re: postfix 3.5.4 centos 8 hardcoded crypto settings?

[Kris Deugau]

Xavier Belanger wrote:

Hi,


Leonardo Rodrigues  wrote:


      You nailed it, Viktor and Xavier, it was the default system-wide
setup on the CentOS 8 OS from file

/usr/share/crypto-policies/DEFAULT/opensslcnf.txt

      setting MinProtocol to TLSv1 there did the trick.

      Thank you guys!


You're welcome.

One piece of advice: that file may be considered as a "system
file" and could be overwritten in the future by some CentOS
update. Make sure to document that change and to keep an eye
of that file; or to define your own policy (custom policies
are not overwritten).


It should be possible to set options like this in /etc somewhere, which 
shouldn't be overwritten on package upgrades.  I'm not sure where 
CentOS/RHEL/Fedora have put the relevant OpenSSL configuration recently, 
but on Debian and derivatives this can be set in /etc/ssl/openssl.cnf.


-kgd

Re: Preferred/maintained greylisting options?

[Kris Deugau]

micah anderson wrote:

Allen Coates  writes:

The web page https://www.abuseat.org/faq.html  (about half-way down the page)
has an honest - and fairly recent - appraisal of a number of DNSBLs.


Its a little outdated...

For example:

Invaluement DNSBL
 [Note: Commercial] ivmURI and ivmSIP are good solid and
 professionally operated lists. ivmURI is a URI (domain) DNSBL like
 SURBL or URIBL or DBL, with high effectiveness (comparable with
 DBL/URIBL/SURBL), extremely low false positives, and quick to
 list. ivmSIP is a IP-based DNSBL which is particularly good at
 catching "new" emitters. Its FP rate is quite low. Neither of which
 should be considered substitutes for Spamhaus Zen/Spamcop, but do
 complement them well.

They no longer exist.


Not sure where you're looking, but we have an active subscription for 
Invaluement and the datafeed files all have timestamps within the last 
~10 minutes or so.


https://www.invaluement.com/

They *are* strictly paid access;  they do not have a free tier.

-kgd

Re: Replace null sender addresses?

[Kris Deugau]

Bob Proulx wrote:

Jason Bailey wrote:

It is indeed being generated internally. The RCPT TO is there, but
because it lacks a MAIL FROM, we are seeing some email providers
drop the message, presumably because it looks like UCE/spam.


"some email providers"?  That makes it sound like you are generating
bounces to random places on the net.  That makes it sound like you
have an open relay problem.


We are trying to get the manufacturer of the system to acknowledge
the problem and address it, but they're currently insisting there's
no problem. In the mean time I've got important emails that aren't
getting delivered.


Your description is too vague to be useful.  Details, or it didn't
happen.


I was hoping to get Postfix to fill it in so that the resulting
email traversing the public Internet was standards compliant and
less likely to get filtered by someone else's UCE solution.


Bounce messages from the MAILER-DAEMON using <> *are* standards
compliant.  That isn't the problem.  It is definitely not the first
problem to be solved.  The first problem to be solved is to debug and
fix why you are generating those bounce messages.


To my reading of Jason's first message, the widget/appliance/app that's 
generating the original emails is, in and of itself, (mis)using the null 
sender on (some of) its own original messages, because Reasons.


Jason wants to take those messages, and overwrite a correct envelope 
sender address onto them.


-kgd

Re: IP addresses in helo

[Kris Deugau]

Matus UHLAR - fantomas wrote:

On 18.11.19 18:10, Gregory Heytings wrote:

Bill Cole wrote:
Rejecting mail is a far better choice than delivering to a 'spam box' 
since most users never bother looking there for anything. Rejections 
at least stand some chance of making enough noise on the sender side 
to get misconfigurations fixed.


IMO this is naive.  As Kris Deugau wrote in most cases nobody ever 
looks at that noise, your users will just not receive their email.


A common answer to this is that the sender was supposed to get
error message. Since the message might be rejected anywhere between sender
and recipient, it's usually a must.


Yes, they're *supposed to* get an error.  But some end users have 
blackholed postmaster notices, and many end users have trouble making 
sense of even the best postmaster notices (assuming they don't just 
treat the error as a reply, and continue their conversation like nothing 
went wrong - yes, I see this at least a couple times a month).  If a 
message is rejected with an error message that reads, more or less 
literally:


550 Rejected for spammy content

how is the sender supposed to make any kind of sense of what, exactly, 
they need to do to get their message through?


At least with most of the DNSBL rejections, there's usually a link to 
the list's website with some reference information the sender can take 
to their provider, and ask "Hey, why are you on this blacklist?  It's 
preventing me from sending mail!".  (Not that that helps all the time, 
due to shared hosting and the unavoidable mystery meat so many 
desktop/mobile clients stuff into their HTML formatting.)



If you want to receive any possible spam and send them to spam folder, it's
completely up to you.


*nod*  "Your system, your rules."


Just note that people with too many spams in spam folder
may start ignoring it and complain...


*sigh*   All too true, although not just with "many" spams.  I've lost 
count of the number of customers who have complained about maybe 5-10 
messages in the Spam folder over the course of a week:


"Why is this spam in the Spam folder?!?"
"Er... because... it's not in your Inbox?"

-kgd

Re: IP addresses in helo

[Kris Deugau]

Bill Cole wrote:

Rejecting mail is a far better choice than delivering to a 'spam box' 
since most users never bother looking there for anything. Rejections at 
least stand some chance of making enough noise on the sender side to get 
misconfigurations fixed.


IME exactly the opposite is true, because all too many automated notices 
are fire-and-forget - the senders don't even have the infrastructure to 
handle bounce messages, never mind bring them up to the attention of 
someone who can fix things.  Or the notices are sent entirely by hand, 
but some "helpful" IT support monkey has gone and blacklisted all 
postmaster notices (or worse, sent them to /dev/null automatically).


At least if the message gets misfiled in the recipient's spam folder 
they've got some chance of finding the actual message, and a better 
chance of then informing someone who can fix the misfiring filter.


We had a case recently where a customer's one-man-band IT "support 
provider" couldn't seem to understand the idea that if our server tries 
to pass on a message and gets:


550 Rejected for spammy content

back in a postmaster notice, any further investigation MUST be started 
by the recipient, because it's the recipient's mail system doing the 
rejecting.


They had a couple of examples of rejected messages sent through other 
outbound servers to the same recipients, too, so it really was something 
to do with the content of their mail, not some property of our mail 
cluster.  I have a feeling there will be Words Spoken when (almost 
certainly not "if") their move to Office 365 doesn't fix the problem.


-kgd

Re: Sender IP reverse lookup rejected

[Kris Deugau]

Kadlecsik József wrote:

Hello,

One of our users reported a rejected email with the error code and message

Remote-MTA: dns; artemis.gat.com
Diagnostic-Code: smtp; 550 Sender IP reverse lookup rejected

We handle several domains with different outgoing smtp settings at
multiple mail gateways:

# /etc/postfix/master.cf
wignersmtp   unix  -   -   y   -   -   smtp
 -o smtp_bind_address=148.6.0.56
 -o smtp_bind_address6=2001:738:5001::56


Slightly wild guess:  Something about the reverse DNS entries bothers 
the receiving site.  (Whether it's a reasonable complaint is something 
else entirely, and rejecting mail to postmaster@ is not very bright all 
on its own.)


kdeugau@pod:~$ host 148.6.0.56
56.0.6.148.in-addr.arpa domain name pointer smtp.wigner.mta.hu.
kdeugau@pod:~$ host smtp.wigner.mta.hu.
smtp.wigner.mta.hu has address 148.6.0.58
smtp.wigner.mta.hu has address 148.6.0.56
smtp.wigner.mta.hu has address 148.6.0.57
smtp.wigner.mta.hu has IPv6 address 2001:738:5001::56
smtp.wigner.mta.hu has IPv6 address 2001:738:5001::57
smtp.wigner.mta.hu has IPv6 address 2001:738:5001::58

I would recommend giving each of those IPs a unique PTR name, and 
setting up matching A or  records.


I'm guessing they're erroring on either the multiple IPs in the forward 
lookup, or the mismatch between PTR and at least one forward entry. 
They may still fail if you have eg:


56.0.6.148.in-addr.arpa domain name pointer smtp1.wigner.mta.hu.
smtp1.wigner.mta.hu has address 148.6.0.56
smtp1.wigner.mta.hu has IPv6 address 2001:738:5001::56

-kgd

Re: Format of ip address in /etc/postfix/access

[Kris Deugau]

Jan Ceuleers wrote:

On 10/08/2019 23:22, Wietse Venema wrote:

   NOTE 1: The access map lookup key must be in canonical form:  DO
   NOT SPECIFY UNNECESSARY NULL CHARACTERS, and do not enclose net-
   work address information with "[]" characters.

Emphasis added for clarity.



To me a NULL character is the ASCII character which has all of its bits
set to zero. Could I therefore suggest talking about 0 characters
instead in this man page?


Think "semantically null".  There are other things that could be 
included in a "convenient for [x]" format for an IP address which do not 
change its meaning.


-kgd

Re: Different SSL certificate per virtual domain

[Kris Deugau]

Viktor Dukhovni wrote:

Google and Microsoft deliver outbound mail for hundreds
of thousands of domains from a common pool of outbound
names.  Nobody seems to mind.


Some of us do mind, but there's really nothing we can do about it 
because any spam-control measures we might try would block far too much 
mail that our customers want to receive.


Realistically, many other mail systems also relay mail on behalf of many 
apparently unrelated domains;  it's rare to have a valid use case for 
really truly requiring mail for a given domain to be (apparently) 
running on its own dedicated system.


-kgd

Re: opendmarc.dat Permission denied issues

[Kris Deugau]

On Thu, May 30, 2019 12:52 am, Benny Pedersen wrote:

li...@sbt.net.au skrev den 2019-05-29 06:09:



change /var/run to /var/tmp

if you reboot with your config you will loose data

/var/tmp must not be cleaned after boots, /tmp will be cleaned on boot


/tmp and /var/tmp may be emptied at any time;  they are not intended for 
persistent data.  Sockets and temporary working files are fine;  I 
wouldn't put anything in either one that I expected to keep around for 
very long.


The exact default policy may also vary from *nix to *nix (either across 
Linux/*BSD/"real"-UNIX divisions, or between Linux distributions), and 
will almost certainly vary from system to system according to local 
administrator preference/policy.


The default /var/spool/opendmarc/opendmarc.dat sounds reasonable; 
/var/lib/opendmarc/opendmarc.dat is probably another good choice.  Files 
in these trees are expected to hang around.



li...@sbt.net.au wrote:

following Dominic advice I've set "UMask 0002" as , and, also reverted to
default path, restarted some 10 hours ago, so far, so good, no more fopen
errors

I'll change to /var/tmp next


I'd just leave it in the default location;  unless you have some strong 
reason to put it elsewhere.


-kgd

Re: Sporadic, repeated connections from aws

[Kris Deugau]

@lbutlr wrote:

I've had the following in my fqrdns.pcre checks for quite awhile:

/^ec2(-[12]?[0-9]{1,2}){4}\.compute-[0-9]\.amazonaws\.com$/ REJECT  Generic - 
Please relay via ISP (amazonaws.com)

And I have noticed that I frequently get a series of 50 or more connection 
attempts from some aws server out there in a burst (50+ connections in a few 
minutes).

Fine, everything is working as it should with my settings, the connection is 
dropped right away (although the REJECT is not logged).

Am I right in blocking these connections? Is there any reason for an aws server 
to be sending mail directly that I am overlooking?


IMO this *should* be absolutely completely 100% correct and safe.  (Also 
IMO, Amazon should actively block outbound direct-to-MX connections from 
these IP ranges in much the same way most ISPs block direct-to-MX mail 
from their dynamic connection IP ranges.)


Unfortunately many people with AWS services either don't agree, or more 
likely don't know what their mail ends up looking like from the spam 
control perspective, because I see a modest but regular flow of 
legitimate mail from Amazon compute nodes.  :(


A quick sampling of our FP archive and mail logs shows a seed company, a 
political something, a propane/fuel supply company, several smallish web 
forums, a smallish payment processing company, and several apps.


I'm pretty sure I've seen mail from nearby IP ranges that have had 
"proper" (ie, user-specific) reverse DNS applied, so clearly there's a 
mechanism for Amazon VPS customers to do it right.


Amazon doesn't make life easier by insisting in their abuse reporting 
form that IP assignments are highly volatile;  there's next to no way to 
tell, for sure, from the outside, whether a given Amazon IP is part of 
their static IP pool for long-running VPSes, or part of their "compute 
power for hire" cloud, which may change "ownership" several times in an 
hour.  Or even if they actually maintain separate IP pools for these 
functions - possibly they don't.


-kgd

Re: Assistance to protect from spam flood

[Kris Deugau]

Nick Howitt wrote:
OK. Let's assume I don't have an MX Backup. Then all 30k+ attempted spam 
deliveries would have come straight to me. They would all have failed, 
initially because of unknown recipient, then, when I added them to the 
access list, because of an denied sender. What is the most efficient way 
of blocking these messages? Can they be blocked earlier than 
smtpd_sender_restrictions?


Blocking at that point is still incredibly cheap compared to accepting 
the message then feeding it to eg SpamAssassin.


About the only notch better you could do would be to watch for some of 
the IPs, look up the netblock they're part of in WHOIS, then block them 
in the firewall.  That assumes you never ever EVER want to receive mail 
from anyone using those providers, with ANY domain in the sender address.


I had a P100 with maybe 32MB or RAM, running sendmail, relaying possibly 
10-15K messages daily to a legacy mail system running on a Novell 
Netware 4.something host (yes, really) around 2001, and rejecting a 
longish list of things based on connecting IP or sender email both 
within sendmail and occasionally via milter (MIMEDefang).  Load was 
effectively 0.  If these aren't showing up in your mailbox, don't worry 
about it.


-kgd

Re: G Suite mx checker complains "do not configure the mail service on the only domain name."

[Kris Deugau]

Poliman - Serwis wrote:
Hello. I have used G Suite MX checker available here 
https://toolbox.googleapps.com/apps/checkmx/


This seems to be a Google-specific tester for domains hosted with 
Google, so it's difficult to compare with random other domains.


and I have message: "The 
address of the mail server in the domain record A can cause poorly 
visible and difficult to diagnose errors manifested by "disappearing" 
e-mails in the event of problems with the DNS server. This problem can 
be diagnosed by entering a command*telnet your.do.main 25*[..]". How can 
I resolve this?



It would be helpful to know which domain you're testing so the rest of 
us can read the entire report.


It sort of sounds like you have either managed to enter one of the 
Google MX hosts' IP addresses as your domain root A record, or have an 
extra MX record somewhere, or just have the domain root A record pointed 
somewhere outside Google, but without more information it's really hard 
to tell what they're even checking for.


-kgd

Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?

[Kris Deugau]

Laura Smith wrote:

Honestly, you are most likely wasting your time on that point because all that you are 
likely to get back is a page of waffle saying "blah blah blah ... security 
reasons... blah blah blah"

I know this because a sysadmin ex-colleague was having problems creating accounts with a 
FinCo using delimiters (e.g. nam...@example.com).   FinCo's filters were rejecting this 
because it was "invalid".

Said individual wrote a carefully worded long letter to C-suite execs at FinCo, 
also taking the time to attach copies of RFCs referred to in the letter so they 
would not have to look them up.

A couple of weeks later, a reply arrived in the post ... "blah blah blah ... 
security reasons... blah blah blah... we know better... blah blah blah"

So the moral of this story is, unless you have friends working for FinCo, don't 
bother trying to engage them on how they could improve client service by fixing 
their IT infrastructure. They are unlikely to listen.


When I come across a site that won't accept a "foo+bar" username part 
for the email, I roll my eyes and use "foo_bar" instead.  Thanks Wietse, 
for adding support for multiple different characters in recipient_delimiter!


(I used to do this anyway when my personal server was running sendmail, 
but there I had to add yet another entry in virtusertable each time.)


Of course, sometimes you don't find out that "foo+bar" isn't supported 
until you notice curious lack of email from the site...  since their 
form doesn't validate as tightly as their mail system.  Or sometimes the 
login page is the picky one.


-kgd

Re: Request for feedback on SMTPD restrictions

[Kris Deugau]

Dominic Raferd wrote:
​Is there a method (regex?) for reliably identifying dynamic ip 
addresses?


Short answer:  No.

If you really insist on going down that rabbit hole, look up the 
RDNS_DYNAMIC rule from Apache SpamAssassin.  It's an aggregation of 25 
provider-specific probably-dynamic rDNS patterns.


​ Take for instance 199-127-103-235.static.avestadns.com 
- it looks dynamic to me but it says it is static.


That, right there, is why not.

There is no One True Standard, and even within the more common 
conventions there are quite a few variations.


This particular example would be from a provider that has declared a 
range of IPs to be static IP assignments, and which has deployed a set 
of default records in a particular form so that (presumably) all of 
those IPs have IP->name->IP mappings even if they don't have customer- 
or service-specific rDNS names on them.


-kgd

Re: Microsoft silently discarding emails after recepit

[Kris Deugau]

Dominic Raferd wrote:
Otherwise, the formatting of your DKIM record in DNS seems weird (try: 
dig +short 201605sfinacom._domainkey.sfina.com TXT); even if technically 
valid the intermediate quotes may be influencing 'SmartScreen'.


Strictly speaking that result does not in fact contain quotes at all; 
it's a byproduct of TXT record chunking.


I ran into a similar issue with a somewhat snarky DNS validation tool; 
tinydns automatically splits TXT records into 128-byte chunks by default 
(not 256, or "up to 256 on whitespace" as BIND does), which upset the 
validation tool.  I had to extend my DNS management tool to publish the 
TXT records in such a way that tinydns did not automatically split them 
at 128 bytes.


That said, it wouldn't surprise me if that's contributing to the problem...

-kgd

Re: Try dane and still got "Untrusted TLS connection..."

[Kris Deugau]

Viktor Dukhovni wrote:

There are two prerequisites for DANE verification to happen:

   1. Your DNS resolver in /etc/resolv.conf needs to be a *validating*
  DNS resolver and for any meaningful security must be either on
  the loopback interface or reachable via a securely keyed IPsec
  tunnel or similar.


I'm curious how necessary this really is in the case of "many" servers 
all talking to a local cache on the same switch.  Do I really have to 
set up IPsec tunnels for DANE-friendly DNS resolution on those machines?


Setting up a cache on each machine would be simpler, but then you lose 
the benefit of merging cached results from multiple requesting systems - 
you end up either forwarding to another local cache anyway, or 
multiplying your external DNS lookup traffic by the number of servers in 
the cluster.


-kgd

Re: Throttling bursts of connections at postscreen? More to do here?

[Kris Deugau]

@lbutlr wrote:

Is there anything more you could do? Not really. If you really want the log 
lines to go away you could put in a DENY in your hosts table, but if you do 
that you're going to be doing it A LOT.


*nod*  If there's only one persistent host, it may be worth blocking at 
some higher level (I'm partial to "iptables -j DENY") but if the 
connections aren't resulting in spam actually arriving at some mailbox 
on your system the only "problem" is the volume of log data.


-kgd

Re: What's a better error code than 554 to get a sending server to stop retrying?

[Kris Deugau]

robg...@nospammail.net wrote:

I have a milter set up to REJECT on some body content.

It works like it should and REJECTS with the message

Jul 25 14:41:13 mariner postfix/handoff/smtpd[56542]: proxy-reject: END-OF-MESSAGE: 554 
5.7.1 id=12969-07 - Rejected by next-hop MTA on relaying, from MTA(smtp:[127.0.0.1]:16002): 554 
5.7.1 BANNED CONTENT; from= to= 
proto=ESMTP helo=

I've tested it by sending 'bad' email to myself from gmail.  Seems to work as 
advertised.

The mailers on EXAMPLE2.com are for an otherwise fairly repsectable domain.  
Most of what comes from there to me is OK.

But they keep retrying to resend the email that's getting REJECTed.  Every 
15mins for the past 9+ hours since the 1st message was sent and got rejected.

Depending on where I read about it that "554 5.7.1" error code means "failed 
transaction".

I thought that a REJECT is supposed to do that -- just send an 'undeliverable' 
notice back to the sender containing the error code.

But it acts like it means "and retry later" too.

Is there some other Error code that says "failed.  permanently.  stop trying to 
resend the darn thing." ?


Any 5xx code is supposed to say that.  Whether the recipient of the 
remote site's resulting bounce message is paying attention is another 
matter.


You're now down to something like Kevin McGrail's suggestion downthread, 
or contacting the postmaster at the remote site to get them to check in 
to this from their end.


If that fails (ie, no action;  or worse, postmaster@ and/or abuse@ 
bounces), you may need to resort to a firewall entry, and live without 
the legitimate traffic for that site.  (I've done this once in a while - 
all it really did was clean up my logs a little, because when I removed 
the block months later the problem traffic came right back.)  That 
assumes there's not much of that;  if you get a lot of legitimate mail 
from that site, plus this trickle of mishandled rejections, you're out 
of local options.


This could also be a sender that just keeps trying to send the same 
thing over and over again, an automated process doing the same, or even 
virus-generated mail not being caught by whatever outbound filtering the 
remote site has.


-kgd

Re: Queue ID availability for milters on multi-message connections/sessions?

[Kris Deugau]

Wietse Venema wrote:

Below are the SMTP commands/responses, and the test-milter output
showing that the second "DATA" event is reported with the correct
queue ID.


OK, thanks!  I'll take it up further with the milter authors.

-kgd

Re: Queue ID availability for milters on multi-message connections/sessions?

[Kris Deugau]

Wietse Venema wrote:

Kris Deugau:

I came across a bit of an information-passing glitch on a system that
uses a milter (MIMEDefang) to glue together complex filter policies.

MIMEDefang is configured to log sender, first recipient, Message-ID (if
any), and the queue ID, along with some filter result data, for each
message.

This works just fine for messages sent on their own connection.

However, if a remote system sends more than one message during a
connection/session, the queue IDs of the second and further messages are
not passed to/retrieved by the milter;  instead they're logged as
"NOQUEUE".  I've confirmed this works as expected with sendmail, but not
with any version of Postfix up through the current 3.3 snapshot.


Logged as NOQUEUE by Postfix? Milter? Something else? At what
protocol stage?  Envelope? End-of-body? Something else? Actual
logging would clarify a lot. I don't haver the time to drop what
I'm doing and spend hours to reverse engineer your conditions.


Sorry, guess I've been prodding this on and off for too long and forgot 
some of that wasn't as obvious as to me.


The literal 'NOQUEUE' is a placeholder MIMEDefang initializes its local 
reference copy of the i macro to.  smfi_getsymval(ctx, "i") is called in 
five places including end-of-message in the C that talks directly to 
libmilter.  The log action I've added that creates the mimedefang.pl log 
entries below is in a section run at end-of-message.


Here's the full mail log from a test system:

Mar 29 16:35:14 jessie64 postfix/smtpd[17537]: connect from 
localhost[127.0.0.1]
Mar 29 16:35:27 jessie64 postfix/smtpd[17537]: 26F5E428A4: 
client=localhost[127.0.0.1]
Mar 29 16:36:02 jessie64 postfix/cleanup[17556]: 26F5E428A4: 
message-id=<f...@bar.com>
Mar 29 16:36:03 jessie64 mimedefang.pl[17552]: 26F5E428A4: 
clientip=127.0.0.1 smtpauth= from=kdeu...@deepnet.cx to=f...@example.com 
messageid="<f...@bar.com>" queueid=26F5E428A4"
Mar 29 16:36:03 jessie64 postfix/qmgr[17527]: 26F5E428A4: 
from=<kdeu...@deepnet.cx>, size=324, nrcpt=1 (queue active)
Mar 29 16:36:03 jessie64 postfix/local[17557]: 26F5E428A4: 
to=<f...@jessie64.pem-lan>, orig_to=<f...@example.com>, relay=local, 
delay=42, delays=42/0.01/0/0.01, dsn=2.0.0, status=sent (delivered to 
command: procmail -a "$EXTENSION")

Mar 29 16:36:03 jessie64 postfix/qmgr[17527]: 26F5E428A4: removed
Mar 29 16:36:17 jessie64 postfix/smtpd[17537]: 55ADB428A4: 
client=localhost[127.0.0.1]
Mar 29 16:36:36 jessie64 postfix/cleanup[17556]: 55ADB428A4: 
message-id=<f...@bar.com>
Mar 29 16:36:36 jessie64 mimedefang.pl[17552]: clientip=127.0.0.1 
smtpauth= from=kdeu...@deepnet.cx to=b...@example.com 
messageid="<f...@bar.com>" queueid=NOQUEUE"
Mar 29 16:36:36 jessie64 postfix/qmgr[17527]: 55ADB428A4: 
from=<kdeu...@deepnet.cx>, size=324, nrcpt=1 (queue active)
Mar 29 16:36:36 jessie64 postfix/local[17557]: 55ADB428A4: 
to=<f...@jessie64.pem-lan>, orig_to=<b...@example.com>, relay=local, 
delay=27, delays=27/0/0/0.03, dsn=2.0.0, status=sent (delivered to 
command: procmail -a "$EXTENSION")

Mar 29 16:36:36 jessie64 postfix/qmgr[17527]: 55ADB428A4: removed
Mar 29 16:36:38 jessie64 postfix/smtpd[17537]: disconnect from 
localhost[127.0.0.1] helo=1 mail=2 rcpt=2 data=2 quit=1 commands=8


and the SMTP transcript:

# telnet localhost 25
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 jessie64.pem-lan ESMTP Postfix
helo local
250 jessie64.pem-lan
mail from:kdeu...@deepnet.cx
250 2.1.0 Ok
rcpt to:f...@example.com
250 2.1.5 Ok
data
354 End data with .
Subject: test
Message-ID: <f...@bar.com>

test
.
250 2.0.0 Ok: queued as 26F5E428A4
mail from:kdeu...@deepnet.cx
250 2.1.0 Ok
rcpt to:b...@example.com
250 2.1.5 Ok
data
354 End data with .
Subject: test
Message-ID: <f...@bar.com>

test
.
250 2.0.0 Ok: queued as 55ADB428A4
quit
221 2.0.0 Bye
Connection closed by foreign host.
#


For completeness:
# sbin/postconf -n
alias_database = hash:/opt/pfcustom/etc/aliases
alias_maps = hash:/opt/pfcustom/etc/aliases
append_dot_mydomain = no
biff = no
compatibility_level = 2
default_transport = error
inet_protocols = ipv4
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
mydestination = jessie64.pem-lan, localhost.pem-lan, localhost, 
jessie64.deepnet.cx, jessie64, example.com

myhostname = jessie64.pem-lan
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 192.168.2.0/24
myorigin = jessie64.pem-lan
readme_directory = no
recipient_delimiter = +
relay_transport = error
relayhost =
smtpd_milters = unix:/var/spool/MIMEDefang/mimedefang.sock
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated 
defer_unauth_destination

virtual_alias_maps = texthash:/opt/pfcustom/etc/virtual_alias
#

-kgd

Queue ID availability for milters on multi-message connections/sessions?

[Kris Deugau]

I came across a bit of an information-passing glitch on a system that 
uses a milter (MIMEDefang) to glue together complex filter policies.


MIMEDefang is configured to log sender, first recipient, Message-ID (if 
any), and the queue ID, along with some filter result data, for each 
message.


This works just fine for messages sent on their own connection.

However, if a remote system sends more than one message during a 
connection/session, the queue IDs of the second and further messages are 
not passed to/retrieved by the milter;  instead they're logged as 
"NOQUEUE".  I've confirmed this works as expected with sendmail, but not 
with any version of Postfix up through the current 3.3 snapshot.


Does the milter need the fix near the bottom of 
http://www.postfix.org/MILTER_README.html copied somewhere else?  Or is 
Postfix not (re?)setting this macro after the first message is done with?


-kgd

Re: sending GMX, WEB failed - Dynamic IP Addresses

[Kris Deugau]

Maurizio Caloro wrote:

If sending any Mail to GMX or WEB.de, i have here this error, Please view 
Mail.log
last two lines. i undestond that GMX will check the Resolver-Name, "dynamic IP 
Ranges"
Yes true i'am running now with dynamic IP Address "DSL Connection" but also 
running
a service like No-Ip that will forrward the MXrecord, mail.caloro.ch.

But exist here any way to solv this issue, or are here the only way to buy 
Static-IP
Address so GMX can Resolv the Name from Sender correct? or i have understond 
any thing
wrong here?



Feb  1 13:29:39 caloro postfix/smtp[3510]: B17D64020B: to=, 
relay=mx01.emig.gmx.net[212.227.17.5]:25, delay=579, delays=578/0.05/0.17/0, dsn=4.0.0, 
status=deferred (host mx01.emig.gmx.net[212.227.17.5] refused to talk to me: 554-gmx.net 
(mxgmx109) Nemesis ESMTP Service not available 554-No SMTP service 554-IP address is 
black listed. 554 For explanation visit 
http://postmaster.gmx.com/en/error-messages?ip=151.248.162.33=bl)l)


They don't say which blacklist actually triggered, but I checked that IP 
and it's listed on the Spamhaus PBL.  This Spamhaus sublist is made up 
of IP ranges that have been manually submitted by the ISP that operates 
them as IP ranges that should never emit direct-to-MX email.


Checking further with Spamhaus:

"
Outbound Email Policy of WWZ Telekom AG for this IP range:

It is the policy of WWZ Telekom AG that unauthenticated email sent from 
this IP address should be sent out only via the designated outbound mail 
server allocated to WWZ Telekom AG customers. To find the hostname of 
the correct mail server to use, customers should consult the original 
signup documentation or contact WWZ Telekom AG Technical Support.

"

So, by your provider's explicit policy, you are not allowed to do what 
you are trying to do.  Use your provider's outbound mail server, ask 
your provider about a static IP, or arrange for a private VPS to handle 
your outbound mail via authenticated port 587.


Note that this has nothing to do with anything you've set up for your 
own incoming email.


-kgd

Re: Postfix for sendmail users - rejecting users with custom SMTP codes and text

[Kris Deugau]

Noel Jones wrote:
> On 11/9/2016 8:58 AM, Kris Deugau wrote:
>> I'm in the process of migrating my personal domain to a new server, and
>> in the process I'm switching from sendmail to Postfix.
>>
>> One feature I haven't been able to quite figure out is part of
>> sendmail's "virtusertable" - *most* of this is equivalent to
>> virtual_alias_maps, but it also allows you to do a variety of other
>> things such as reject arbitrary recipients with a custom SMTP response
>> code and message.
>>
>> For instance:
>>
>> kdeugau...@deepnet.cx   error:5.1.1:550 This address is no longer valid
>> as it was sold to spammers
>>
>> I've come close to an exact match by adding a check_recipient_access map
>> to smtpd_recipient_restrictions, but the resulting SMTP status codes
>> aren't quite correct - 554 vs 550.
> 
> Yes, check_recipient_access is the right tool for this.  You can
> manually specify the result code, see:
> http://www.postfix.org/access.5.html
> 
> oldu...@example.com  550 5.1.1 address not valid

Ahh, I found my mistake;  I misread that reference page.

You use EITHER the numeric codes OR the text codes, not both.

-kgd

Postfix for sendmail users - rejecting users with custom SMTP codes and text

[Kris Deugau]

I'm in the process of migrating my personal domain to a new server, and
in the process I'm switching from sendmail to Postfix.

One feature I haven't been able to quite figure out is part of
sendmail's "virtusertable" - *most* of this is equivalent to
virtual_alias_maps, but it also allows you to do a variety of other
things such as reject arbitrary recipients with a custom SMTP response
code and message.

For instance:

kdeugau...@deepnet.cx   error:5.1.1:550 This address is no longer valid
as it was sold to spammers

I've come close to an exact match by adding a check_recipient_access map
to smtpd_recipient_restrictions, but the resulting SMTP status codes
aren't quite correct - 554 vs 550.

It doesn't matter that much, but I'd like to be precise with these
responses.

Postfix 2.11 on Debian 8/Jessie.  Suggestions for other minor fixups
welcome as well, although I'm pretty sure I've got everything else
working the way I want.

-kgd



# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
delay_warning_time = 1h
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
mydestination = tiny.deepnet.cx, localhost.deepnet.cx, deepnet.cx,
deepnet.ca, localhost
myhostname = tiny.deepnet.cx
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
readme_directory = no
recipient_delimiter = +_
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_milters = unix:/var/spool/MIMEDefang/mimedefang.sock
smtpd_recipient_restrictions = check_recipient_access
hash:/etc/postfix/nosuchuser, permit_sasl_authenticated
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
defer_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/certs/smtp_deepnet_cx.crt
smtpd_tls_key_file = /etc/ssl/private/hex.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
virtual_alias_maps = hash:/etc/postfix/virtual_alias,
regexp:/etc/postfix/regexp_virtual_alias

# cat /etc/postfix/nosuchuser
kdeugau...@deepnet.cx   REJECT 5.1.1 550 This address is no longer valid
as it was sold to spammers
someuserwhol...@deepnet.cx  REJECT Sorry, not accepting mail for
this account
supp...@deepnet.cx  REJECT


sendmail, old server:

$ telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
220 hex.deepnet.cx ESMTP Sendmail 8.13.8/8.13.8; Tue, 8 Nov 2016
14:40:32 -0500
helo local
250 hex.deepnet.cx Hello hex.deepnet.cx [127.0.0.1], pleased to meet you
mail from:kdeu...@deepnet.cx
250 2.1.0 kdeu...@deepnet.cx... Sender ok
rcpt to:kdeugau...@deepnet.cx
550 5.1.1 kdeugau...@deepnet.cx... This address is no longer valid as it
was sold to spammers
quit
221 2.0.0 hex.deepnet.cx closing connection
Connection closed by foreign host.
$

postfix, new server:

$ telnet localhost 25
Trying ::1...
Connected to localhost.
Escape character is '^]'.
220 tiny.deepnet.cx ESMTP Postfix
helo local
250 tiny.deepnet.cx
mail from:kdeu...@deepnet.cx
250 2.1.0 Ok
rcpt to:kdeugau...@deepnet.cx
554 5.1.1 : Recipient address rejected: 550 This
address is no longer valid as it was sold to spammers
quit
221 2.0.0 Bye
Connection closed by foreign host.
$

Re: Is not honoring bounces-to violation of RFC?

[Kris Deugau]

Chip wrote:
> My mistake NOT "bounces-to" rather "return-path"

Return-path is a header added by the receiving MTA (usually on final
delivery) that contains the envelope sender (MAIL FROM) used by the
sending system.

> as in the following
> snippet of campaign emails from Home Depot, Martha Stewart and Sears:

> Return-path:

Notice this one contains an extended ID number?  Their mail-sending
infrastructure almost certainly generates this pseudoaddress on a
per-mailing+recipient basis, so automated systems can quickly tell whose
email is bouncing, and which email campaign it bounced on.

> Return-path:

This doesn't use a unique envelope sender for each recipient, so they'll
have to do more complex parsing of any bounce messages to identify stale
recipients.

> So is "Return-path" supposed to be respected?  Because the company I was
> speaking of insists it's appropriate to send bounces to something other
> than "Return-path" usually the "From" or "Reply-to".

No;  as stated upthread bounces must be sent to the envelope sender
address.  Any system sending bounces to any other address is misbehaving
and may end up blacklisted (locally or in public datasources like
DNSBLs)  because of it.

All that said, if *you* are a perfectly innocent bulk-mailer who is
*receiving* bounces to the wrong place, you'll probably have to suck up
and deal with it to keep your service clean.

-kgd

Re: DKIM/SPF failure to folder, not return to sender and other tricks

[Kris Deugau]

li...@lazygranch.com wrote:
> 
> Peter wrote:
> > As a relatively simple example, I use amavisd-new and Spamassassin to
> > flag mail with a spam header. Then Dovecot LMTP with sieve looks for
> > this header and if it is present it delivers to the user's "Spam" folder.
> 
> Well this is interesting. I have a similar setup for postfix. With my desktop 
> email client (Claws), the program "builds the tree" based on what I assume 
> resides on the email server. So what on the server creates this spam folder? 

The delivery agent.  Dovecot's delivery agent and procmail (can't recall
any other general-purpose MDAs - although there are several that are
tied to their own non-mbox/maildir mail folder system) both understand
how to create the appropriate files and directories as needed, so "all"
that's needed for this is to create the configuration for the delivery
agent to tell it where to file which messages.

If you're using a multi-folder-aware delivery agent that doesn't know
how to create new mail folders  you probably need to find a new
delivery agent.

> I still rather just let the client filter the message based on the header 
> rewrite. Less work. 

Only if you only ever access your mail from one device.  If I'm reading
mail on my laptop, I don't want to have to either:

a) rely on my main desktop being on to do the message sorting and
filtering, or

b) duplicate, and try to keep up to date, all the message sorting rules
across multiple systems - to say nothing of the headache I might be in
for if I decided to start reading mail on my phone, which can't run the
mail client I use on my laptop and desktop in the first place.

-kgd

Re: postfix virtual domain walking

[Kris Deugau]

James B. Byrne wrote:
> 3.  If there is nothing that involves Postfix then something like what
> you propose must be the case.  Or someone has gone to some lengths to
> scan for these addresses using our domain name as a search term.

Every now and then I have seen indications in the mail logs of various
systems that some spammer is once again taking all of the username parts
they've ever seen and mix-and-matching them with domain names.

I have also seen, even less often, the next best thing to literally
trying all possible ASCII usernames, in order - or at least trying all
dictionary words from a modest dictionary mixed with that username list,
in ASCII order.

-kgd

Mail clients and forwarding (was Re: SV: Special method required for Gmail dkim/spf verification)

[Kris Deugau]

Sebastian Nielsen wrote:

> Another way, that is the preferred RFC way to do it, is to encapsulate the
> mail in a new message/rfc822 container, and adding Fwd: to the original
> subject of the outside container.
> (This is how most mail clients "forward" a message)

I can't speak to most of the rest of your message, but I'm pretty sure
you're wrong about "most mail clients" on this.

If mail clients forwarded messages as attached message/rfc822 blobs by
default, I wouldn't have so much trouble getting users/customers to
report suspect/junk/unwanted email this way.

Most desktop mail clients are set up to forward mail "inline" (ie,
basically formatted as a reply, but with some additional header bits in
the quoted section) by default.

Outlook in particular seems to have been carefully designed to make this
difficult to impossible.  Even when you do manage to come close, you
discover that the message you get out the other end is not the
bit-for-bit original message you intended to forward.

> To reply to a message, you would have to reply to the "inner" message.

I'm curious which mail client you're using that lets you do this without
a great deal of trouble.  None of the common desktop clients I've met or
used can do this - none can even save the attached message as a native
message in an in-client local mail folder.

-kgd

Re: AntiSpam & AntiVirus Integration with Postfix: lots of tools, but which one's AREN'T 'dead'?

[Kris Deugau]

joh...@fastmail.com wrote:
> I'm now at the phase of looking into Anti-Virus and Anti-Spam.  Looks like 
> ClamAV and Spamassassin are the main options here.

You'll probably want to look into third-party signatures for ClamAV;
its detection rate is a bit low otherwise IME.

> Both of those projects seem to be pretty alive and kicking too.
> 
> So I'm left with how to integrate them into and with Postfix.

The "best" way depends on your goals and requirements for filtering -
for instance, I want to use the heuristic tests in ClamAV but I don't
want them to be treated as absolute black/white results.  So I set up my
glue to flag those "viruses" - and ONLY those ones - for a bit of extra
score in SpamAssassin instead of immediate quarantine.

I also want to run SpamAssassin as a per-user filter, with (potentially)
different thresholds and scores for this or that, or different
whitelist/blacklist entries, so I call it on final mail delivery instead
of from an intermediate stage deeper in the MTA.

> I've poked around in all the options listed on the Postfix wiki & the common 
> option seems to be Amavisd.

I'm partial to MIMEDefang as my Swiss-army-chainsaw of choice for
in-band mail filtering, but Amavisd is probably a better choice if you
don't want to dig into Perl coding to configure your filter.

Both are well-tested and solid, IMO.

Amavisd comes with more prebuilt filter features and faster
out-of-the-box configuration for common mail flow patterns, and it works
with nearly any MTA;  MIMEDefang allows wide-open access to anything the
milter interface lets you do to an email in transit but is restricted to
MTAs that offer the milter interface.

> But both of those seem to be pretty inactive.  Amavisd's not had any releases 
> or updates afaict since last October, and I was told that the author isn't 
> really participating in it anymore (I gotta check myself on that).

"Project activity" isn't all that useful a metric;  chances are nobody
has seen the need for a Hot New Killer Feature in a while, and there
haven't been any nasty security or functionality bugs.

-kgd

Re: smtps via 465 is not working

[Kris Deugau]

Jithesh AP wrote:

 This does not work - telnet ml.w8timez.com 465
 This works - openssl s_client -connect ml.w8timez.com:465

Unless you've redefined the behaviour, this is exactly correct;  port
465 expects an SSL handshake before any other traffic.  Plain telnet
won't do you much good unless you can do the SSL handshake by hand, and
then hand-encrypt/decrypt the outbound and inbound traffic.  openssl
s_client -connect handles that SSL handshake and encrypt/decrypt
process, otherwise acting much like telnet.

Port 587 allows plaintext communication before enabling SSL with the
STARTTLS command.

-kgd

Re: rfc5322 compliance of Date: field

[Kris Deugau]

Richard Damon wrote:
 Minor nit, SPAM filters really don't determine compliance to the
 standards, they determine the likelihood of a message being
 undesirable. If being 100% compliant to the RFCs made a message immune
 to being detected as spam, then there would suddenly be a LOT of 100%
 compliant messages being sent out as spam.
 
 If someone has evidence (or even just have convinced themselves) that
 the inclusion of a Time Zone comment in the date field is a good
 predictor of a message being spam, then they will make such
 determinations, and reject such message.
 
 Spam blocking breaks some of the principles of the RFC in reliable
 message delivery because people don't WANT those messages reliably
 delivered, and for some strange reason the spammers aren't doing things
 to clearly mark there messages as spam.

*nod*  And then you add in the eye-crossing volume of variously
legitimate mail that is variously NOT standards-compliant...

-kgd

Re: RBLs getting a lot of spam

[Kris Deugau]

motty cruz wrote:
 Hello, recently I am getting loads of spam, more than usual. I have the
 following RBLs. 
 
  reject_rbl_client b.barracudacentral.org
 http://b.barracudacentral.org,
  reject_rbl_client zen.spamhaus.org http://zen.spamhaus.org,
  reject_rbl_client bl.spamcop.net http://bl.spamcop.net,
  reject_rbl_client all.spamrats.com http://all.spamrats.com

A little overaggressive for my taste.  Your system, your rules.

 any recommendation? 
 
 Bayes Headers: 

I think you mean SpamAssassin/Amavis headers.  You should probably take
further followup to the SA users list.

 X-Spam-Flag: NO
 X-Spam-Score: 3.147
 X-Spam-Level: ***
 X-Spam-Status: No, score=3.147 tagged_above=-999 required=5.3
 tests=[BAYES_99=4.5, BAYES_999=0.2, HTML_MESSAGE=0.001,
 MIME_HTML_ONLY=0.723, RDNS_NONE=2.013, T_REMOTE_IMAGE=0.01,
 URIBL_BLACK=1.7, USER_IN_WHITELIST_TO=-6] autolearn=no

Well, USER_IN_WHITELIST_TO=-6 isn't helping this particular message get
tagged as spam  Without that hit, the message would have scored ~9,
well over your threshold of 5.3.

-kgd

Re: Regarding DNS lookup

[Kris Deugau]

Mauricio Tavares wrote:
 On Wed, Apr 16, 2014 at 8:40 AM, Joy pj.netfil...@gmail.com wrote:
 Dear Expert,
  I have configured my postfix to lookup against LDAP
 server which hosts multiple domain all working fine but in case any domain
 moves from my mail server to another server like yahoo or gmail by changing
 only MX record my server still tries to deliver mail to this domain
 disabling domain works perfectly but i want in case MX not points to my
 server mail should be delivered to current set MX record of domain.

 Is it possible in Postfix or any hack can do the same.

   That is a rather long sentence; you might consider breaking it
 down so it is easier to see your points and questions.
 
 So, does your postfix install use ldap to know which domains it is
 responsible for? If so, disabling there should make it ignore them.
 Also, I would expect if you change the MX record for a give domain,
 the mail to that domain will go to the new server.

I think the question is more along the lines of:

In case some customer changes the MX records away from me, how can I
automatically stop accepting mail for that domain?

About the best you can do is probably a cron job that checks on MX
records for domains you supposedly host, that can lead to automatically
disabling domains that suddenly point somewhere other than your mail system.

-kgd

Re: Edit bounced message by postfix and dovecot

[Kris Deugau]

pgala wrote:
 Hi,
 
 I want edit default bounced message witch is bounced by Mail Delivered
 System. I edit and configure bounce.cf but to my text automatically is
 adding smtp transcritpion. Below example:
 
 My text.
 
 us...@test.com: host 127.0.0.1[127.0.0.1] said: 553 5.7.1
  us...@test.com: Sender address rejected: not owned by user
  x...@test2.com (in reply to RCPT TO command)
 quot;
 
 i want remove from this message information about error. I want only
 quot;My textquot;.

Please don't.  Troubleshooting mail problems is already hard enough
without someone going around removing what little information can be
seen from outside.

-kgd

Re: can someone explain this SPF fail to me

[Kris Deugau]

jeffrey j donovan wrote:
 Greetings,
 
 Can someone explain this error to me, I have never seen this one before. I 
 tested my spf records and they seem fine. 
 
 someu...@ncem-pa.org: host mail.ncem-pa.org[204.186.202.37] said: 554
5.7.1 someu...@ncem-pa.org: Recipient address rejected: Failed SPF
check; beth.k12.pa.us, Redundant applicable 'v=spf1' sender policies 
 found
(in reply to RCPT TO command)
 Reporting-MTA: dns; smtp5.beth.k12.pa.us
 
 in this , it looks like the user recipient address is incorrect or something 
 along those lines.
 I do have two spf records, one for my relays and one for google.

I'm not completely clear on what you mean by one for my relays and one
for google, but you have two SPF records published publicly.  Don't Do
That.  (I don't think it's strictly a violation of the spec, but clearly
the recipient is being picky.)

There's no reason not to combine them like so:

beth.k12.pa.us IN TXT v=spf1 ip4:209.96.107.0/24 ip4:209.96.96.0/24
mx:beth.k12.pa.us mx:bethsd.org include:_spf.google.com ~all

unless you really need different SPF records to be visible to different
systems, which means you'll need to investigate DNS views so that any
given client only sees one SPF record.

-kgd

Re: Client host name resolution

[Kris Deugau]

E.B. wrote:
 Hello,
 
 My understanding was clients for whom you see this in the logs:
 
 connect from unknown[1.2.3.4]
 
 Do not have a PTR/rDNS set up for themselves.

For Postfix to include the rDNS in the log and Received: header, the PTR
name must then resolve back to that same IP as well.

Sometimes there will be a PTR record, but no matching A record.

Also keep in mind that if there is a temporary glitch in DNS resolution,
either the PTR or A lookup might fail when the message first passes
through, but looks fine later on when you check by hand.

-kgd

Re: SPAM through postfix+postscreen

[Kris Deugau]

HL wrote:
 On 13/11/2013 12:52 μμ, Paul C wrote:
 From what I see from the spam scoring, you have a -100 from the domain
 being whitelisted,

 But there seem to be a zillion mail servers out there that do not comply
 with the RFC,
 
 most of the times DNS and Reverse DNS and IP ADDRESSES and HELO
 hostnames are totally wrong from other-wise legit mail servers.

(Going a little OT;  if you're still not sure about what I'm talking
about ask for more info on the SpamAssassin users list.)

I'm not sure how your points about rDNS and HELO arguments have anything
to do with Google's servers (they have sane rDNS and HELO), but Paul's
point was that you likely have a line in your SpamAssassin configuration
somewhere like:

whitelist_from *@google.com

Do not use whitelist_from.  If you really feel you have to whitelist
anything claiming any association with Google, use whitelist_from_dkim;
 all mail legitimately using a @gmail.com or @google.com email should be
DKIM-signed, and should originate from a Google server.  Mail not
originating from a Google server should not have a Google envelope
sender.  (We'll ignore mail forwarding cases for now.)

FWIW, that particular relay IP in your example (41.13.5.22) doesn't look
to be a mail server at all based on the HELO and rDNS, and as of a few
moments ago was also listed on Spamhaus.

 Clients don't want to understand this
 specially if the these mails are about SALES 
 SALES = Money
 But I have to reply to complaints again and again and again ...
 
 Why did this spam passed through ???  

You can either block all of the spam, and put up with the false
positives, or you can block most of the spam, and only tag a legitimate
message once in a while, or you can let almost all of the spam through.

When someone complains, check your logs and let them know how many spams
they *didn't* get in their Inbox.

-kgd

Re: Do not forward spam

[Kris Deugau]

azurIt wrote:

 I don't believe in rejecting e-mails based on spam checks - there are and 
 always be false positives. I will rather accept 100 spams than reject single 
 legitimate e-mail message.

Spam volume these days is such that accepting, processing, and storing
**all** mail is becoming more and more unworkable, especially with a
situation like you're asking about where that stream of garbage is
forwarded out of your system to a system that *does* reject some volume
of spam (or blocks your system outright if you send them too much spam).

Depending on how you count, we reject anywhere from 50% to 90% of our
total mail volume based on a Spamhaus lookup.  Aside from an incident
where a Postini netblock got listed for a little while, I don't think I
recall *any* false positives over several years.

To more directly answer your original question, it would help if you
posted an overview of your mail flow.  It sounds like your forwarding is
done via alias rather than .forward or some similar processing on final
local delivery;  choosing a different place for your forwarding may help
cut the volume of forwarded spam.

-kgd

Re: Rejecting mail to unknown users

[Kris Deugau]

Mark Goodge wrote:
 It might help if you explained why you want to do this. What particular
 problem is being caused by your internal users getting an error message
 instead of a bounce?

Some idiot mail clients (*cough*ManyversionsofOutlook*cough*) don't
actually display the SMTP error response to the user, they just pop up a
generic Wahh!  Can't do that! error message.

Some users are also quite resistant to actually *reading* the text of
the error (although these users will also have trouble with reading the
bounce message).

-kgd

Re: Mail server, what else?

[Kris Deugau]

Craig R. Skinner wrote:

No Apache, PHP or webmail. HTTP was designed to transfer hyperlinked
text files, not do dynmaic stuff with root access to the whole box.
Beware!

IMAP (Thunderbird, Elm, KMail) is the way to go.
https://en.wikipedia.org/wiki/Comparison_of_email_clients#Operating_system_support


Then what do you suggest for casual users who do not care to either 
bring along a single device everywhere they want to access their email, 
or (know how to) install a fullblown mail program on every device they 
may access their mail from?  (Including things like Internet cafe PCs...)


Webmail means at least they only have one mail client and one UI to 
learn to read their mail.


-kgd

Re: Multiple recipient_delimiter address extensions?

[Kris Deugau]

grarpamp wrote:
 I've done - (qmail) to + (postfix) hurriedly in the past to avoid a
 meta issue. Other users migration or dual uses aside, with that
 one I wanted to but did not have benefit to research whether
 + or - had better merits. Such as which is in more common use now,
 which is trending to be more prevalent in the long term. And why?
 Honestly, best I could come up with was the large - legacy from
 decade old qmail-like installations, and not requiring the shift key
 seemed to win, heh :) I'm sure there are more sound thoughts
 on the matter in a paper somewhere.

- has the fairly significant advantage of being allowed on more sites
that try to validate well-formed email addresses - often in
Javascript.  Many such validators reject + in an email address.  :(

-kgd

Re: LDA understanding

[Kris Deugau]

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

Re: LDA understanding

[Kris Deugau]

Reindl Harald wrote:
 Am 14.03.2013 17:07, schrieb Kris Deugau:
 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

By harder I mean that you end up going to a great deal of trouble to
properly deal with a message that user A really, really wants in their
Inbox, and which user B never ever EVER wants to see at all.

 usually sieve comes AFTER SpamAssassin because it is a broken
 setup using a pre queue filter because it results in become
 a backscatter and you are usually not permitted by law
 accept a message with 250 OK and drop it silent

Laws vary by region.  So far as my personal mail handling goes, I also
want to divert eg mailing lists like this one to a mail folder *before*
calling an expensive content filter on a message that isn't spam.

Wearing my ISP mail admin hat, we don't use procmail, but the mail flow
would be entirely compatible;  there are several stages of filtering and
each one can short-circuit the process and deliver the message (either
to the Inbox or the Spam folder), instead of having to run *everything*
through an expensive SpamAssassin scan.

-kgd

Re: OT: prevent archiving SPAM mails

[Kris Deugau]

Reindl Harald wrote:
 sieve is your friend for this crap :-)

That class of filtering gets **really** tiresome to maintain though.  :/

Personally, I've found that running SpamAssassin with a threshold of 8
instead of 5 works quite well;  legitimate abuse reports (even with
complete attached spams) rarely go over 8 points.

-kgd

Re: Perl milters?

[Kris Deugau]

Ben Rosengart wrote:

What is the best Perl interface for milters?  I found several:

   Sendmail::Milter is way old, and demands -Dusethreads -- my perl is
   built with -Duseithreads.

   Sendmail::Pmilter is recent, but lacks a maintainer.  No traffic on
   its mailing list since 2009.

   Then there's http://code.google.com/p/milter-perl/, but there's very
   little information available about it.


It's not strictly a milter written in Perl, but a C shim to speak milter 
on one side with Perl stubs exposed at pretty much every available stage 
of processing:


http://www.mimedefang.org

I've used it for a variety of filtering configurations in the past with 
sendmail, and recently converted a custom content filter to MIMEDefang.


-kgd

Re: LoadShared Failover

[Kris Deugau]

Stan Hoeppner wrote:

On 3/12/2012 2:28 AM, Michael Maymann wrote:

Hi,

Stan: My question is not how I setup the solution, but how I *BEST* (best
practice) setup the loadshared/failover postfix solution I described
earlier.


I dunno if there is a BCP covering smtp submission/relay server load
balancing/fail over.  I'd make an educated guess that just about
everyone with more than one submission/relay server is using round robin
DNS.


*raises hand*

We're using Linux Virtual Servers for load-balancing all public-facing 
bits (and a handful of internal bits) of our entire mail cluster.


Once you beat the ARP configuration into shape to prevent a random real 
server from taking over the load-balanced IP it seems to work well.


We found that DNS-based round-robin strategies didn't actually balance 
the load very well.


-kgd

Re: spf configuration woes

[Kris Deugau]

David Southwell wrote:

But still got the following errors when the lines in main.cf were unchecked:


[snip]

Nov  4 07:37:50 dns1 postfix/smtpd[26676]: warning: connect to
private/policyd-spf: Connection refused


You need to find out why your policy server isn't responding to Postfix.

Since it's set up for a Unix socket, you likely either have a 
permissions issue (eg, running as the wrong user) or the policy server 
isn't running.


-kgd

Re: Using Spamassassin as content filter

[Kris Deugau]

Daniele Nicolodi wrote:

Hello Kris, thank you for your comments.

On 18/10/11 17:03, Kris Deugau wrote:

Since you're happy to deliver the spam somewhere, rather than trying to
reject it during the SMTP conversation, you're probably best off calling
spamc early in your local-delivery rules rather than trying to integrate
it into Postfix somewhere.  This way mail for a given real recipient
will always get processed by that recipient's filtering rules.


Well, I would very happy to discard spam as early as possible, however,
as I understand it, I can run Spamassassin rules only once the full
message in received, and therefore there is little value in having it
rejected sooner or later. What would be the solution to have it rejected
sooner than what is happening with my current configuration?


I don't know exactly how you'd do it, but IIRC the minimum change would 
be to configure Postfix to send a 550 error if the SA score is beyond a 
certain point.  You still incur the bandwidth cost to receive the data, 
but you don't have to store the messages you reject.


I think this is possible without any other software, but for flexibility 
and better control you'd probably want to switch to a content filter or 
milter that can call SA.


Personally, for inbound mail I prefer to run SA on delivery more or less 
as described in the SA procmail example, and deliver it all (mostly to 
one or another spam folders).



Look up the standard procmailrc example from the SpamAssassin docs, and
adapt as necessary for sieve.


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.


-kgd

Re: Using Spamassassin as content filter

[Kris Deugau]

Daniele Nicolodi wrote:

Hello,

on the web there are several recipes to integrate Spamassassin with
Postfix, but no one seems to me to be the definitive recipe. I think
that this configuration is quite common (for low volume smtp servers)
and would deserve a small space in Postfix official documentation, but
maybe it is already there and I missed it.


How you integrate any given kind of content filtering best depends on 
what you want to do with the filtering results.



(spam messages will be then discarded or archived with
dedicated Sieve rules implemented by dovecot-lda)



There is a way to have the filtering done after postfix has resolved the
aliases? There are other problems with this configuration that I'm not
aware of? There are better ways of doing what I want to do?


Since you're happy to deliver the spam somewhere, rather than trying to 
reject it during the SMTP conversation, you're probably best off calling 
spamc early in your local-delivery rules rather than trying to integrate 
it into Postfix somewhere.  This way mail for a given real recipient 
will always get processed by that recipient's filtering rules.


The cost is a slightly higher overall processing load from SpamAssassin, 
since messages sent to many recipients by way of an alias will pass 
through SA for each real recipient, instead of once.


Look up the standard procmailrc example from the SpamAssassin docs, and 
adapt as necessary for sieve.


-kgd

Re: Authenticated sender and milter

[Kris Deugau]

Jeetu wrote:

im trying to use mimedefang milter to append footer based on
Authenticated sender address


MIMEDefang provides all sorts of useful info from the MTA in various 
global variables.


The one you're looking for is $SendmailMacros{auth_authen}, and should 
be available without any special configuration.


man mimedefang-filter has the complete list of globals, and fairly clear 
notes on which sendmail macros are available at which stages of 
filtering.  AFAICT Postfix automatically provides most of them;  it's 
only if you're using sendmail that you have to specifically tell it to 
provide some of these macros to the milter.


-kgd

Re: What does Postfix stamp...

[Kris Deugau]

Murray S. Kucherawy wrote:

X-Originating-IP: isn't standard, so I'm not surprised postfix isn't adding it 
by default.  And I wouldn't trust it anyway; how do you know it contains a true 
value?


Not to mention, at least in my experience it's the IP that introduced 
the message to the Internet (ie, the sending client's IP, or webmail 
user's IP), not the IP that connected to your server.


-kgd

Re: selective greylisting with a long delay

[Kris Deugau]

Stan Hoeppner wrote:

Jerry put forth on 4/11/2011 4:39 PM:

Stan Hoeppners...@hardwarefreak.com  articulated:

Why bother with this complex greylisting setup?  Simply hammer the big
blocks with a CIDR entry and whitelist individual IPs in the range
from which you need legit mail.  If such IPs are used to send both
snowshoe spam and ham, that's a human shield tactic, and deserves
permanent blocking, FOREVER.  If anyone complains, lay the full
skinny on them as to why.  I.e. lay the blame at the proper feet, and
direct complaints at the guilty.

Life is too short to waste _your_ valuable time playing whack-a-mole
with spammers, isn't it?  We don't live in a totally collateral
damage free world.  People must get used to this.


Unless of course you get hit with a law suit.



Have you heard of a case of an SMTP sender suing an SMTP receiver for
message rejection, and winning the case?  Something like this would echo
through the tech press, and I've heard nothing.


Consider instead the case of a paying ISP customer suing said ISP for 
blocking dear Mother's email because Mother is getting her Internet 
connection from a company with lax enforcement against spammers.


Some of us simply do not have the luxury of deliberately causing false 
positives in our spam blocking efforts.


-kgd

Re: OT: How to resolve big ISP mail drop

[Kris Deugau]

Gary Smith wrote:

Anyway, the question is, how does the community as a whole deal with
  big ISP's losing email? It seems that some companies (like ATT) seem
  to have less and less access to tools necessary for communicating with
  them on things like this. Is there any know lists of contact/support
  channels out there that people use for the larger ISP's?


As already stated, there's not a huge amount that you can do on your
own. However, if you're prepared to part with a bit of cash, then you
could look into using a whitelisting agent such as SuretyMail or
ReturnPath.


Andy,

Problem isn't white/grey/black listings, its that they accepted the email with 
a valid return code but it never made it to the destination box. It only seems 
to be happened on a few recipients. Basically, in short, the destination ISP 
(in this case ATT) is making some type of decision as to what email you are 
receiving. Buying additional technology won't exactly solve this problem.


Actually it might work;  chances are there's a spam filter on the 
recipient side eating the message without telling anyone, and shelling 
out for a whitelist certification may help get through that filter.


It's by no means *guaranteed*, though.

-kgd

Re: Text Substitution with pcre:

[Kris Deugau]

Jerrale G wrote:

sorry for not including. Centos automatically puts 127.0.0.1 as
$hostname in /etc/hosts.


  could you not fix /etc/hosts?  (So far as I'm concerned, the only 
hostname legitimately associated with 127.0.0.1 is localhost.  Anything 
else is broken by definition.  Others may not share my opinion.)


-kgd

Re: postscreen access list

[Kris Deugau]

Benny Pedersen wrote:

someone else wrote:

Yes, it's spamhaus but due to the amount of trafic we have our own

server

(data feed).


make it a forward zone in bind so zone name is still same, that way no
magic configs does not use local rbldnsd


Spamhaus actually recommends a non-public local zone for their datafeed; 
 that way you don't leak the data to other users on your DNS cache, and 
you're certain that you are actually using your local copy instead of 
the public servers.


-kgd

Re: postfix and thousands unix user

[Kris Deugau]

Stan Hoeppner wrote:

ahmad riza h nst put forth on 11/8/2010 3:05 AM:

our hardware is hp dl180 g6 (a xeon quad core + raid 1 + 4G ram)


Ok, that answers one of my previous questions.  This system isn't nearly
strong enough for thousands of users.


IBTD.

I had PII/450 with ~768M of RAM, and a single 40G IDE hard drive 
handling about 250+ accounts (POP+IMAP+webmail, SSL and non) plus 
passthrough outbound mail filtering for the other ~1300 accounts on the 
main Novell mail system at peak.


Running sendmail.

(Admittedly, by that point, it *was* pretty much at its limit...  and 
that *was* with SpamAssassin 2.6 - it took me a while to shuffle around 
the available hardware enough to be able to upgrade to 3.0 due to the 
memory demands.)


Performance was by no means spectacular at peak, but after tuning and 
fiddling for a while as new accounts got added and performance problems 
showed up, it worked well enough that there was rarely much delay on 
inbound mail processing.


That said...  Yeah, upgrade the hardware now - I'd even say go for more 
than 8G of RAM if you can stuff it in, because if you're running a 
memory hog like SpamAssassin on the same machine as your core mail 
daemons and webmail, you'll need it sooner or later - and going into 
swap when running something like SA is a good way to cause *everything* 
to slow to a halt.


-kgd

Re: Postscreen update

[Kris Deugau]

Stan Hoeppner wrote:

For example:  http://www.spamhaus.org/datafeed/

The Spamhaus DNSBL Datafeed is a service for users with professional
DNSBL query requirements, such as corporate networks and ISPs. It offers
both a Query service and an Rsync service (you can choose).

The paid Query service mentioned above requires the Postfix feature
you are asking about.  It's an authentication mechanism.

The Rsync service allows downloading the entire Spamhaus databases
multiple times a day and hosting them on a local dns server or via an
rbldnsd daemon on each MX.  The latter is suitable for those such as big
ISPs with massive mail flows, who cannot afford the latency of over the
wire network based dnsbl queries.


It's also a reasonable option due to cost;  the paid query service is 
more expensive (at least at the level we were looking at here) compared 
to the rsync service.



A remote dnsbl query can take anywhere from 20-200 milliseconds (or
more) depending on number of hops and network conditions.  A query to a
local network dns server can take less than 1ms.  A query to an rbldnsd
daemon residing on the MX MTA host itself can occur in a few
microseconds, as it is an interprocess communication occurring at the
speed of system memory.  This is the preferred method for some of the
worlds busiest MTAs.  All this performance comes at a cost:  the rbldnsd
method requires multiple gigabytes of system memory for the Spamhaus
zone files alone.


Hmm, no, less than 100M:

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
28776 rbldns20   0 81740  65m  700 S0  3.3 118:49.42 rbldnsd

And this with a modest local blacklist loaded in as well.  The on-disk 
files for all of the lists total just over 100M.  We just run the 
Spamhaus data on a non-public zone on our general resolvers (running 
dnscache) and we have yet to see any latency problems.


The biggest sysadmin/network costs for the rsync service are in 
configuration (may need extra scripting to distribute the data to 
multiple rbldnsd instances, depending on how you want to arrange your 
DNS services - otherwise, it's set up once, let it run) and update 
bandwidth - currently they provide a script intended to be called once a 
minute to update the zone data source files.


-kgd

Re: relayhost doesn't change originating IP?

[Kris Deugau]

James wrote:

I have my own domain (on a dynamic IP) and run my own mail server but I
use relay host to send mail through my ISP.

I recently got this bounce:

(reason: 554 Service unavailable; Client host
[my_isp's_mail_server_host_name] blocked using Barracuda Reputation;
http://bbl.barracudacentral.com/q.cgi?ip=my_mail_server's_ip)


Some (many?) Barracuda filter appliances are (mis?)configured to 
outright reject mail based on a deep scan of Received: headers.  You can 
try contacting abuse@ or postmaster@ on the recipient's domain... but 
chances are one or both will be rejected.  :(


You may have to contact the recipient by phone to let them know their 
spam filter is rejecting legitimate mail.


-kgd

Re: Postfix helo.regexp file for stopping same to/from address

[Kris Deugau]

mouss wrote:

Victor Duchovni a écrit :

On Thu, Jun 24, 2010 at 12:20:23AM +0200, mouss wrote:


This mail is coming from postini. if you use postini, there's nothing
you can do with the envelope (and even if you do content filtering, you
shouldn't reject mail. it's too late).

Postini implement an SMTP proxy, not a store-and-forward relay,


is that always true? don't they queue mail if the destination site
responds with a 4xx?


Only if you're paying them to be a mail spool as well as filtering proxy.

-kgd

Re: which port to use for SSL/TLS?

[Kris Deugau]

Victor Duchovni wrote:

On Tue, May 25, 2010 at 09:09:09AM -0400, Phil Howard wrote:


On Mon, May 24, 2010 at 18:14, mouss mo...@ml.netoyen.net wrote:

As far as I know, it was never standardised.

Good enough reason for me to not use it.


This is the de-facto standard port for the service. Shoot yourself in
the foot if you wish, but for the record anyone implementing SMTP over
SSL (rather STARTTLS over SMTP) should use port 465 for that service.


Not to mention the fact that, IIRC, old versions of Outlook (and 
possibly Outlook Express) that support SMTP over SSL *hardcode* port 465 
- or at least bury any option to change it somewhere most people will 
never find it.  If you must support those clients, you must use that port.


-kgd

Re: mailbox_command

[Kris Deugau]

Danny wrote:

HI ,

I am well aware that postfix plays no part in the process I describe below,


... but then you say:


I
merely wanted to know if the mailbox_command would play a part in it.


?

mailbox_command is a Postfix *configuration directive*, not a binary, 
script, or other Postfix-related file.  So if you're not passing your 
mail through Postfix from fetchmail, Postfix configuration has no effect 
on what fetchmail does with your mail.



Don't you think that it must be a bug is a bit superflous? No it is not, it is
the easiest way to send a first time poster on his way. It is obviuos that you
have better things to discuss on this mailing than answer simple questions. Why 
don't
you make this list an exclusive club for the initiated and seasoned postfix user
only?


You noted in your original post:

   It looks like it is bypassing the  mda flag.

And /dev/rob0 replied to that paragraph with you might have a *Debian 
packaging bug* (emphasis mine).


A bug, as in, unexpected behaviour due to an error in the program.

That misbehaviour might be due to some screwup on the part of the Debian 
package maintainer, or the upstream fetchmail author - filing a Debian 
bug is the usual way to find out.  (After you've crosschecked the 
documentation for the current version in case some knucklehead thought 
it would be fun to change certain default behaviours, or how some 
long-standing options are processed, without trying to put up a great 
big neon sign warning you about those changes.)


-kgd