On Aug 23, 2013, at 07:54, Grant wrote:
> Does this mean the email address doesn't exist?
>
> : host mailin-04.mx.aol.com[64.12.138.161] said: 550 5.1.1
> : Recipient address rejected: aol.com (in reply to
> RCPT TO command)
Yes, it should mean exactly that;
http://tools.ietf.org/html/rfc3463#
Does this mean the email address doesn't exist?
: host mailin-04.mx.aol.com[64.12.138.161] said: 550 5.1.1
: Recipient address rejected: aol.com (in reply to
RCPT TO command)
- Grant
On 8/22/2013 9:57 AM, Stan Hoeppner wrote:
> On 8/22/2013 6:51 AM, Charles Marcus wrote:
>
>> The simple fact is, we do not have any users based *anywhere* but the
>> US, so, is what is the simplest way to block any/all non-US based client
>> connections on my submission port?
>
>
> Use the us.z
Wietse,
Thank you very much for your response. I'd mentioned that I'd tried this
approach in my first message. You are, however, correct.
I was misreading the maillog when I thought it was sending the message and
well as hitting my script. I need to look at the daemon/queue/service that
is loggi
Thanks a lot. Exactly what I was looking for.
On Thu, Aug 22, 2013 at 1:43 PM, Drizzt wrote:
>> When an outgoing email's target address is prefixed by '+', I would
>> like postfix to delete it replying back to the client ok status.
>>
>> I had previously setup below. But this sends back to the
Brian Armstrong:
> I am trying to set up postfix to send bounced messages to an external script
> to log the bounce to an external logging service so that we can monitor
> bounce rates to different recipient domains. I want to keep the default
> bounce behavior intact, so bounce notices are still s
I am trying to set up postfix to send bounced messages to an external script
to log the bounce to an external logging service so that we can monitor
bounce rates to different recipient domains. I want to keep the default
bounce behavior intact, so bounce notices are still send to the original
sende
Rob Tanner:
> I am upgrading from 2.2.10 to the current 2.10.1 primarily because the former
> does not understand milters and we are trying to implement DKIM. The problem
> is that LDAP appears to be broken and we make extensive use of LDAP. When I
> first copied the production main.cf over to
I am upgrading from 2.2.10 to the current 2.10.1 primarily because the former
does not understand milters and we are trying to implement DKIM. The problem
is that LDAP appears to be broken and we make extensive use of LDAP. When I
first copied the production main.cf over to my development box a
> When an outgoing email's target address is prefixed by '+', I would
> like postfix to delete it replying back to the client ok status.
>
> I had previously setup below. But this sends back to the client 554.
> I would like the client to think that in this situation everything is
> fine.
>
> ma
On 8/22/2013 6:51 AM, Charles Marcus wrote:
> The simple fact is, we do not have any users based *anywhere* but the
> US, so, is what is the simplest way to block any/all non-US based client
> connections on my submission port?
Use the us.zone ipdeny file to build a CIDR table to accept any US
c
When an outgoing email's target address is prefixed by '+', I would
like postfix to delete it replying back to the client ok status.
I had previously setup below. But this sends back to the client 554.
I would like the client to think that in this situation everything is
fine.
main.cf
smtpd_rec
Am 22.08.2013 14:23, schrieb Charles Marcus:
> Now to figure out how to log these firewall rejections to a separate log
> file, so I can see them if/when someone
> complains about not being able to connect
nothing easier than that
* the first rule logs with rate-control to avoid self-DOS
* the
On 2013-08-22 8:03 AM, Simon B wrote:
Surely the simplest solution is fail2ban with the false attempts in x
minutes resulting in a 20 minute ban?
No for two reasons...
1. Again, we have ZERO users who are outside the US, so why allow
connections at all?
and
2. I am not currently seein
On 22 Aug 2013 13:52, "Charles Marcus" wrote:
>
> Hi all,
>
> This isn't about spam, this is about blocking obvious attempts to
hack/connect to my submission port.
>
> I know and understand the argument against just blanket blocking hosts
based on the country of origin, but I've recently been seei
Hi all,
This isn't about spam, this is about blocking obvious attempts to
hack/connect to my submission port.
I know and understand the argument against just blanket blocking hosts
based on the country of origin, but I've recently been seeing random
connections on my submission port from hos
16 matches
Mail list logo
