Interesting. ORF gives you the option to disconnect and I'm wondering
if it is wise despite the 20 year old stipulation in the RFC:
Close SMTP connection when blocking
The Open Relay Filter Enterprise Edition blocks the spam when the
remote server tries to specify the message recipient(s). ORF does
blocking with sending negative responses to protocol commands, e.g.
does not accept the mail sender or the mail recipient(s). If the mail
sender or the recipient(s) are not accepted, the remote server should
not continue with sending the message body. There are some
"aggressive" servers however which do send the message even if they
receive negative response. Because of this, some spam mails can still
get through.
This is only a backup MX and it's only being used to verify the
recipients are valid so there's no chance of it allowing spam to pass
through, though it might result in spam being accepted to invalid
addresses if I'm reading it properly. I was under the impression
though that things like spamware on zombies might send the data anyway,
and this would be a way to save bandwidth and processing power.
I guess what I'm asking is should I be closing the connection on a
failure for the sake of blocking spam, or keeping it open for the sake
of being RFC compliant? I would imagine that this will be something
that Declude might want to support when it comes time to break away
from IMail :)
Thanks,
Matt
R. Scott Perry wrote:
I just came across an issue where DNS Report
was giving me a failure for the following:
FAIL
Connect to mail servers
ERROR: I could not connect to one or more of your mailservers:
mx2.mailpure.com: Connection closed before I received all my data
(state 8). Your mailserver disconnected before it was done! This may be
the result of a non-RFC-compliant mailserver or anti-spam program.
The server was fine, but it wasn't accepting a domain literal (which
was warned). When I configured Vamsoft's ORF on the secondary to
accept domain literals, both that warning and the above failure
disappeared.
I just thought I would point this out to you in the event that this
behavior was unintentional. I'll remove the domain literal support for
the next hour so you can see the failure plus the warning.
Actually, the problem is that it is/was disconnecting the TCP/IP
session after the E-mail to the domain literal was sent. That's the
part that isn't allowed, and causes the DNS report to stop the testing.
-Scott
---
Declude JunkMail: The advanced anti-spam solution for IMail mailservers
since 2000.
Declude Virus: Ultra reliable virus detection and the leader in
mailserver vulnerability detection.
Find out what you've been missing: Ask for a free 30-day evaluation.
---
[This E-mail was scanned for viruses by Declude Virus
(http://www.declude.com)]
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
--
=====================================================
MailPure custom filters for Declude JunkMail Pro.
http://www.mailpure.com/software/
=====================================================
|
