--On 17 October 2006 22:54:54 +0300 Stuart Gall <stuart@???> wrote:
> Hello,
> I have just came across two servers that are blocking empty envelope
> to's
>
> VIZ
> telnet mail.ophosting.net 25
> Trying 63.246.16.254...
> Connected to mail.ophosting.net.
> Escape character is '^]'.
> 220 ophosting.net (IMail 8.00 37307-38) NT-ESMTP Server X1
> helo itsme
> 250 hello ophosting.net
> mail from:<>
> 501 bogus mail from
It's a badly configured IPSwitch Imail server. IPSwitch say "In versions
8.10 and later, this option is no longer configurable in IMail
Administrator", and "To comply with the SMTP RFC, the 'Refuse Null <>
Senders' option should not be selected".
There are instructions on how to switch off the "feature" here:
<
http://support.ipswitch.com/kb/IM-19980116-DD02.htm>
> quit
> 221 Goodbye
> Connection closed by foreign host.
>
>
> I assume that this is some kind of anti spam measure
> So this means
> 1. They will never get a DSN
> 2. sender callout will fail
Reject their messages. Send an email referring the postmaster to
<
http://support.ipswitch.com/kb/IM-19980116-DD02.htm>
>
> Now obviously if they do not accept DSN's undeliverable messages will
> be frozen on our server and so this should be rejected. Personally I
> would be quite happy to leave it at that. However one of my clients
> wants to be able to receive mail from two such domains.
>
> So I was wondering if anyone else has came across this strange tactic. ?
> If it becomes more widespread then perhaps we need an option to
> specify the from address in sender callouts.
>
> That way if you are using callouts as an anti spam measure then you
> can use postmaster as the sender.
> and retain some of the advantages.
> The only problem with having a from address in the callout is that
> you might get a mail callout loop if the other server is doing call
> backs. Hmmm thats a big problem.
>
> Perhaps there should be a way to defer if the from is rejected as
> opposed to the rcpt to:
There is, but don't do it. Punish the evil ****s and educate them ;^)
> Comments ?
>
>
> Stuart Gall
--
Ian Eiloart
IT Services, University of Sussex
