Jeff wrote on 12/09/2006 04:57:51 PM:
So, when my server sends e-mail, it uses saber.nabs.net as its
EHLO, and the connection comes from 71.246.216.107. host
saber.nabs.net returns 71.246.216.107, which is the same IP that the
connection comes from. So far, so good.
But, host
[EMAIL PROTECTED] spake the following on 12/11/2006 8:11 AM:
Jeff wrote on 12/09/2006 04:57:51 PM:
So, when my server sends e-mail, it uses saber.nabs.net as its
EHLO, and the connection comes from 71.246.216.107. host
saber.nabs.net returns 71.246.216.107, which is the same IP that the
Scott Silva wrote:
That is why I don't score botnet as high as the default. I want the actual
mail content to contribute something to its being tagged.
That way if I get a botnet hit at say 2.0, either a bayes_99 or a hit on a
digest will send it way over. But if it hits only botnet, and
I'm updating my MD configs to exempt submissions by trusted users from
SpamAssassin scanning. By trusted, I mean users that authenticated
themselves with SMTP AUTH, and have submitted via the MSA daemon on
ports other than 25.
I'm still novice enough at perl code that I don't quite have this
# return if ($SendmailMacros{daemon_name}) = MSA;
You can't use arithmetic comparison on a string value: use eq instead:
return if ($SendmailMacros{daemon_name}) eq MSA;
Also, there are Sendmail auth macros which are a more reliable method of
determining who connected and how - they
--On Monday, December 11, 2006 20:16 + Paul Murphy
[EMAIL PROTECTED] wrote:
# return if ($SendmailMacros{daemon_name}) = MSA;
You can't use arithmetic comparison on a string value: use eq instead:
return if ($SendmailMacros{daemon_name}) eq MSA;
Watch the parentheses too.
Philip Prindeville wrote:
Well, I can test changes.
One thing I noticed in the .spec file after I posted my first
email message is that we should run autoconf so that the
configure file gets rebuilt. This would happen after %setup
gets run, but before ./configure. Especially if some distros
Group,
I'm googling through the RFCs trying to find this (mainly RFC821 and 822),
but perhaps one of you might be able to help narrow this down? It's not a
MIMEDefang question, per se, but we've got a customer trying to send us a
programmatically-generated email, that is being blocked by our
Joseph Brennan wrote:
--On Monday, December 11, 2006 20:16 + Paul Murphy
[EMAIL PROTECTED] wrote:
# return if ($SendmailMacros{daemon_name}) = MSA;
You can't use arithmetic comparison on a string value: use eq instead:
The problem wasn't arithmetic vs string, it was assignment
Cormack, Ken wrote:
The arg being passed (to a sendmail rule that we have) indicates that the
HEADER To: line has incorrect syntax as follows:
[EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED]
The sendmail rule is not correct. I think that header is
perfectly fine, and a cursory
On Mon, Dec 11, 2006 at 04:57:38PM -0500, Cormack, Ken wrote:
The arg being passed (to a sendmail rule that we have) indicates that the
HEADER To: line has incorrect syntax as follows:
[EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED]
Note the presence of commas, but and the
Cormack, Ken spake the following on 12/11/2006 1:57 PM:
Group,
I'm googling through the RFCs trying to find this (mainly RFC821 and 822),
but perhaps one of you might be able to help narrow this down? It's not a
MIMEDefang question, per se, but we've got a customer trying to send us a
On Mon, Dec 11, 2006 at 02:32:47PM -0800, Scott Silva wrote:
RFC822 paragraph 3.4.2 deals with whitespace. 3.4.4 deals with phrases and
quoting, and the examples in the appendix clearly show a space after the comma
in multiple fields in the To:. Paragraph 3.1.1 also mentions the space or
CRLF
Jan-Pieter Cornet spake the following on 12/11/2006 3:16 PM:
You must have missed the big fat NOTE at the beginning of section
3.4.2 in RFC822 (which is obsolete for over 5 years now, by the way,
RFC2822 is the only true reference).
The spaces aren't required (unless as part of a folded
14 matches
Mail list logo
