on at the last moment (support
nightmare)
Any pointers?
Thanks
Ed W
On 16/03/2012 11:57, Wietse Venema wrote:
Ed W:
Therefore I'm suggesting that the out of the box config matches the
*RFC*. Then if the mail owner wants to lock it down to some non RFC
suggested spec they can read the instructions.
SHOULD does not forbid mandatory TLS; only a twisted mind
least a small number of clients to connect and
that the mail server owner should read the instructions to get their box
working in line with RFC?
If we are going to adjust the defaults can we please match the RFC?
Thanks
Ed W
Enabling TLS costs you $1-3 in additional connect time, plus lack of PPP
compression increases the cost by about a factor of 3. Although we are
clearly not talking about the average user now, I think it would focus
your mind if I asked if you would be happy to increase your monthly
internet bill by a few hundred dollars vs risking going plain text?)
Cheers
Ed W
port (RFC
aside). I think "may" is a more appropriate default?
Ed W
On 21/02/2012 19:26, Wietse Venema wrote:
Ed W:
As the OP suggested, a desirable solution would be for the MTA to only
check the various maps to decide a domain is local *after* having done a
DNS check to see if the MX record points "to this machine". ie the end
goal is if the MX rec
look like..?
I think you are saying that cidr map would make more sense here anyway?
Could/should the docs perhaps be updated to show that suggestion?
Thanks for postfix!
Ed W
ic A
record names, followed by a connection to the destination server to
check the mail banner if we aren't 100% sure?
Grateful for better ideas from those who have tried to tackle this?
Thanks
Ed W
looped several times and examine
all the received headers - this normally gives you a clue on the message
path and you can work back from there to understand the rules causing it
to loop
My best guess would be the exchange autoforwarder is doing something
unexpected
Good luck
Ed W
entropy using the EGD protocol (helpful for virtualised server pools)
(No relationship other than happy customer)
Ed W
cause. The output below, many thanks in advance.
I find the pfqueue utility very helpful for managing the queue...
Good luck
Ed W
1234) to do the internal
relaying so that I can skip some steps when I re-inject on the final
server (performance tweak only, eg don't spam scan again)
In this way any of the backend servers can also serve as a frontend
server, accept mail and route it to the final destination. Similar
tweaks can be done with Dovecot proxying to have the pop/imap servers
act as a mixed frontend/backend setup.
Good luck
Ed W
Wietse Venema wrote:
Ed W:
Wietse Venema wrote:
If you don't want to receive mail for domain-less addresses then
say so, instead of coming up with the wrong solution for the wrong
problem.
OK, "I want to accept most emails over smtp and then later bounce emails
w
Wietse Venema wrote:
Ed W:
Wietse Venema wrote:
If you don't want to receive mail for domain-less addresses then
say so, instead of coming up with the wrong solution for the wrong
problem.
OK, "I want to accept most emails over smtp and then later bounce emails
w
hout noticing - easily done
I think?)
In general it's useful for machines to "do the right thing" and at least
in my situation this means bouncing the email rather than delivering (I
concede that others may prefer something else)
Thanks
Ed W
internet connection with 2,400 baud speeds costing $1.50/min. We have a
fairly precise setup which maximises speed and minimises cost.
So, is there some way to please configure postfix to *bounce* domainless
addresses?
Thanks
Ed W
Wietse Venema wrote:
Ed W:
To clarify the question - the goal is if someone connects via the
network (not local sendmail command) and the transcript says "RCPT TO:
" that this is subsequently bounced as being an invalid
To summarize my other response, by definition
Ed W wrote:
Wietse Venema wrote:
Ed W:
Hi, I'm using postfix 2.5.7 and having some trouble with the server
domain being appended to incomplete sender addresses. I have set
# postconf|grep -e rewrite -e append -e myorigin -e mydomain -e local_header
append_at_myorigin
Wietse Venema wrote:
Ed W:
Hi, I'm using postfix 2.5.7 and having some trouble with the server
domain being appended to incomplete sender addresses. I have set
# postconf|grep -e rewrite -e append -e myorigin -e mydomain -e local_header
append_at_myorigin = yes
append_dot_mydomain
Hi, I'm using postfix 2.5.7 and having some trouble with the server
domain being appended to incomplete sender addresses. I have set
# postconf|grep -e rewrite -e append -e myorigin -e mydomain -e local_header
append_at_myorigin = yes
append_dot_mydomain = no
local_header_rewrite_clients =
mydo
Anyone got any good recipes for restricting mail in the case of mail
apparently sent FROM a local address, TO the same local address, apart
from obviously writing a policy server?
(It's to try and tighten up some checks on high probability spam)
Thanks
Ed W
> Let's assume that you specify:
>
> /etc/postfix/main.cf:
> default_transport = smtp
> relay_transport = smtp
> smtp_destination_rate_delay = 120s
>
> With this, Postfix inserts 120s between deliveries over the smtp
> transport. There will not be two messages back to back.
>
> In othe
Ralf Hildebrandt wrote:
> * Eddy Beliveau :
>
>> Hi!
>>
>> We are using Postfix 2.5.4 with success. Thanks ;-)
>>
>> My question is:
>>
>> We have many students who send emails to mispelled domains, as:
>> hotmmail.com, hotmial.com, hotmail.cm ...
>>
>> I know that I can try to find all individ
Ralf Hildebrandt wrote:
> * Jacky Chan :
>
>> Dear all,
>>
>> Can I create custom mail queue in /var/spool/postfix to hold the mails for
>> specific detinsation and schedule to deliver one by one for period of time,
>> let's say 2 mins.
>>
>
> That's not needed. Create a custom transport fo
24 matches
Mail list logo