[Mimedefang] Re: On pinheaded ISP's (sort of OT)
The near-uselessness of AOL feedback loop reports has been thoroughly flogged on both the SPAM-L and HIED-EMAILADMIN lists. At least one member of AOL's postmaster staff is subscribed to the HIED-EMAILADMIN list (at the invitation of the list owners) and responded to the complaints with a carefully worded message which led me to believe that the current situation was mandated by some management and/or legal types with little or no experience in email services administration. -- Paul Russell, Senior Systems Administrator OIT Messaging Services Team University of Notre Dame [EMAIL PROTECTED] ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Graphdefang: Need to chart activity by server for multiple servers on a single chart
We consolidate logs from multiple mail servers for processing by GraphDefang. We have a need to generate charts which show activity by server, such as IMAP logins per server, with the totals for multiple servers on a single chart. The server name appears in every log entry, however, it is not one of the values returned by the event parsers. Has anyone modified the event parsers to include the server name? I would rather not re-invent the wheel, if I can avoid it. -- Paul Russell, Senior Systems Administrator OIT Messaging Services Team University of Notre Dame [EMAIL PROTECTED] ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Re: Non-routable addresses in HELO
On 11 Jul 2006, Jan-Pieter Cornet <[EMAIL PROTECTED]> wrote: > Also note that I'm not aware of any SMTP server implementation that > actually enforces syntactic checks on the HELO or EHLO argument out > of the box (resulting in lots of clients sending utter crap). Also > note that blocking based on EHLO will produce some false positives: > there are legitimate mail servers out there that EHLO as, eg. > "lan.local" or something silly. Any mail server that is so poorly administered that is not offering a properly formatted HELO argument is not legitimate and should not be connected to the Internet. The RFC clearly states that the server *MUST* use a FQDN or bracketed literal IP address as the HELO argument. Anything else is explicitly prohibitted and grounds for rejecting the connection. -- Paul Russell, Senior Systems Administrator OIT Messaging Services Team University of Notre Dame [EMAIL PROTECTED] ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Re: Requiring FQDN in HELO
On Wed, 28 Dec 2005, James Ebright <[EMAIL PROTECTED]> wrote: In addition, I believe rejecting email due to an invalid HELO/EHLO is a rfc violation in of itself (MUST NOT even). That said, the only ones I reject are the ratware ones that say they are me (my ip blocks or localhost or my own FQDN). ;-) RFC 2821 states that a sender *MUST* start an SMTP transaction with a HELO/EHLO command, and that the syntax of the command is: ehlo= "EHLO" SP Domain CRLF helo= "HELO" SP Domain CRLF It also states that the domain *MUST* be either a FQDN or a bracketed IP address, and explicitly forbids the use of any other format. Before we put an "email security appliance" in front of our inbound MTA's, we were rejecting messages from systems which used anything other than a FQDN or bracketed IP address as the HELO/EHLO parameter. We had to exempt our own net block from this restriction, due to the number of broken MS systems which HELO'd with their Netbios name. We experienced a noticeable reduction in the volume of spam and virus traffic accepted at the SMTP level when we implemented this policy. We returned an error message with a URL pointing to a page that explained the reason for the rejection. When remote sites complained about the rejections, we referred them to the web page, explained that most of the systems exhibiting this behavior were either owned or controlled by spammers, and suggested that they fix their broken systems. To the best of my knowledge, no one complained twice. The prohibition on rejection seems to apply to situations in which the HELO/EHLO parameter does not match the DNS name. Technically, the use of a syntactically invalid domain name on the HELO/EHLO parameter is a subset of the cases in which the HELO/EHLO parameter does not match the DNS name, but we were not comparing the HELO/EHLO parameter to the DNS name and rejecting due to the mismatch; we were rejecting because the HELO/EHLO parameter was syntactically invalid. This issue was discussed at length on the SPAM-L list a few months ago. If I recall correctly, most posters seemed to agree that sites which rejected for this reason were probably not violating the RFC, but were likely to experience a large number of false positives. At least one site reported adding points to the SA score on messages from systems which used syntactically invalid HELO/EHLO parameters. -- Paul Russell Senior Systems Administrator OIT Messaging Services Team University of Notre Dame ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Re: ClamAV's Worm/Trojan/Joke/W97M classifications
On Thu, 30 Jun 2005, Matthew Schumacher <[EMAIL PROTECTED]> wrote: There is another case where rejecting is better that hasn't been bought up yet (or at least I didn't read it) password protected zip archives. On our mail system we call these viruses simply because they almost always are, but if we where silently dropping them then that would be a problem. Many viruses use their own SMTP engines, which just keep pumping the sludge, no matter how many 5xx errors you throw at them, and they do not display the mail server rejection messages to the local user. We deal with this issue by running a script against our mail server logs twice daily to identify systems in our net blocks which have submitted virus carrier messages to our SMTP servers. -- Paul Russell Senior Systems Administrator OIT Messaging Services Team University of Notre Dame ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Re: ZDnet article on new Zombie Trick
On Thu, 3 Feb 2005 "Paul Murphy" <[EMAIL PROTECTED]> wrote: And in any case, how long will it be before the trojan stuffs keypresses or VB script into Windows to start Outlook or Outlook Express in a hidden window if it finds it, and then plug away sending messages with the correct client settings, including client authentication? It seems to me that it would be much easier and almost as effective to simply pop up a dialogue box asking for the username and password. I suspect that many users would stupidly provide the requested information and click OK without wondering why they were being asked. -- Paul Russell Senior Systems Administrator OIT Messaging Services Team University of Notre Dame ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Re: MIMEDefang Digest, Vol 11, Issue 28
On Tue, 10 Aug 2004, Ben Kamen <[EMAIL PROTECTED]> wrote: Er, oo... Well, in that case, let me introduce you to Mr. "Reply-To:" field. Can't help ya there.. that is a problem. But the reply-to: would fix that. For a good time, try introducing a Eudora user to the concept of a reply-to header. -- Paul Russell Senior Systems Administrator OIT Messaging Services Team University of Notre Dame ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
