It probably logged the blank HELO as the result of invalid data. The
sending software might have executed a return immediately following it
due to a missing value, and IMail might have then tracked the HELO as
the return, hence the return within the Message-ID header. It might
have also been a different character, similar to the bug in Declude
that is causing spam leakage with invalid Mail From characters.
Typically such software gets the name from the box. I'm not sure if
that name is somehow missing or inserted manually in the scripting.
Matt
Andy Schmidt wrote:
Hi:
this line tells you that this
mail truly should have never been accepted by Imail:
06:13
13:00 SMTPD(ef2801f100006207) [216.16.233.16] HELO
HELO
must be followed with the host name of the sender. Having no (or at
least no recognizable) host name is causing you the problem.
I'm
certain that your ASPmail/ASPEmail component will have some "host name"
property that wasn't set correctly - or may be it's picking it up from
the web server's host name and there is some problem there.
In
any case, the problem is not with Imail or what comes behind in - it's
the sending system.
Best Regards
Andy Schmidt
Phone: +1 201 934-3414 x20
(Business)
Fax: +1 201 934-9206
following is an excerpt of my
imail log: This message is submitted directly to the imail server.
None of my other servers run any SMTP server software.
06:13 13:00
SMTPD(ef2801f100006207) [216.16.233.16] HELO
06:13 13:00 SMTPD(ef2801f100006207) [216.16.233.16] MAIL FROM:<[EMAIL PROTECTED]>
06:13 13:00 SMTPD(ef2801f100006207) [216.16.233.16] RCPT TO:<[EMAIL PROTECTED]>
06:13 13:00 SMTPD(ef2801f100006207) [216.16.233.16] RCPT TO:<[EMAIL PROTECTED]>
06:13 13:00 SMTPD(ef2801f100006207) [216.16.233.16]
D:\IMail\spool\Def2801f100006207.SMD 16252
Thanks for your assistance
Harry Vanderzand
inTown Internet & Computer Services
519-741-1222
Any connecting SMTP connection must submit a HELO or EHLO. I believe
that IMail uses the HELO/EHLO name given as the part of the Message-ID
after the @ symbol, but will only insert this if there is no Message-ID
already present (which would also fail SPAMHEADERS in Declude unless
LOOSENSPAMHEADERS ON is set). If there is an line break here, that
data must be bad. If you look in your IMail log for the information
about the session (and turn up the logging), you should be able to see
the HELO/EHLO name given.
FYI, this wouldn't be the first IIS plug-in that had RFC issues. Many
have them. I can't say for sure 100% though that this is the case here
due to circumstances, but I strongly suspect this is the trigger. If
IMail acted properly, the message would have been rejected, and that's
not a solution to your issues either, so the fix is likely best applied
to your mailer.
Matt
Harry Vanderzand wrote:
Thanks Matt
This message comes straight from
a form submission on one of my servers. I think aspmail is being
used. My programmer says that it can't be caused by that and is
blaming the SMTP server it is submitted to, which is my imail server
Harry Vanderzand
inTown Internet & Computer
Services
519-741-1222
Looks like an IMail inserted Message-Id header, so in part it is their
problem. I suspect that the trigger though is the sender having an
invalid HELO, which IMail is then mishandling. It could have also been
a hickup unless it is repeatable with the same source.
The HELO, MAIL FROM and RCPT TO should all have only US-ASCII printable
characters (excluding space). Anything beyond that is invalid on it's
own, and IMO, the MTA should issue a 5xx error when received indicating
as much.
Matt
Harry Vanderzand wrote:
I am having a problem where the
message-id is malformed which trips up some clients.
see:
Message-Id: <200606131300275.SM04448@
>
X-Declude-Sender: [EMAIL PROTECTED]
[216.16.233.16]
Notice the the closing bracket is on a
separate line. This causes the headers
to become part of the body for some of my clients.
Has anyone
seen this before? Is it an imail issue or a declude issue?
Harry Vanderzand
inTown Internet & Computer
Services
11 Belmont Ave. W., Kitchener, ON,N2M 1L2
519-741-1222
---
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.
---
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.
---
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.
---
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.
---
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.
---
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.
---
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. |
