+++ Raju Mathur [linux-india] <10/09/01 19:24 +0530>:
> Anyone got a clue why this is happening with one of the list
> subscribers?
As a matter of fact, I do. The valinux / sourceforge sysadmin - Marc Merlin
- has implemented sender verification callbacks in Exim. He was discussing
this on the exim-users archive quite a while back.
When you send mail to sourceforge, a series of tests are likely to be run on
your domain - where sourceforge connects back to your server and attempts to
find out if you exist or not.
> ... while talking to mail.sourceforge.net.:
> >>> DATA
> <<< 550-Envelope sender verification failed
> <<< 550 rejected: there is no valid sender in any header line (envelope
> sender is <[EMAIL PROTECTED]>). Your mail server returned: response
> from mail.rurkiu.ernet.in [202.141.62.14] was 551
> <[EMAIL PROTECTED]>... we do not relay.
> 554 <[EMAIL PROTECTED]>... Service unavailable
Roorkee University seems to have misconfigured their mailserver a bit, I
think. At least one of their backup MXs - mail.rurkiu.ernet.in (the tertiary
MX) doesn't know that it is a backup MX. That is, sendmail on that box
doesn't have rurkiu in relay-domains (or local, for that matter).
;; ANSWER SECTION:
rurkiu.ernet.in. 1D IN MX 40 mail-relay-vsat.ernet.in.
rurkiu.ernet.in. 1D IN MX 50 milan.doe.ernet.in.
rurkiu.ernet.in. 1D IN MX 10 rurkiu.ernet.in.
rurkiu.ernet.in. 1D IN MX 30 mail.rurkiu.ernet.in.
Sourceforge couldn't connect to the pri / sec MX (no surprise, going by the
lousy connectivity ERNET provides) and then went to the tertiary MX for a
checkup. The tertiary MX returned a hard reject (550), implying that the
address is bogus. So sourceforge's exim assumes that this is spam coming in
with a bogus address, and bounces the connection.
-suresh
--
####[ Linux One Stanza Tip (LOST) ]###########################
Sub : Hard Disk packing up LOST #064
The frequency of faults at read write access to hard disk is
on the increase may herald a disk about to pack up. fsck prog
is not adequate to sort things out. Run e2fsck as well since
this calls the badblocks prog to write to bad blocks inode. On
an unmounted partition, from rescue disk do:
#e2fsck -c -p ..... Back up the partition soon thereafter.
####<[EMAIL PROTECTED]>####################################
_______________________________________________
linux-india-help mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/linux-india-help
