Hi,
>> I thought mail would arrive on smtpd where all the milters are
>> called and afterwards the mail would be handed over to cleanup,
>> which does canonical stuff. But it seems I am wrong :)
>
> While Milters see SMTP commands as they happen, the first Milter
> inspects the message content an
On 4/27/2014 3:10 AM, Erik Starbäck wrote:
> Hi!
>
> We have an rather complex postfix/cyrus-setup with many old quirks
> and stuff.
>
> I want to redirect our outgoing postfix to a "black box mail
> cleaning thing", and I want to direct it to it without any rewriting
> of addresses, just as it w
Tom Ritter:
> Hi all. New to running a mailserver, and I want to make sure I really
> understand what's happening with it, strange behaviors, and try to
> prevent misconfigurations.
>
> What I'd like to do is slowly filter out specific notifications I
> don't care about. The example I'll use rig
Hi,
Am 27.04.2014 um 21:53 schrieb Tom Ritter :
>if isSpecificError(self.msg.strip()):
I am not 100% sure, so this is what I guess or what I would expect:
The milter is using callbacks, which are called from Postfix in each of its
smtpd_*_restrictions. So if you have something like rej
Hi all. New to running a mailserver, and I want to make sure I really
understand what's happening with it, strange behaviors, and try to
prevent misconfigurations.
What I'd like to do is slowly filter out specific notifications I
don't care about. The example I'll use right now is 'Relay Access
Christian R??ner:
> I thought mail would arrive on smtpd where all the milters are
> called and afterwards the mail would be handed over to cleanup,
> which does canonical stuff. But it seems I am wrong :)
While Milters see SMTP commands as they happen, the first Milter
inspects the message conten
Hi,
I have this in my logs:
Apr 27 03:42:59 mx postfix/smtpd[16599]: connect from
outmail038.prn2.facebook.com[66.220.144.165]:61593
Apr 27 03:42:59 mx postfix/smtpd[16599]: Anonymous TLS connection established
from outmail038.prn2.facebook.com[66.220.144.165]:61593: TLSv1 with cipher
ECDHE-RS
On 4/27/14, 9:36 AM, Matt Holgate wrote:
>
> Thanks Wietse! Actually, 'theirdomain.com' was a placeholder (I wanted
> to avoid exposing their real domain to mailing list and thus making it
> a target of spam). The domain they are using is real :)
>
> Matt.
As a point of information, there is a set
You are right.
Even if I did not manage to get what I wanted, based on your tips, I worked
with "warn subject".
It revealed that those few messages are 100% spam, passing my machine and
being rejected by Exchange which incorporates MS SmartScreen.
I will work on spam detection to close this gap
On 27/04/2014 14:18, Wietse Venema wrote:
This looks like the "fantasy domain" example in
http://www.postfix.org/SOHO_README.html#fantasy
You'd do something like:
/etc/postfix/main.cf:
smtp_generic_maps = hash:/etc/postfix/generic
/etc/postfix/generic:
dougandmari...@theirdomain.com
Matt Holgate:
> Indeed - sorry, I didn't explain myself very well!
>
> What I'm trying to achieve is to forward unextended addresses in my
> parent's domain to extended addresses at Gmail.
>
> My parents share a common gmail account, and use Gmail filters to sort
> 'private' messages sent to th
Matt Holgate:
> It seemed like the catchall address was getting triggered for e.g.
> d...@theirdomain.com. I'm guessing I need to put the catchall rule at
> the top?
As documented in the virtual(5) manpage, virtual alias lookups are
recursive (the result of lookup is subject to alias lookup).
Re
On 27/04/2014 13:35, Matt Holgate wrote:
What I'm trying to achieve is to forward unextended addresses in my
parent's domain to extended addresses at Gmail.
D'oh, sorry! I just realised I had a catchall address setup as well,
which was causing the problem (i.e. it was nothing to do with addre
On 27/04/2014 13:21, Wietse Venema wrote:
Matt Holgate:
Is there any way of avoiding this? I see there is a
'propagate_unmatched_extensions' parameter, but I'd have thought this
would have no effect as there is no extension in the original address.
No that is backwards. It propagates the exte
Matt Holgate:
> Is there any way of avoiding this? I see there is a
> 'propagate_unmatched_extensions' parameter, but I'd have thought this
> would have no effect as there is no extension in the original address.
No that is backwards. It propagates the extension that exists in the
original addre
Marius Gologan:
> I made a test (log below). The warning header appears in "cleanup" log line.
> Not in the same line with the smtp client log, with Exchange rejection.
>
> Apr 27 03:14:03 gateway postfix/cleanup[10319]: 76D2343520: warning: header
> X-SMTP-Client-Addr: ip.add.re.ss from host.s-do
Hi,
I've got a virtual map with lines as follows:
a...@example.commydomain+...@gmail.com
d...@example.commydomain+...@gmail.com
However, it seems like when the lookup occurs, the address extension
(+abc or +def) of the destination address is removed.
Is there any way of avoiding this
Hi!
Perhaps clarifying what I want to achieve...
The blackbox thing will then direct my "cleaned mail" to the same postfix (but
with another personality (in master.cf) to another port. So this machine still
need all the virtual alias stuff for this part. And the "deliver back part"
seems to wo
Hi!
We have an rather complex postfix/cyrus-setup with many old quirks and stuff.
I want to redirect our outgoing postfix to a "black box mail cleaning thing",
and I want to direct it to it without any rewriting of addresses, just as it
was external mail.
I still want check the sending address
19 matches
Mail list logo
