Lukas,
On 8/4/2009 1:02 AM, Lukas Ruf wrote:
On Monday 03 August 2009 15:34:59 Lukas Ruf wrote:
I cannot understand why Postfix/cleanup rejects particular Subject
lines, since I have been searching for the respective regexps but
haven't found what I've been looking for. My question is simple:
Velvet Pixel wrote:
>
> A grep of smtp returns two types of entries. A postfix/smtp and a
> postfix/anvil.
>
> When I grep the ID of a sample of each they look like this:
>
> postfix/smtp:
> Jul 29 20:14:11 vps postfix/smtp[21650]: A85225A08723:
> to=<[EMAIL PROTECTED]>,
> relay=gmail-smtp-in.l.
Velvet Pixel wrote:
> I think I understand what anvil is now.
>
> So to be clear, all listings in postfix/anvil are clients trying to
> connect to use my system to send and has nothing to do with messages
> received (such as spam) by my system or is it both?
>
Right, clients connecting to your
t;
> Should I just ignore these or is there something I can do to block them?
>
Post output from postconf -n and you'll get lots of good feedback about
how to configure your anti-spam measures.
MrC
Luigi Rosa wrote:
> mouss said the following on 31/07/08 09:02:
>
>> so you also need to play with "advanced" routing to make sure the
>> packets go out of eth2.
>
> Such as?
>
> I just need a hint on what I have to search in the documentation, either
> Postfix or Linux. What do you mean with "
Jim McIver wrote:
> My header_checks file contains:
> # Disallow sender-specified routing. This is a must if you relay mail
> #for other domains.
> /[EMAIL PROTECTED]@]/ 550 Sender-specified routing rejected
>
This seems prone to many false positives. Many headers have such
pattern
Uwe Dippel wrote:
> Aside of hacks, I *think* that it might make sense to have a non-hacked
> solution. As system administrators, we, at least I, send quite a number
> of items with mail (cronjobs).
> Therefore, IMHVHO, a tool distributed with *nix or *fix (wrapping around
> mail) might be useful?
ut should look like:
1 SASL authenticated relayed messages --
1 [EMAIL PROTECTED] (*unknown)
1 *unknown
1218.30.101.41unknown
I've corrected the bug in 1.37.08:
http://www.mikecappella.com/logwatch/
MrC
mouss wrote:
> MrC a écrit :
>> [snip]
>> But, your entry discovered a bug in the parsing of the sasl_sender=
>> portion of smtpd's client= log line. The output should look like:
>>
>>1 SASL authenticated relayed messages --
>
Victor Duchovni wrote:
>
> It is interesting to see an MUA negotiate an anonymous session. Clearly
> T-Bird did not care to ask for or verify the server certificate. Did
> it require special configuration to enable this, or is this default
> T-Bird behaviour?
I see the same in my logs - default s
10 matches
Mail list logo
