Postings by Patrick Ben Koetter
I can put a mail on HOLD and release it later with the postsuper command.
That's great for debugging purposes, but only if I need to send the message
just once.
Would it be possible to expand the postsuper command with an optional command
line parameter that releases the message, but does not delete it from the hold
queue, so someone who needs to debug can resend it as many times as required
until I decide to ditch it?
The queue id could change. That's okay, because it is Postfix internal.
When a message reenters from an instance that uses XFORWARD, for example
amavis, will Postfix count the IP used twice and, for example,
add that to smtpd_client_recipient_rate_limit?
p@rick
* dd1313 < ... at gmail dot com>:
As a quick help run this and follow the command to add a new user- and
mailaccount:
# adduser <username>
To add an alias name for an existing user read man aliases and edit
/etc/aliases. The run "newaliases" once you're done.
For long time success you probably need to learn more about Linux and Ubuntu.
p@rick
Mailman 3.x will introduce a LMTP server and it will generate a Postfix style
transport map.
A postmaster will only have to add that maps path to $transport_maps and
create a dedicated lmtp service in master.cf.
I would like to simplify that step and provide a dedicated lmtp service in
master.cf that remains commented out until a postmaster decides to use that.
Would that be feasible? What would I have to do? I guess I should provide the
entry and some documentation that describes what to do - a MAILMAN readme or
something alike.
p@rick
I am doing research for an article related to the current state of DKIM and
ADSP usage. Please reply to me offline if you want to share your opinion or
experience:
- Do you know DKIM?
- Do you know ADSP?
- Do you know ARF?
- Do you use it?
- If not, why?
- If yes, why?
- What are your experiences?
- Do you run statistics?
- What do they say?
Thanks!
p@rick
Wietse,
out of curiosity and completely ignoring the fact that you probably have other
things on your mind:
Have you ever had a look at LEMONADE
<http://www.lemonadeformobiles.com/index.html> and the protocol extensions it
defines for SMTP (e.g. BURL, CHUNKING, BINARYMIME) and have you considered to
add those functionalities to Postfix?
p@rick
Everybody seems to use recipient delimiters. I wonder if there's a standard
that specifies a recipient delimiter functionality or did it just appear one
day and people adopted it without a spec or anything.
Anybody knows?
p@rick
Did anybody ever measure how many clients a Postfix server using Milter can
serve?
Somewhere hidden in my brain I recall someone on the list reporting problems
with Milter under high load. I am wondering how high the load was and if there
was a solution to the problem?
Reason I am asking is: I need to plan a rather large system (~600 messages/sec
at 150kb average size) and I ask myself if I need to do some tests now or if I
can rely on some others numbers for the moment and do the tests at a later
stage.
Thanks,
p@rick
I scanned the Postfix documentation for stress_expire_time and could only find
it in master_avail.c, where it is set to 1000s.
So the stress recheck interval is 1000s, correct?
Did I miss that in the official documentation? I believe it should be part of
the official documentation. I can write a sentence or two if you want me to.
p@rick
Wietse,
a customer asked me to help them customize Postfix replies, so clients
(better: users) can get a hint why their message is being rejected.
The idea is to refer to an URL in the reply where (generic) verbose
explanations on the reject reason can be found.
Maps in $relay_recipient_maps are evaluated as lists - only the LHS is
examined to determine if a recipient is listed and therefore a valid
recipient.
Does the same apply for local_recipient_maps, virtual_alias_maps and
virtual_mailbox_maps when Postfix tries to determine if a given recipient is
a valid recipient?
I'm asking because I am trying to figure out what I need to do to accept
messages for local/virtual mumble domains and have them sent off to a LMTP
server afterwards.
Sending them off to a LMTP server is a transport map job:
<a href="mailto: ... at example dot com"> ... at example dot com</a> lmtp:localhost
But what do
I was looking for a (current) RFC section that says SMTP servers MUST accept
messages sent by the null sender "<>", but almost all I found were references
that say notifications MUST be sent as null sender.
That in turn might mean a server must accept such senders, but I'd rather see
that written down.
I did find one reference though on
<http://www.rfc-ignorant.org/policy-dsn.php>: "An empty reverse path MUST be
supported." (5.2.9 of RFC1123).
It that still valid? Does anybody have a newer reference?
Thanks,
p@rick